---
title: Revision 3 Transition
description: Prepare for the NIST SP 800-171 Revision 3 update — set organization-defined parameters (ODPs), see how each control changes between Rev 2 and Rev 3, and opt in to the Rev 3 experience early.
navigation:
  icon: i-lucide-git-compare-arrows
---

# Revision 3 Transition

CMMC Level 2 is built on **NIST SP 800-171**. The standard is moving from **Revision 2** — the baseline your assessment is scored against today — to **Revision 3**, a reorganized and reworded update. The **Revision 3 Transition** feature is how DIBFI prepares you for that change without disrupting the work you've already done: it shows you what happens to each control, lets you record the **organization-defined parameters (ODPs)** that Rev 3 asks every organization to set, and gives you a way to start working in Rev 3 early.

The transition is a formal, industry-wide event, so DIBFI controls *when* Rev 3 becomes the operative standard for everyone. Until then, you can preview what's coming and — when early adoption opens — opt in on your own schedule.

::note
Rev 3 settings live in **Organization Settings** (`/dashboard/org-settings`). ODP values are set from the places you already work — an assessment's parameters, a control's objective panel, or the policy editor — and appear anywhere DIBFI displays a control's details.
::

---

## Key concepts

### Rev 2 vs Rev 3

Revision 3 keeps the same intent as Revision 2 but restructures the catalog. At a high level:

| What changes | In practice |
| --- | --- |
| **Renumbering** | Requirements are re-identified (e.g. the `3.x.x` family gives way to `03.xx.xx` references). |
| **Reorganization** | Some Rev 2 controls are **merged**, some are **split**, a few are **dropped**, and new ones are **added**. |
| **Wording** | Many requirements are reworded or clarified even when the underlying expectation is unchanged. |
| **Parameters** | Rev 3 formally introduces **ODPs** — values each organization defines for itself (see below). |

::tip
Nothing about your Rev 2 assessment changes when you explore Rev 3. The transition feature is additive — it annotates and prepares, it does not rescore.
::

### Transition modes

Your Rev 3 experience is governed by a platform-wide phase, combined with whether your organization has opted in early.

| Mode | What you see |
| --- | --- |
| :badge[Preview]{color="neutral"} | Rev 3 is read-only — "here's what's coming." ODP values can be pre-recorded, but control dispositions aren't shown yet. |
| :badge[Early opt-in]{color="info"} | Once early adoption opens platform-wide, organizations that opt in see Rev 3 surfaced and editable alongside Rev 2. |
| :badge[Active]{color="success"} | Rev 3 is the operative standard for everyone — no opt-in required. |

::note
The platform-wide phase is set by DIBFI. Your opt-in only takes effect during the early-adoption window, but you can record it ahead of time so you're ready the moment it opens.
::

### Organization-defined parameters (ODPs)

Some Rev 3 requirements deliberately leave a value open for you to decide — how often you do something, which items are in scope, or how a control is applied in your environment. Those blanks are **organization-defined parameters**. Rev 3 expects you to fill them in, and DIBFI stores your choices so they flow into your requirement text, your policies, and your assessment.

Every ODP resolves in a fixed order:

| Source | Meaning |
| --- | --- |
| **Your value** | The value your organization set — always wins when present. |
| **Default** | The DoD/DFARS default value, used when you haven't set your own. |
| **Unset** | No value yet — the text shows a clear `[organization-defined]` placeholder instead of a broken blank. |

ODPs come in a few shapes, and DIBFI gives each the right kind of input:

| Shape | Example |
| --- | --- |
| **Single value** | A number, duration, or frequency — "every 90 days," "3 attempts." |
| **List** | A set of items — roles, event types, system components. |
| **Narrative** | Free text where the parameter calls for a description. |
| **Frequency with triggers** | A recurring period *plus* the events that also trigger the action — "annually, or when a significant incident occurs." |

### Control disposition

When Rev 3 is in view, each control carries a **disposition badge** that tells you, at a glance, what happened to it between revisions — with a plain-language note.

| Disposition | Meaning |
| --- | --- |
| :badge[Kept]{color="success"} | Carried into Rev 3 essentially unchanged. |
| :badge[Modified]{color="info"} | Wording or parameters changed, same intent. |
| :badge[Merged]{color="warning"} | Combined with other Rev 2 controls into one Rev 3 requirement. |
| :badge[Split]{color="warning"} | Divided into multiple Rev 3 requirements. |
| :badge[Dropped in Rev 3]{color="error"} | No direct successor requirement. |
| :badge[New in Rev 3]{color="info"} | Introduced for the first time in Rev 3. |

::note
Dispositions appear only once Rev 3 is surfaced for you — in early opt-in or active mode. In preview mode the badges stay hidden until you're ready to work with them.
::

---

## Using the feature

### Set an ODP value

You can record an ODP wherever a control's details appear — an assessment's parameters, a control's objective panel, or the policy editor. All three write to the same place, so a value you set once is consistent everywhere.

::steps{level="4"}

#### Open the parameter

Find the ODP on the control you're working. DIBFI shows its label, what the requirement is asking for, and the current default if you haven't set your own.

#### Choose your value

Enter the value in the input suited to its shape — a single value, a list, a narrative, or a recurring period with triggers. DIBFI stores one canonical value no matter which input you used.

#### Review the blast radius

Before you save, DIBFI shows **how many controls this change affects** — the Rev 3 requirement it belongs to and every Rev 2 objective that maps to it — so you understand the reach of the parameter.

#### Save

Your value takes effect immediately across your requirement text, policies, and assessment. Clearing a value simply falls back to the default.

::

::note
Every ODP change is recorded to your activity log along with the controls it touched, so there's an audit trail of who set which parameter and when.
::

### Opt in to Rev 3 early

When early adoption opens, you can start working in Rev 3 ahead of the platform-wide switch.

::steps{level="4"}

#### Open Organization Settings

Go to **Organization Settings** and find the Rev 3 transition section. It shows the current platform phase and your opt-in status.

#### Turn on early adoption

Opt in to surface Rev 3 alongside Rev 2 — dispositions become visible and Rev 3 requirements become editable for your organization.

#### Opt out any time

Turning the opt-in off returns you to the preview experience. Your recorded ODP values are kept either way.

::

::tip
You can record your opt-in during preview mode. It won't change anything visibly yet, but it means Rev 3 turns on for your team automatically the moment early adoption opens — no second trip to settings.
::

---

## Permissions

Access follows the standard role matrix.

| Capability | Permission |
| --- | --- |
| View Rev 3 status, dispositions, and resolved ODP values | *(any role that can read compliance data)* |
| Set or clear ODP values | :badge[UPLOAD_EVIDENCE]{color="info"} or :badge[MANAGE_POLICIES]{color="info"} |
| Opt your organization in or out of early adoption | :badge[MANAGE_ORG]{color="info"} |
| Set the platform-wide transition phase | :badge[Platform Admin]{color="warning"} |

Viewing Rev 3 information is open to everyone who can already read your compliance data. Setting an **ODP value** requires either the evidence or policy management permission, because a parameter feeds both. Opting in is an **organization-level** decision reserved for org admins, and the platform-wide switch is DIBFI-only.

::warning
The platform phase is a shared, industry-wide event — it is intentionally not something an individual organization can flip. Your controls are early opt-in and your own ODP values; the global switch to Rev 3 is managed by DIBFI.
::

---

## How it works

Extra detail on how the transition behaves — product behavior, not internals.

### One switch, read everywhere

Every Rev 3-aware surface reads the same effective mode: **active** for everyone once the platform switches, **early opt-in** while adoption is open and you've opted in, and **preview** otherwise. Because there's a single source, flipping the global phase transitions the whole application at once — your dashboards, assessments, and policies move together.

### How an ODP resolves

Whenever DIBFI needs to display a parameter, it resolves it the same way: your organization's value first, the DoD/DFARS default next, and a clear placeholder if neither exists. Requirement and objective text that contains a parameter is filled in with the resolved value inline, so you read a finished sentence — "…update the list annually and…" — rather than a raw blank.

### Knowing what a change touches

Because one parameter can drive many controls, DIBFI computes the **blast radius** of every ODP before you save it: the Rev 3 requirement it belongs to, that requirement's objectives, and every Rev 2 objective those map back to. That's the "this change affects N controls" confirmation, and the same list is written to your activity log with the change.

### How dispositions are determined

A control's disposition is read from the Rev 2 → Rev 3 crosswalk. Where a control fans out to several Rev 3 requirements it reads as **Split**; where several Rev 2 controls converge on one Rev 3 requirement it reads as **Merged**; controls with no successor are **Dropped**, and requirements with no Rev 2 origin are **New**. Each badge carries a plain-language note so a non-technical reader understands what happened.

---

## Related features

:::card-group

::card{title="Assessments" icon="i-lucide-clipboard-check" to="https://app.dibfi.com/dashboard/assessments"}
Work controls and objectives — where Rev 3 dispositions and ODPs appear in context.
::

::card{title="Document Library" icon="i-lucide-file-text" to="https://app.dibfi.com/dashboard/policy-templates"}
Policies pull in your ODP values so parameters read consistently across documents.
::

::card{title="Organization Settings" icon="i-lucide-settings" to="https://app.dibfi.com/dashboard/org-settings"}
Opt in to early Rev 3 adoption and see the current platform phase.
::

:::