0.3 The Frameworks and Their Versions

Introduction

Every lesson in this course relies on frameworks, standards or laws, and every one of them is named with its version. This lesson sets out which versions the course teaches, why the course is built on NIST, how it handles the ISO standards it cannot quote, and what to do when a version changes after you read.

Lesson 1.7 teaches the frameworks in depth: what kind of document each is, what it asks of a program and how they relate. This lesson is the reference: the versions, where to read them, and the rules the course follows. Return to it whenever a lesson names something you want to check.

This lesson covers why versions matter, why NIST, the core publications, the supporting NIST publications, ISO and its text, SOC 2, laws, the other frameworks named, how the course checks versions, and what to do when one changes.

Frameworks change. A claim about one is only checkable if it says which version. The comparison shows the difference.

"SP 800-53 requires this control" cannot be checked: against which catalog? After a new release, it is silently right or wrong, and an auditor's first question is which version. A versioned claim, naming NIST SP 800-53 Rev. 5, release 5.2.0 (27 August 2025), can be checked against that release; after a new release it visibly needs rechecking; and the auditor's question is already answered.

The same is true in a program. A control mapping that cites "ISO 27001 A.8" without the edition is ambiguous, because the 2013 and 2022 editions organize Annex A differently. A policy that says it follows "the NIST Cybersecurity Framework" without saying 1.1 or 2.0 cannot be checked against either. Module 7's mapping lessons and Module 11's change lesson both depend on versions being stated.

The course holds itself to the same rule. Every lesson ends with a versions line naming each framework, standard and law it relies on, with its version, generated from a single register so the same version is stated the same way everywhere. Section 9 shows how that is checked.

Stating versions also protects you when you use the course's material. If you build your Statement of Applicability from Module 6 and a new edition of ISO/IEC 27001 is published, the lesson's versions line tells you the edition its method was written for, and you can see at once that the new edition needs checking against it.

The habit is worth building early. Programs that cite versions find framework changes easy to absorb, as lesson 11.7 showed; programs that do not discover the change when an auditor points it out. A version costs a few characters to write and saves an argument later, when two people discover they have been reading different editions of the same framework.

The course builds the program on NIST publications. The cards give the reasons.

NIST publications are free to read: every one the course uses can be downloaded in full, so you can check any lesson against its source rather than taking the course's word for it. They are US government works and may be quoted with attribution, which means the course can show you the exact words where they matter; the ISO standards may not be quoted.

Together they cover a whole program: structure, risk method, risk register, control catalog, assessment and monitoring. And NIST publishes and links mappings to other frameworks, which is what lets one control set serve many, as Module 7 teaches.

Building on NIST does not make the course US-only or government-only. The NIST publications the course uses are written for any organization, and are widely used outside the US and outside government. CSF 2.0 in particular was written to apply to organizations of any size, sector or country.

It also does not mean NIST is the only framework that matters. Many organizations must certify to ISO/IEC 27001, report against SOC 2, or meet laws and contracts. The course teaches all of those, as things the program maps onto its one NIST-based control set. The figure in section 3 shows the arrangement.

If your organization already uses another framework as its backbone, ISO/IEC 27001 or the CIS Controls, say, the course still works. The method of each module is the same; Module 7 teaches how to map between your backbone and the others, and the lessons' NIST references become the mapping targets rather than the structure.

Nothing in the course's method depends on NIST being your organization's choice. NIST is the course's backbone because a course needs one that every reader can open and check; your program's backbone is a decision for your organization, recorded in its charter as lesson 1.8 teaches.

The program is built on four NIST publications around one control set. The figure shows the arrangement.

CSF 2.0 gives the program its structure and outcomes. SP 800-30 Rev. 1 is the risk assessment method. IR 8286 Rev. 1 is the risk register and its reporting to enterprise risk management. SP 800-53 Rev.

5 is the catalog the one control set is selected from, and SP 800-53A Rev. 5 is how those controls are assessed. ISO/IEC 27001 certification, SOC 2 attestation and obligations from law and contract map onto the same control set.

The record below gives the exact versions.

The structure and outcomes come from NIST CSF 2.0, NIST CSWP 29 (26 February 2024). The risk assessment method is NIST SP 800-30 Rev. 1 (September 2012). The risk register follows NIST IR 8286 Rev. 1 (18 December 2025). And the control catalog is NIST SP 800-53 Rev. 5, release 5.2.0 (27 August 2025). All four are free to read at csrc.nist.gov and nvlpubs.nist.gov.

The record also lists where each is cited, computed from the lessons themselves: CSF 2.0 in Modules 1, 2, 3, 4, 5, 6, 7, 8 and 9, SP 800-30 in Modules 1, 4 and 6, IR 8286 in Modules 1, 3, 5, 6 and 11, and SP 800-53 in Modules 1, 3, 5, 6, 7, 8, 9, 10 and 11.

The four play different parts. CSF 2.0 says what outcomes a program should achieve and gives it a vocabulary for describing them, but it names no controls. SP 800-30 says how to assess risk: threats, vulnerabilities, likelihood and impact.

IR 8286 says how to record those risks so that they can be rolled up into the organization's enterprise risk picture. And SP 800-53 supplies the controls that treat them. Remove any one and the program has a gap: outcomes without controls, controls without a reason, or risks that never reach the people who decide.

The note under the record explains SP 800-53's versioning. Revision 5 was published in 2020 and is updated by numbered releases; lessons name the release they rely on. A release can add controls or change their discussion, so a mapping built on one release is checked when the next arrives.

Beyond the core, the course uses NIST publications for specific subjects. The cards list them with their versions, from the course's own register.

Each is used in the module whose subject it covers, and the card shows where, computed from the lessons. SP 800-53A, the assessment procedures, supports the control assessment of Modules 7 and 10, and SP 800-53B, the baselines, supports control selection. SP 800-161 is the supply chain guide behind Module 9.

SP 800-137, SP 800-55 and SP 800-50 support Modules 10 and 11: continuous monitoring, measurement, and awareness and training. SP 800-63B appears where the policy and risk lessons discuss passwords and authentication. IR 8477 and IR 8278A support the crosswalks of Module 7. SP 800-171 appears only as the standard CMMC references, in Module 8's example of a contractual requirement.

None of these needs reading in full before the lesson that uses it. Each lesson explains what it takes from the publication and cites the section, so you can go to the source if you want more. Where a lesson read only part of a publication, its source note says so, and it does not teach what it did not read.

Some of these publications are older than the core. SP 800-137 dates from September 2011 and has not been revised; the course uses it because its monitoring cycle is still the reference, and says so. A publication's age is not a reason to set it aside if it is still current; it is a reason to state its date.

The same applies to drafts. Where NIST has a revision in draft for a publication the course uses, the course teaches the final version and treats the draft as a change to watch, because a draft can change before it is final and is not yet what an assessor will test against.

The course teaches ISO/IEC 27001 without reproducing its text. The token sets out what that means.

The course specification sets the rule: there is no licensed copy for the course, and ISO text is not reproduced. ISO/IEC 27001:2022 is taught by clause number and short title, and Annex A by theme, in the course's own words. Control numbers and titles are used only where a source the course opened gives them from the published text. And you read the controls themselves in your organization's copy.

A lesson explaining clause 6.1.3 in its own words, citing the clause, is in. A lesson quoting the text of an Annex A control is out. A lesson grouping Annex A controls by theme and subject is in. A practice asking you to check a control in your organization's copy is in.

The token's note gives the reason: the ISO standards are paid documents under copyright. The course teaches what they require and how to meet it, and leaves their text to the copy your organization holds. Most organizations seeking certification buy the standard; if yours has not, Module 6 is still useful, because its method works from the clause structure every ISO management system standard shares.

The version is ISO/IEC 27001:2022 with Amd 1:2024. The amendment, published in February 2024, added climate change considerations to clauses 4.1 and 4.2, as lesson 6.2 described from secondary sources. Certificates issued against the 2013 edition had to transition by 31 October 2025, as lesson 6.8 described.

ISO/IEC 27002:2022, the guidance standard that expands on each control, and ISO/IEC 27006-1:2024, which governs certification bodies, appear where Module 6 needs them, under the same rule. Where a lesson relies on a secondary source for a detail of the standard, its source note says so, and you can confirm the detail in your own copy.

SOC 2 is taught from the AICPA's Trust Services Criteria. The tiles set out the version and where it is used.

The criteria taught are the AICPA 2017 Trust Services Criteria, revised points of focus (2022). They have five categories: security, availability, processing integrity, confidentiality and privacy. Module 8 teaches them from the side of an organization preparing for an examination, Module 9 from the side of a buyer reading a supplier's report, and Module 10 from the side of an organization supporting the auditor.

A change is on the way. In October 2026, the AICPA released an exposure draft of proposed 2027 Trust Services Criteria for comment, as lesson 8.3 noted from a secondary source.

An exposure draft is a proposal, not a standard: the final text and its effective date will decide when examinations must use it. The course teaches the current criteria, and lesson 11.7 shows how a program tracks a draft like this one in its change register.

The AICPA's criteria document is available from the AICPA, and the course cites it by category and criterion number. Some details the course teaches, such as criteria counts, come from secondary sources that summarize the AICPA's document; lessons that rely on such sources say so in their source notes.

SOC 2 reports themselves are confidential to the organization examined and its customers. The course never reproduces one; its examples are written for the course, using the structure the AICPA's guidance and the secondary sources describe.

If your organization is preparing for its first SOC 2 report, Module 8's lessons 8.3 and 8.4 are the place to start, followed by Module 10. If it already has one, read lesson 9.4, on reports and certificates as evidence, as a check on your own: what a buyer looks for in yours is what your report needs to show clearly.

The course treats laws as obligations to record and map, not as the frame of a lesson. The cards show the three it uses as examples.

GDPR, Regulation (EU) 2016/679, is the reference privacy law, chosen because it is the most widely copied model; Module 8 uses it to teach how any privacy law becomes obligations mapped to controls.

The EU AI Act, Regulation (EU) 2024/1689, appears in Module 11 as a source of regulatory change, including the change to its own dates. CMMC 2.0, set out in 32 CFR part 170, appears in Module 8 as one example of a contractual security requirement.

Other laws are named where an example needs them, with the date they were read, and are treated the same way: as sources of obligations. The course does not survey the world's security and privacy laws, because any survey would be out of date somewhere on the day it was published. It teaches the method for finding, recording and meeting obligations from any law, which lasts.

Laws are cited by article and paraphrased. Nothing in the course is legal advice. Every lesson that touches law says that interpretation belongs to counsel, and Module 8 teaches the program to record counsel's interpretation as the requirement it maps to controls.

The course read law texts from public sources: GDPR from a widely used mirror of the regulation's text, the AI Act's timeline from a public tracker, and secondary analyses where the primary text was not reachable. Source notes say which, so you know how much weight each claim carries and where to check it.

When a law changes, as the AI Act's dates did, lesson 11.7's method applies: record the change with its source, check the plan, and do not treat an agreement as law in force until counsel confirms it.

The course names other frameworks where a lesson compares, maps or cites them. The tiles list them with their versions, from the course's register.

CIS Controls v8.1 appear as a widely used alternative catalog with implementation groups. COBIT 2019 (ISACA) appears in Module 1 to separate governance from management. The CSA Cloud Controls Matrix v4.1, with the CAIQ, appears in Module 9 as a standard questionnaire for cloud suppliers. Open FAIR, made of the Risk Taxonomy (O-RT) 3.0.1 and Risk Analysis (O-RA) 2.0.1 standards, appears in Module 4 as a quantitative risk method.

ISO 31000:2018 appears in Module 1 for its definition of risk. The IIA's Three Lines Model (2020) appears in Module 1. And OCEG GRC Capability Model 3.5 (the Red Book) appears in Module 1 as one description of what GRC is. The tiles give the modules where each is cited, computed from the lessons rather than written by hand.

In all, the course's version register knows 28 families of framework, standard and law: 14 NIST publications, 4 ISO standards, 3 laws and contract regimes, and 7 others. The counts come from the register itself, so they match what the lessons are checked against.

None of these other frameworks is required. They are named because a practitioner will meet them, and a program often has to map to one of them for a customer or a regulator. Module 7's method handles any of them the same way: as another set of requirements mapped onto the one control set.

If your organization uses a framework the course does not name, the same method applies. The course does not need to know every framework; it teaches how to map any of them. Start by recording it in your version register with its exact version, as the practice below asks, and then treat it as Module 7 treats any framework.

The course checks its own versions with a script. The evaluator shows the check on a draft lesson.

A draft lesson named SP 800-53, ISO/IEC 27001 and the CIS Controls. The check found SP 800-53 named with "Rev. 5", matching the register, and ISO/IEC 27001 named with ":2022", also matching. The CIS Controls were named without a version, so the check refused the lesson until it said v8.1.

The versions line at the foot was generated from the register, listing each family the lesson names. And the check itself is tested against a planted lesson with a missing version, so it cannot pass silently by checking nothing.

The evaluator's note gives the scale. The check knows 28 families, and a lesson that names one without its version is not published until it is fixed.

The check exists because reading a lesson back does not catch a missing version: a sentence that says "SP 800-53" looks complete to a reader who knows what is meant. A script looking for the pattern does not have that blind spot.

The register is also the single place where versions are stated. When a framework changes, its entry changes once, and every lesson's versions line changes with it when the lessons are regenerated. The check then finds any lesson whose text still states the old version, so nothing is updated in one place and missed in another.

The same idea works in a program. A register of the frameworks, standards and laws the program relies on, each with its version and where it is cited, makes a framework change a matter of looking up where it is used, as lesson 11.7's change register does.

The register does not need a tool. A short list in the program file, kept current, does the job; what matters is that it is the one place the versions are stated.

Frameworks will change after you read this course. The gate shows what to do when one does.

If it is a core publication, or one your organization reports against, read what changed, and check the lessons and your own records that cite it. If it is a supporting publication or a draft not yet final, note it, and revisit when it is final or when you next use it. If it is a framework your program does not use, carry on.

The gate's foot explains why the course makes this easy. The versions line tells you exactly what a lesson relied on, so you can tell whether a new version touches it. A lesson built on CSF 2.0 is unaffected by a new release of SP 800-53, unless it maps between them.

The course itself is kept current against its register. When a framework the course relies on changes, the register's entry is updated, the affected lessons are checked and regenerated, and their versions lines change with them. The versions line at the foot of each lesson is therefore also the date stamp of what it was last checked against.

Your program will face the same task. Lesson 11.7 teaches the change register, triage and impact assessment for framework and legal change. This lesson's register is a small example of the same idea, and the habit of citing versions is the first step.

The quickest test of whether your program is ready for a framework change is to pick one framework it relies on and ask where it is cited. If the answer comes from a register, the change will be manageable. If it comes from searching documents, start a register. Either way, the practice below gives you a first register to start from, and lesson 11.7 shows how to keep it current.

Every framework, standard and law the course relies on is named with its version, from one register that the course's own check enforces. The program is built on four NIST publications, CSF 2.0, SP 800-30 Rev. 1, IR 8286 Rev. 1 and SP 800-53 Rev.

5 release 5.2.0, because they are free, quotable and complete. ISO/IEC 27001:2022 is taught without reproducing its text, SOC 2 from the 2017 criteria with a 2027 draft in view, and laws as obligations with GDPR as the reference. When a version changes, the versions line shows what it touches.

Versions this lesson relies on: NIST SP 800-30 Rev. 1 (September 2012); NIST SP 800-53 Rev. 5, release 5.2.0 (27 August 2025); NIST IR 8286 Rev. 1 (18 December 2025); ISO/IEC 27001:2022 with Amd 1:2024; ISO/IEC 27002:2022; NIST SP 800-53B, release 5.2.0 (27 August 2025); NIST SP 800-53A Rev. 5 (January 2022), release 5.2.0 (27 August 2025); CMMC 2.0 (32 CFR part 170; 48 CFR rule published 10 September 2025); NIST SP 800-171 Rev. 2, as CMMC 2.0 Level 2 references it; NIST IR 8477 (February 2024); NIST IR 8278A Rev. 1 (February 2024); CIS Controls v8.1; NIST SP 800-55 Vol. 1 (December 2024); NIST SP 800-50 Rev. 1 (September 2024); EU AI Act, Regulation (EU) 2024/1689; NIST SP 800-137 (September 2011); NIST SP 800-161 Rev. 1, Update 1 (1 November 2024); CSA Cloud Controls Matrix v4.1, with the CAIQ; ISO/IEC 27006-1:2024; ISO 31000:2018; NIST SP 800-63B-4 (July 2025); NIST CSF 2.0, NIST CSWP 29 (26 February 2024); AICPA 2017 Trust Services Criteria, revised points of focus (2022); COBIT 2019 (ISACA); GDPR, Regulation (EU) 2016/679; The IIA's Three Lines Model (2020); The Open Group Risk Taxonomy (O-RT) Standard, Version 3.0.1, and Risk Analysis (O-RA) Standard, Version 2.0.1 (Open FAIR); OCEG GRC Capability Model 3.5 (the Red Book).