A Prioritized Rev. 3 Remediation Roadmap, From Where You Actually Are

A project sized by your starting point, not by the requirement count

The natural way to size the Rev. 3 transition is arithmetic: count the requirements, count your gaps, multiply by an effort estimate. It produces confident numbers and wrong ones. The first article in this series walks through why — consolidation moved substance rather than removing it, organization-defined parameters turned defaults into decisions, and three new families wrote requirement language over ground Rev. 2 left implicit. The real size of your project is the distance between how your program operates today and what Rev. 3 examines — which means two contractors with identical gap counts can face projects that differ by a year.

Every section below carries a toggle, because the same work lands differently depending on where you sit. An OSC — Organization Seeking Certification — is the contractor whose contracts carry the requirements and who answers for them in an assessment. An ESP — External Service Provider — is the MSP, MSSP, or cloud operations partner running parts of the OSC's environment; in the CMMC ecosystem, the services an ESP performs and the assets it touches are examined as part of the OSC's scope, and how ESP assets are treated is determined by the current CMMC scoping guidance and the assessor — not by either party's assumptions. Pick your seat once; the choice applies to every section on this page and is remembered in this browser.

Find your profile

The profiles below are keyed to this site's seven-level maturity ladder — Absent → Documented → Configured → Deployed → Operating → Measured → Governed — because 'where are we, honestly?' is a ladder question, not a checklist question. If you have not placed yourself on that ladder recently, the scorecard is the fastest honest way to do it; the start-here guide explains the model.

Real organizations are blends — pick the row that describes most of your program and borrow from the others where they fit. And note the asymmetry in Profile C: the capability and the record of it sit at different rungs, and the posture an assessor can examine is the weaker of the two.

Profile A: the paper program

The candid description: your documentation was written to win work or pass a self-assessment, not to run a program. Most practices sit at Documented or below on the ladder, several are Absent, and the SSP describes an environment that has drifted since it was written. The trap for this profile is producing more paper — or buying tools — before anything operates. Rev. 3's hard parts (parameters you must justify, a supply chain program, monitoring cadence) all punish exactly that instinct, so the sequence below is deliberately narrow: convert a small number of things from Documented to Deployed and Operating, and let the writing follow the reality.

Start now

• Open the ODP register by harvesting, not deciding: export what your tenant, directory, and tools actually enforce today — lockout thresholds, timeouts, retention, scan frequencies — into the configuration baseline worksheet. Justifications come later; the inventory of reality comes first.
• Open the supplier register: list critical suppliers, integrators, and single-source components in the vendor risk assessment worksheet. This is the slowest-maturing artifact in the whole transition — see 03.17.01 — which is why it starts on day one even in a program with bigger fires.
• Name owners in a roles and responsibilities matrix — a register without an owner is a snapshot, not a program.
• Start the evidence index with entry number one dated today. Evidence discipline is free at the start of a program and expensive to retrofit.

By 60 days

• The asset inventory is deployed across its intended scope — the hardware and software inventory and the cloud and SaaS inventory, with support-status columns filled in. Everything else in the program depends on knowing what exists; the IT-02 practice guide is the operational companion.
• The SSP is being rebuilt as an operated document — named owner, version history, review cadence — using the SSP development worksheet; the PL family (03.15.01 through 03.15.03) examines exactly this discipline.
• Rules of behavior exist, are CUI-specific, one page, and actually signed — the cheapest visible win in the PL family.
• MFA coverage is mapped, exceptions and all, in the MFA deployment tracker. Mapping before remediating keeps the identity project honest; the IT-01 practice sets the direction of travel.

By 90 days

• The supplier register is operating: the supplier security questionnaire has gone out to the critical tier, and responses land somewhere with an owner.
• Monitoring coverage is mapped before any tooling purchase — the logging and monitoring coverage matrix usually shows the gap is unforwarded sources and absent review, not a missing SIEM.
• A vulnerability and patching cadence has begun at a pace you can sustain — the vulnerability register and patch tracker, run the way the IT-06 practice describes. Declared numbers you keep beat ambitious numbers you miss.
• The gap list is an honest POA&M with owners and dates, not a spreadsheet of aspirations.

By 180 days

• A short SCRM plan is written from the operating register — the five pages you follow, naming the register, the assessment cadence, the contract-terms approach, and the escalation path (03.17.01).
• The EOL register exists with replace-or-mitigate decisions per unsupported component — the discipline of 03.16.02 and the technical-debt practice.
• ODP register entries carry justifications, not just harvested values — each value either ratified as a risk decision or queued for change.
• A first internal self-assessment has been run with the internal assessment worksheet — not to score well, but to learn what retrieving evidence actually costs.

Profile B: the operating Rev. 2 program

The candid description: your controls genuinely run — patching happens, MFA is enforced, reviews occur — and evidence exists, even if retrieving it takes effort. On the ladder, most practices sit at Deployed or Operating; almost nothing is Measured. Your Rev. 3 project is the narrowest of the three profiles, and it is mostly the deltas: the ODP documentation layer, the SR, PL, and SA families, sharper monitoring language, and formalized shared responsibility. The trap for this profile is complacency — assuming an operating program transfers automatically. It transfers well, but the ODP layer in particular is documentation work that no amount of good operations does for you.

Start now

• Harvest the ODP layer and diff it: what the tenant enforces, what the SSP says, what any provider baseline imposes. At this profile the finding is usually contradiction, not absence — three sources, three values.
• Open the supplier register from what procurement already holds — vendor lists, contract files — into the vendor risk assessment worksheet; you are formalizing an instinct, not building from zero.
• Walk the Rev. 2 → Rev. 3 mapping against your SSP to build the actual delta list — consolidated requirements, moved requirements, and the genuinely new ground.

By 60 days

• The ODP register is populated with justifications and the conflicts from the diff are reconciled — each value ratified as a risk decision, with its enforcement point and evidence location recorded. Keep it beside the SSP, not inside it.
• SR scaffolding is drafted from the operating register: a short SCRM plan (03.17.01) plus security expectations entering supplier agreements at renewal (03.17.03); the OT-09 practice covers the component-provenance angle for manufacturers.
• The PL family is a formality check rather than a project: SSP ownership, version history, and review cadence made visible; rules of behavior refreshed and re-signed using the rules of behavior template (03.15.03).

By 90 days

• Monitoring cadence is declared and visibly lived: review frequencies and per-severity response times written down as your parameter choices, with dated review records accumulating — the coverage matrix shows where sources still leak past the net.
• Identity coverage extends into the corners: authenticator lifecycle records (03.05.12), legacy exceptions written and dated, and the MFA tracker reporting enrolled-and-enforced over active accounts rather than 'MFA is on'.
• Every external service has a completed responsibility matrix — the MSP/MSSP responsibility matrix per provider, with the who-evidences-what column filled in (03.16.03).
• Acquisition discipline is in the purchasing workflow: security questions asked before buying, recorded where 03.17.02 can find them.

By 180 days

• The core registers are climbing toward Measured: coverage and trend numbers in the security metrics register — the ladder rung where you can state a number and show its direction.
• An internal assessment against the Rev. 3 determination statements has been run with the internal assessment worksheet, including timed evidence-retrieval drills out of the evidence index.
• The EOL register operates with review dates — unsupported components carry replace-by dates or documented mitigations, per 03.16.02.
• The supplier register is producing follow-through: questionnaire responses reviewed, findings tracked, and at least one supplier conversation that changed something.

Profile C: the provider-dependent program

The candid description: an MSP or MSSP genuinely runs much of your security — patching happens, monitoring exists, identity is administered — but the documentation of the split is thin. On the ladder this profile is two positions at once: the capability may be Operating in the provider's hands, while your record of it — who does what, which parameter values apply, where evidence lives — is Documented at best and often Absent. The posture that can be examined is the weaker of the two, because accountability does not outsource. That is why this profile's sequence starts in a different place than the other two: not with any control, but with the shared-responsibility matrix.

Start now

• Complete the MSP/MSSP responsibility matrix with your provider, together, in one sitting — and do not leave the room until the who-evidences-each-control column is filled in; it is always the column that gets skipped.
• Inventory every provider and cloud dependency in the cloud and SaaS inventory — most provider-dependent programs discover they depend on more parties than the one they pay monthly.
• Request the provider's standing evidence package — their security posture, personnel access model, incident-notification terms, subcontractor list. How they respond tells you most of what the supplier questionnaire would.

By 60 days

• The ODP register exists with a provider column: for every parameter, whose value is enforced — yours, the provider's baseline, or a silent default nobody chose. At this profile the register is mostly a discovery document, and that is its value.
• The supplier register includes the provider itself, assessed like any other critical supplier in the vendor risk assessment worksheet — 03.17.03 reaches your most important supplier first.
• The agreement review is scheduled against the renewal date: incident notification with a clock, data location and return, subcontractor disclosure, evidence delivery — the terms 03.16.03 expects to find in writing.

By 90 days

• The oversight cadence is operating: a periodic review of the provider's reports, with a date and a note, filed in your evidence index — this record is what overseeing a provider looks like on paper.
• Identity is mapped across the boundary: your accounts and the provider's technician accounts in the privileged account inventory, coverage in the MFA tracker, and the provider's break-glass paths written down.
• The monitoring split is explicit: whose SIEM, whose retention clock, who reviews, where the review record lives, and what happens to your data at offboarding — mapped in the coverage matrix.

By 180 days

• Provider-supplied SSP contributions exist in writing: per service, a provider-authored description of how their share of each area is implemented, reviewed and dated — folklore retired.
• The retained-capability decision is made and staffed: whatever else is delegated, the registers, the oversight cadence, and the evidence index stay in-house, because they are the program's memory.
• A first joint internal assessment has been run with the internal assessment worksheet, sampling both sides of the matrix — the fastest way to find the controls each side assumed the other was evidencing.
• Offboarding terms are documented before you need them: data return, log export, credential revocation, and transition support — the questions that are unanswerable during a dispute get answered now.

Sequencing principles that hold at every profile

Three rules generated every ordering decision above, and they will generate yours when your situation does not match any profile cleanly.

1. Start what is slow to mature. The ODP register and the supplier register open on day one at every profile — not because they are urgent but because they are slow: supplier relationships, parameter ratification, and register history accumulate in quarters. Tools install in days. Sequence by maturation time, not by visibility.
2. Do not buy tools before cadences. A platform without a declared review frequency and a named reviewer produces a new kind of gap: recorded, timestamped proof that nobody was looking. Map coverage first, declare the cadence you can sustain, and only then let tooling close the measured remainder.
3. Evidence from day one. The operating history that matters at examination time is the one that started accruing when the work started — an evidence index opened in the first week costs nothing, and one reconstructed later reads exactly like what it is. Write the record as you go, and let the documents describe what the record shows.

One more, implicit in all three: order by leverage, not by deadline. The day markers in this article survive policy-timeline shifts precisely because nothing in them is pegged to a date — each phase exists because its artifacts unblock the next phase's work, under Rev. 3, under Rev. 2, and under whatever the policy status page says next quarter.