Framework versioning
Why this matters
Section titled “Why this matters”When you import a framework with Crosswalker, you create a snapshot. When that framework publishes a new version, your snapshot is stale. Your crosswalk links may point to renamed or removed controls. Your assessments reference outdated IDs. This page documents how each major framework handles versioning — so Crosswalker can eventually handle it too.
NIST CSF 1.1 → 2.0 (February 2024)
Section titled “NIST CSF 1.1 → 2.0 (February 2024)”What changed
Section titled “What changed”- Added GOVERN as a sixth core function (previously governance was scattered across other functions)
- Broadened scope beyond critical infrastructure to all organizations
- Reorganized subcategories — some merged, split, or moved between functions
- No content was removed — all CSF 1.1 meaning is preserved in 2.0
Migration resources
Section titled “Migration resources”- CSF 1.1 to 2.0 Core Transition Changes — Excel spreadsheet mapping every subcategory
- OLIR Crosswalk Spreadsheet — machine-readable mapping
- CSF 2.0 Quick Start Guides
- CPRT Reference Tool
Impact
Section titled “Impact”- FFIEC CAT was retired (August 2025) rather than updated — tools built on it became obsolete
- HITRUST created CSF 2.0 as an add-on certification — prior CSF 1.1 assessments don’t auto-transfer
- Organizations needed to manually re-map their evidence to the new structure
NIST 800-53 Rev 4 → Rev 5 (September 2020)
Section titled “NIST 800-53 Rev 4 → Rev 5 (September 2020)”What changed
Section titled “What changed”- 65 new base controls and 204 new control enhancements
- Two entirely new control families: PT (PII Processing and Transparency) and SR (Supply Chain Risk Management)
- 63 existing controls received 149 new enhancements
- Priority system eliminated; baselines moved to separate document (SP 800-53B)
- Rev 4 is officially withdrawn
Migration resources
Section titled “Migration resources”- Rev 4 to Rev 5 Comparison Workbook — describes changes to each control with significance assessment
- SP 800-53 Downloads
- Control Overlays
MITRE ATT&CK — the gold standard Best Practice
Section titled “MITRE ATT&CK — the gold standard ”Best PracticeATT&CK has the most mature versioning system of any cybersecurity framework:
Release cadence
Section titled “Release cadence”- Biannual releases (April and October) with major.minor versioning
- Current: v16.1 (as of late 2025)
- Every version gets an archived website
Lifecycle states
Section titled “Lifecycle states”| State | Meaning | Example |
|---|---|---|
| Active | Current, maintained | Most techniques |
| Revoked | Replaced by another object | T1086 (PowerShell) → T1059.001 |
| Deprecated | Retired, no replacement | Techniques deemed too broad |
| Un-deprecated | Brought back after deprecation | Techniques reconsidered based on community feedback |
Machine-readable changelogs via STIX 2.1
Section titled “Machine-readable changelogs via STIX 2.1”ATT&CK publishes changelogs in both human-readable and STIX 2.1 JSON format. The key mechanism: revoked-by relationships link old objects to their replacements, creating a followable deprecation chain. The mitreattack-python library can follow these chains programmatically — a pattern Crosswalker could adopt for automated migration detection.
The sub-technique migration (July 2020)
Section titled “The sub-technique migration (July 2020)”The largest structural change: 266 techniques consolidated into 156 parent techniques with 272 sub-techniques. IDs changed to dot notation:
T1086(PowerShell) →T1059.001(Command and Scripting Interpreter: PowerShell)
MITRE preserved the pre-sub-technique version separately for backward compatibility and corrected ID errors based on community feedback.
Resources
Section titled “Resources”- ATT&CK Versions — archived versions of every release
- ATT&CK Data & Tools — STIX data bundles
- MITRE ATT&CK GitHub — machine-readable data
- Mappings Explorer — cross-framework mappings
CIS Controls v7 → v8 (May 2021)
Section titled “CIS Controls v7 → v8 (May 2021)”What changed
Section titled “What changed”- Consolidated from 20 controls to 18
- Reorganized by activity type rather than by who implements
- New emphasis on cloud, mobile, and third-party risk
- Implementation Groups (IG1/IG2/IG3) became the primary organizational layer
Migration resources
Section titled “Migration resources”- CIS Controls v8 Change Log — white paper describing all changes
- No automated migration available due to substantial structural differences
- CIS Controls Navigator — interactive comparison
CRI Profile v1.2 → v2.0 (February 2024)
Section titled “CRI Profile v1.2 → v2.0 (February 2024)”What changed
Section titled “What changed”- “Most expansive revision to date”
- Expanded scope to enterprise technology, third-party risk, business continuity
- Added new Extend function
- Added subject tags and global regulatory mappings
- v2.1 kept all v2.0 diagnostic statements unchanged
Migration resources
Section titled “Migration resources”- CRI Profile v2.0 Mapping — v1.2.1 to v2.0 mapping document
- The Profile — latest version download
OSCAL’s versioning approach
Section titled “OSCAL’s versioning approach”OSCAL uses SemVer (MAJOR.MINOR.PATCH) with a core guarantee: content created under a MAJOR version remains valid under all subsequent releases within that major version. Key mechanisms:
- Every OSCAL document has a UUID that regenerates on every change
last-modified,version, and revision history fields are built-in- A metaschema framework generates XML, JSON, and YAML schemas simultaneously — migration between formats is easier because all derive from the same abstract definition
- See also: SchemaVer as an alternative versioning model
CRI Profile v2.1: separating content from mappings
Section titled “CRI Profile v2.1: separating content from mappings”An important pattern: CRI v2.1 kept diagnostic statements unchanged but moved crosswalk mappings to a separate workbook. This separation enables independent evolution — the core framework and its crosswalks can update on different timelines. A pattern Crosswalker should consider for its own config management.
Who maintains crosswalks?
Section titled “Who maintains crosswalks?”NIST OLIR program
Section titled “NIST OLIR program”The OLIR (Online Informative References) program is submission-based: the submitting organization is responsible for maintaining their mappings. There is no automatic mechanism to flag stale crosswalks when either side updates.
Implication: Crosswalks can become stale silently. If CSF updates but the CSF-to-800-53 crosswalk doesn’t, tools relying on it give incorrect results.
SCF’s meta-framework approach
Section titled “SCF’s meta-framework approach”The Secure Controls Framework solves this by acting as a central hub: when a framework updates, only the SCF-to-that-framework mapping needs updating (see interlingua approach). This propagates the change to all 175+ mapped frameworks automatically.
What breaks when a framework updates
Section titled “What breaks when a framework updates”| What | How it breaks | Severity |
|---|---|---|
| Imported folder structure | Hierarchy may not match new version | Medium — old version still readable |
| Crosswalk links | May point to renamed/removed controls | High — broken references |
| Assessment status | ”Compliant with CSF 1.1” ≠ “Compliant with CSF 2.0” | High — compliance claims invalid |
| Tool configurations | Hardcoded IDs, column names, regex patterns | Medium — requires manual update |
| Reports and dashboards | Queries return stale or incomplete data | Medium — misleading results |
| GRC platform mappings | Vendor must release update | Variable — depends on vendor timeline |
How GRC tools handle updates
Section titled “How GRC tools handle updates”| Tool | Approach |
|---|---|
| CISO Assistant | Library versioning with incremental upgrade steps; OLIR-based mappings |
| SCF | Meta-framework absorbs changes centrally using STRM methodology |
| ServiceNow/Archer | Content packs updated per vendor timeline; migration tools |
| Apptega | Commercial crosswalk updates as a service |
The “framework changelog” concept
Section titled “The “framework changelog” concept”There is no universal standard for framework changelogs. Each framework handles it differently:
| Framework | Changelog Format | Machine-Readable |
|---|---|---|
| MITRE ATT&CK | STIX JSON + human-readable | Yes |
| NIST 800-53 | Excel workbook | Partially |
| NIST CSF | Excel spreadsheet | Partially |
| CIS Controls | PDF white paper | No |
| CRI Profile | PDF mapping document | No |
A future Crosswalker feature could ingest machine-readable changelogs (ATT&CK STIX, OSCAL diffs) to automate migration detection.
Resources
Section titled “Resources”Migration documents
Section titled “Migration documents”- CSF 1.1→2.0 Transition
- 800-53 Rev 4→5 Comparison
- ATT&CK Versions Archive
- CIS v8 Change Log
- CRI v2.0 Mapping
Crosswalk maintenance
Section titled “Crosswalk maintenance”Related pages
Section titled “Related pages”- Ontology evolution — the general problem
- Schema matching — how systems find correspondences
- Data model resilience — Crosswalker’s design response
- Framework crosswalks — current crosswalk implementation
- Framework standards & tools — links to all framework resources