What changed between NIST 800-53 Rev. 4 and Rev. 5
If a contract, agency or FedRAMP requirement now points to NIST SP 800-53 Rev. 5, the short answer is that NIST withdrew Rev. 4 on 23 September 2021, and Rev. 5 is the current catalog. NIST maintains Rev. 5 through numbered releases, and Release 5.2.0 of 27 August 2025 is the current release, so a control mapping built against Rev. 4 needs to be re-run against the Rev. 5 control identifiers before anyone cites it in a submission.
The practical impact depends on three things you already own: your control mapping, your system boundary and your documentation. A Rev. 4 mapping that is still accurate in substance can be carried forward with new identifiers, while controls whose wording was restated around outcomes will need a fresh look at what evidence they now require. Privacy controls that once sat in an appendix now sit in the main catalog, so a program that tracked privacy separately should confirm which Rev. 5 controls carry that work. The sections that follow walk through each of these changes.
Start by confirming which revision and which release your contract or authorizing body names, and whether it expects a specific Rev. 5 release or simply the current one. Then ask your assessor or authorizing official how they will treat controls added or revised after your last assessment, since later releases such as 5.2.0 changed some software update and patch controls. Record the answer in your plan of action and milestones so the decision is documented rather than assumed.
How the catalog structure changed in Rev. 5
Rev. 5 removed the responsible entity, such as the system or the organization, from most control statements. A Rev. 4 control often said that the organization must do something. A Rev. 5 control states the outcome, and the question of who performs it moves to the implementation and assessment layer. For a program, this means a single requirement can be satisfied by a system feature, a process, or a combination of both, and the documentation has to say which.
- Ownership moves out of the statement: Rev. 5 statements describe what must be true, so your system security and privacy plan must name who implements each control.
- Mapping changes shape: A Rev. 4 requirement mapped to a single control may now map to an outcome that several controls share, so crosswalks written against Rev. 4 need rechecking.
- Assessment depends on SP 800-53A: The assessment procedures in SP 800-53A are where the responsible party and the expected evidence are spelled out for each control.
- Evidence must show the actor: An assessor still needs to see who performed the control, so logs, tickets and sign-offs should identify the role or system involved.
- Parameters carry the specifics: Organization-defined parameters let you state frequencies and thresholds in your own plan rather than in the control text.
Before you rely on an older mapping, confirm with your assessor which Rev. 5 release and which assessment procedures they will use.
Rev. 4 kept privacy controls in a separate appendix, Appendix J. Rev. 5 integrates security and privacy controls into one consolidated catalog. IRS Publication 1075 notes that the privacy controls previously in Rev. 4 Appendix J are fully integrated into the Rev. 5 controls, and that the publication updated its own control section to align with Rev. 5. Programs that handle both security and privacy requirements now work from one control identifier set instead of two.
- One identifier set: Privacy-related requirements sit alongside security controls in the same families, so one control record can carry both purposes.
- Appendix J references need updating: Policies, contracts and evidence indexes that cite Appendix J should point to the Rev. 5 control identifiers.
- Privacy baseline is selected separately: SP 800-53B defines a privacy baseline that applies regardless of impact level, so integration does not mean every privacy control applies to every system.
- Shared evidence can serve both purposes: A single access review or audit log set may now satisfy security and privacy controls, but the record must show both uses.
- Agency rules still govern: Requirements from agencies such as the IRS are written against their own publications, so confirm which Rev. 5 control set your contract cites.
Check whether your contracts and data handling agreements refer to Appendix J, and map those references to current Rev. 5 identifiers.
Rev. 5 added state-of-the-practice controls for cyber resiliency, secure systems design, and security and privacy governance and accountability. It also introduced the supply chain risk management family, SR, as a new family. These additions reflect practices that were not yet standard when Rev. 4 was written. For a program, they add control work that may not appear in an older security plan at all.
- Cyber resiliency: Controls in this area ask how the system keeps operating and recovers under attack, so recovery design and testing records become assessment evidence.
- Secure systems design: Design-level controls require architecture decisions to be documented and traced, which affects architecture reviews and design artifacts.
- Governance and accountability: Organization-wide program controls, which sit in the PM family, require program-level documents that individual system plans do not provide.
- Supply chain risk management: The SR family asks for a supply chain plan, supplier assessments and component provenance, which are often new deliverables for an existing program.
- Gap analysis: Compare your current Rev. 4 based evidence against these new areas first, since they usually need new owners and new records.
Confirm the exact control identifiers and their current release in the CPRT or OSCAL content before you scope the gap work.
Which new controls and families affect your mapping
Moving from Rev. 4 to Rev. 5 changes the catalog your mapping points to, not just the text behind each control. The three changes below touch control identifiers, where baselines live and which families you must now account for, so each one reaches your SSP, evidence index and assessment plan.
New supply chain risk management family
Rev. 5 added the SR family, which covers the supply chain risk management plan, supply chain controls, provenance, acquisition strategies, supplier assessments, notification agreements, tamper protection, component authenticity and disposal. Rev. 4 had no equivalent family, so supplier and component evidence that once sat under acquisition or configuration controls now needs its own mapping rows. Check whether your SSP names an SCRM plan owner and whether vendor assessments and component provenance records are indexed against SR controls.
Baselines moved to SP 800-53B
Rev. 4 combined the catalog with baseline selection, while Rev. 5 places the low, moderate, high and privacy baselines and tailoring guidance in SP 800-53B. Your mapping now has two sources: the control catalog for what each control requires and the baseline profile for which controls and enhancements your system must implement. Update the baseline reference in your SSP so it cites SP 800-53B, and confirm that each control in your selection traces to the correct baseline profile.
Leading-zero control identifiers
Release 5.1.1 introduced leading zeros in control identifiers, so AC-1 now appears as AC-01 in NIST's CPRT and SP 800-53A labels. Any evidence index, scanner rule, GRC import or assessor workpaper that keys on the old format will fail to match, even when the content is the same. Run a find-and-replace audit across your mapping files and confirm that both formats resolve to one record so historical evidence still traces to current controls.
New IA-13 control in identification
Release 5.1.1 added IA-13 along with three enhancements, so identification and authentication mappings built from the original Rev. 5 text are incomplete for the current release. Add IA-13 and its enhancements to your IA mapping, assign an owner and confirm which system components the control applies to. Record the release you assessed against so an assessor can see which IA entries were in scope at the time.
Release-aware mapping records
Rev. 5 has received numbered releases since its 2020 publication, and Release 5.2.0 added SA-15(13), SA-24 and SI-2(7) along with revised SI-7(12) and updates to several discussions. A mapping built against one release can silently miss new enhancements or cite outdated discussion text. Store the release number on every mapping file, and check the OSCAL catalog when you refresh so new SA, SI and related entries are reviewed by an owner.
How the numbered releases changed Rev. 5 after 2020
This sequence shows how NIST has kept SP 800-53 Rev. 5 current since 2020 through numbered releases, so a program can tell which catalog, baseline and assessment content applies to its assessment date and which changes need action.
Start from the September 2020 Rev. 5 baseline
Rev. 5 was published in September 2020 and updated as of 10 December 2020. This is the reference point for every later release. Your team should record the exact revision it is working from, such as the publication date and update date, in the system security and privacy plan so later comparisons are unambiguous. The check that closes this step is a written statement of the catalog version in use, which the assessor can trace to the NIST publication page for SP 800-53 Rev. 5.
Adopt the numbered release model
NIST moved away from one-off revisions and now issues changes as numbered releases. Compliance, GRC and engineering leads should understand that a release can change control text, enhancements or assessment procedures without a new revision name. Assign one owner to track CSRC announcements and record which release each control inventory and evidence set references. The step is complete when that owner has a documented tracking process and a current release identifier in the control inventory.
Apply Release 5.1.1 identifier and control changes
Release 5.1.1, dated 7 November 2023, added IA-13 and three enhancements and introduced leading zeros in control identifiers, so AC-1 now appears as AC-01 in CPRT and SP 800-53A labels. Update control matrices, evidence index keys, scanner mappings and GRC tool records so that AC-1 and AC-01 point to the same requirement. The check is a reconciliation report showing every identifier changed and the IA-13 and enhancement entries added to the inventory.
Review Release 5.2.0 software and patch changes
Release 5.2.0, dated 27 August 2025, is a minor release issued in response to Executive Order 14306 with a focus on software update and patch security. It added SA-15(13), SA-24 and SI-2(7), revised SI-7(12), updated several discussions, and updated related controls including AU-2, AU-3, CA-7, IR-4, IR-6, IR-8, SA-15, SI-2 and SI-7. Security, engineering and vendor management teams should read these controls against current patching and software acquisition practice and decide which new evidence is needed. The step closes when each added or revised control has a named owner and a documented gap decision.
Confirm SP 800-53B baselines are unchanged
SP 800-53B Release 5.2.0, issued on the same date as the 5.2.0 catalog, made no baseline changes. The low, moderate, high and privacy baseline selections therefore stay as they were, even though individual controls in the catalog were updated. Program owners should confirm this in their baseline documentation and note that new enhancements such as SA-24 are a catalog change to assess for whatever baseline the system already uses, not a change in baseline membership. The check is a baseline record that cites the 800-53B release and states that no selection changed.
Map new assessment procedures to SP 800-53A
SP 800-53A Release 5.2.0 provides assessment procedures for the updated controls, using determination statements and examine, interview and test methods. Assessment leads should compare the procedures for AU-2, AU-3, CA-7, IR-4, SA-15, SI-2 and SI-7 against the previous version and update test plans where objectives changed. The step closes when the assessment plan references the 5.2.0 procedures for each updated control and the differences are logged for the assessor.
Pull current OSCAL content and record the release
NIST publishes the SP 800-53, SP 800-53A and SP 800-53B content in CPRT and as OSCAL JSON, XML and YAML in the usnistgov/oscal-content repository. Engineering teams that automate control documentation should pin the release they ingest, and the OSCAL content repository's v1.5.0 release, dated 13 May 2026, upgraded the 800-53 content to OSCAL 1.2.2. Confirm that your tooling reads that version and that the import is validated against the catalog. The step closes when a versioned copy of the catalog and baseline profiles is stored with a recorded hash and date.
State the current release and re-check in-scope systems
As of October 2026, the current release is 5.2.0, dated 27 August 2025. Confirm this against CSRC before each assessment or contract submission, because NIST may issue later numbered releases. For each in-scope system, compare the release recorded in its security plan with the current one, document the delta in an assessment or plan of action and milestones entry, and set the next review date. The step closes with a signed release-currency statement for each authorization package, which the authorizing official and independent assessor can review.
What the migration work costs in effort, and who does it
Moving from Rev. 4 to Rev. 5 is mostly a documentation, mapping and evidence exercise, not a rebuild of technical controls. Each component below has a clear owner, and the split matters because the organization keeps the control decisions and risk acceptance while a partner can prepare the systems and evidence an assessor will examine.
Control mapping across the catalog
Map every Rev. 4 control your program cites to its Rev. 5 successor, since many controls were consolidated, renamed or reworded and privacy controls moved into the main catalog. The organization owns the mapping decisions, and a partner can draft the crosswalk from NIST's OSCAL content and flag where a Rev. 4 requirement no longer has a one-to-one match. Check that each mapped control still addresses the same risk.
Policy and procedure updates
Rev. 5 statements are written as outcomes and no longer name the responsible entity, so existing policies that assign duties by control statement need rewording and clear ownership. Update the system security and privacy plan, rules of behavior and control implementation statements to match the new control identifiers and parameters. The authorizing official and control owners must approve the revised documents, which keeps this work inside the organization.
New supply chain risk management evidence
The SR family is new in Rev. 5, so programs that never had supply chain risk controls must produce an SCRM plan, supplier assessments, provenance records and disposal evidence from scratch. This is often the largest new body of work. The organization decides its supplier risk tolerance and accepts residual risk, while a partner can build the collection process, templates and evidence repositories.
Privacy control evidence
Privacy controls from the former Rev. 4 Appendix J now sit in the main catalog, and the privacy baseline in SP 800-53B applies regardless of impact level. Programs that treated privacy as a separate document set need evidence for PT and related controls, such as privacy notices, purpose specifications and PII processing records, mapped to system boundaries. Privacy officers keep decisions on processing authority, and implementers gather the records.
Reassessment under SP 800-53A
Assessment procedures in SP 800-53A are organized around each Rev. 5 control, so an assessment performed against Rev. 4 does not carry over as written. Plan a reassessment scope that covers changed and new controls, and confirm with the authorizing official which findings from the earlier assessment remain valid. Only an independent assessor issues assessment results, and the authorizing official alone makes the authorization decision.
Authorization and ownership boundaries
Agree in writing who signs what before work starts: the organization owns its controls and risk decisions, a partner prepares systems, mapping and evidence under a fixed scope, and an independent assessor or authorizing official issues the results and decisions. Ask any partner to confirm it will not sign assessment results, and confirm your assessor's independence rules. Keep the written scope as the reference for every later handover.
Where to confirm the current Rev. 5 release before you map
Before you build a Rev. 4 to Rev. 5 mapping, confirm which Rev. 5 release your contract, agency or authorizing body expects, because NIST now issues changes as numbered releases rather than a single static revision. The authoritative place to check is NIST's Cybersecurity and Privacy Reference Tool (CPRT), where SP 800-53, SP 800-53A and SP 800-53B Release 5.2.0 are published. Pull the control text from the official SP 800-53 Rev. 5 publication page and record the release identifier in your mapping workbook so every row can be traced to a specific version. Note that CPRT labels use leading zeros, so AC-01 is the same control you may know as AC-1.
For machine-readable work, use the usnistgov/oscal-content repository on GitHub. Its catalog files for the 800-53 content are published as OSCAL JSON, XML and YAML, and a script that reads the catalog can confirm the release version and the control identifiers in the file it loads. The repository's v1.5.0 release, dated 13 May 2026, upgraded the 800-53 content to OSCAL 1.2.2, so check that your parsing tools support that OSCAL version before you rely on their output. Compare the catalog's withdrawn flags against your Rev. 4 list rather than assuming identifiers carried over unchanged.
Confirm the required release and any agency-specific version with the contract, the authorizing official, the agency's security office or the FedRAMP rules that apply to your authorization. Those parties decide which release and which parameter values count as compliant, and no public source can settle that for you. If you also map to the CSF 2.0 crosswalk in NIST's OLIR catalog, use it only as NIST marks it: a final, NIST-developed mapping that NIST itself describes as not comprehensive. Treat its entries as a starting point for your own review, and document any control with no crosswalk entry as a gap to assess directly.
Questions buyers ask about moving from Rev. 4 to Rev. 5
Can we still use Rev. 4 for new work?
Usually not for new work, but the answer depends on the authority that requires the framework, so confirm it in writing before you start. NIST withdrew SP 800-53 Rev. 4 on September 23, 2021, and lists Rev. 5 as its replacement. A contract, agency or program office may still name Rev. 4 in an older agreement, or may accept a transition period for systems already in flight. Ask the requiring authority which revision applies to the new authorization, the renewal and any significant change, and get the answer in the contract file. Your partner can map your current controls to Rev. 5 only after that revision is confirmed.
Does moving to Rev. 5 require a new authorization?
Whether a move to Rev. 5 triggers a new authorization is a decision for the authorizing official and the requiring authority, not for the implementation team. Authorization is tied to the system and its risk, so a change in control revision may or may not count as a significant change under the program's rules. Ask the authorizing official how the revision change will be recorded in the authorization package, what reassessment they expect, and whether an update to the system security and privacy plan is enough. Expect the revision change to be documented as a change to the control baseline and assessment basis, with the plan of action and milestones covering any gaps.
How much of our existing Rev. 4 evidence carries over?
Much of the evidence carries over because most Rev. 5 controls keep the same subject matter, but the mapping is not one to one, so each artifact needs review. Policies, system security plans, configuration baselines, vulnerability scan reports, access reviews and incident records usually remain useful, while the control identifiers, parameter values and assessment language change. Rev. 5 also adds controls such as the supply chain risk management family, and it moves privacy controls into the main catalog, so those areas may have no Rev. 4 evidence at all. Ask your assessor which artifacts they will accept under the new procedures and which will need refreshing.
Are privacy controls mandatory in the main catalog now?
Privacy controls are now integrated into the consolidated Rev. 5 catalog, so they appear alongside security controls, but being in the catalog does not by itself make every privacy control apply to your system. Which controls apply depends on the baseline you select. SP 800-53B defines a privacy baseline that applies regardless of impact level, and your security baselines select from the catalog according to the system's impact. IRS Publication 1075 notes that the privacy controls previously in Rev. 4 Appendix J are fully integrated into the Rev. 5 controls, which is a useful example of how a regulator reads the move. Confirm with your authority whether the privacy baseline is required for your system.
Can our own team make the move without an outside partner?
Yes, an internal team can do the move if it has people who know the system, the control catalog and the requiring authority's expectations. The work includes confirming the revision, mapping controls, updating the system security and privacy plan, refreshing evidence and preparing for assessment. The cost drivers are the size of the system boundary, the number of inherited common controls and how much of the evidence is already automated. Whatever you choose, the organization owns its controls and decides risk. An outside partner can prepare systems and evidence, but only an independent assessor issues the assessment results that an authorization relies on.
What must we provide to an implementation partner?
A partner needs enough written context to scope the work and avoid guessing at your risk decisions. Prepare the current system security and privacy plan, the most recent assessment report, the plan of action and milestones, the system boundary and architecture diagrams, the inventory of components and the list of common controls inherited from other providers. Also provide the security categorization, the baseline and any tailoring already agreed, and written confirmation of the revision the requiring authority expects. Access to the environment, named technical owners and a decision-maker who can approve scope changes will shorten the engagement and keep it fixed scope.
Which Rev. 5 changes affect our evidence most?
The biggest effects usually come from the outcome-based wording, the new supply chain family and the separation of baselines into SP 800-53B. Outcome-based statements remove the responsible entity from many control statements, so your documents must show who performs each activity in your system. The new SR family asks for supply chain evidence that Rev. 4 did not require in that form. Baseline selection now draws on SP 800-53B, so the control set your assessor tests may differ from the one you assessed before. Review each control's determination statements in SP 800-53A before you decide what evidence to produce.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so the Rev. 4 to Rev. 5 move can be mapped to the systems, controls and evidence you actually run. We prepare the systems and documentation, while your organization keeps ownership of its controls and any authorization decision.
How we scope
- We inventory which systems, control statements and evidence files still reference Rev. 4 numbering or the responsible-entity wording removed in Rev. 5.
- Engagements are fixed-scope, so the written scope names the systems, control families and deliverables covered by the Rev. 5 update.
- We agree in writing whether SR supply chain controls, privacy controls and the Release 5.2.0 SA-15(13), SA-24 and SI-2(7) additions are in scope.
How we build
- We map existing Rev. 4 control implementations to Rev. 5 identifiers and record where a control was split, consolidated or newly added.
- We configure and document the self-hosted platforms in your cloud accounts, data centers or air-gapped networks to produce the evidence the Rev. 5 control statements call for.
- We test the implemented controls with the methods in SP 800-53A, and report gaps for your team to decide how to close them.
How we hand over
- You receive the updated control mapping, system configurations, procedures and evidence outputs organized by Rev. 5 control ID.
- We document which decisions belong to your organization, such as tailoring choices, risk acceptance and the authorizing official's decision, so ownership stays clear.
- Assessment by an independent assessor is not performed by DeployOpen, so we prepare the package that such an assessor would review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which covers later numbered NIST releases such as future 5.x updates.
- Confirm with your team which NIST release your contract or agency references, since the current release differs from the one used during the initial move.
- We can rerun the mapping and tests when NIST publishes changes, with the scope of each update agreed in writing beforehand.
