NIST SP 800-53 Rev 5 Controls Course — RMF Coach

Lesson 1 — What the Catalog Is (~9 min)

Start here: what SP 800-53 actually is, and why every RMF program leans on it.

Explain what security & privacy controls are and how the SP 800-53 catalog supports risk management.

You're handed a new system — MCMS, a case-management system that holds people's benefit records — and asked a simple question: what protects it?

You could invent safeguards from scratch, but every organization would invent something different, and no assessor could check your work against a common standard. Instead, NIST publishes a catalog of security and privacy controls — SP 800-53 — that everyone selects from.

This lesson is the orientation: what that catalog is, what a "control" even means, and why the whole Risk Management Framework leans on it.

A control is a standardized way to express a safeguard or protection measure that achieves a security or privacy objective. "Standardized" is the key word: because everyone uses the same catalog, a control means the same thing across agencies and systems.

Controls can be technical (a system setting), administrative (a policy or procedure), or physical (a locked door) — often a mix. In the RMF, controls are selected, implemented, assessed, and monitored to protect an organization's operations and information, make systems more resistant to attack, and limit the damage when an attack lands.

That's the job of the catalog: a shared vocabulary of protection you draw on instead of starting from zero.

SP 800-53 is a comprehensive catalog of outcome-focused controls for managing security and privacy risk as threats and vulnerabilities keep evolving.

It directly powers two RMF steps: Select (choose the controls) and Implement (put them in place). It's deliberately broad — it works for any size organization, any sector, and any platform, from ordinary servers to cloud, mobile, IoT, and industrial control systems. And it complements other frameworks like the NIST Cybersecurity Framework and Privacy Framework.

The word outcome-focused matters: a control says what protection to achieve, not which product to buy — so it stays neutral across technologies and vendors.

The catalog is for everyone in the risk program, not just security engineers. System owners, ISSOs, security and privacy officers, control assessors, authorizing officials, risk and oversight staff, and senior agency officials all rely on it — as do the vendors whose products end up inside agency systems.

Why so broad? Because the catalog touches the whole RMF life cycle: controls are selected and implemented against it, assessed against it (via SP 800-53A), and monitored over time. Whatever your role, you're reading from — or writing to — the same catalog.

If the RMF steps themselves are fuzzy, the RMF (SP 800-37) course is the companion to this one.

Lesson 2 — Requirements vs. Controls (~11 min)

The distinction the whole catalog rests on — and the one that makes an SSP line testable.

Tell a requirement from a control, and a security control from a privacy control, when writing the SSP.

Dana, the ISSO on MCMS, adds a line to the system security plan:

"The system restricts access to authorized users."

Her lead reads it and asks one question — "Is that a requirement, or a control?" — and she pauses. The same phrase, restrict access, shows up in the law that applies to MCMS, in the SP 800-53 catalog she selects from, and in the actual configuration she'll build. Depending on which she means, the line belongs in a different place and a different person verifies it.

Hold the question. By the end of this lesson you'll answer it without hesitating — and you'll write the line so an assessor can test it.

A requirement is an obligation you must meet. In federal security and privacy policy, requirements are the obligations imposed on agencies by public laws, regulations, executive orders, and government-wide policies — for example, OMB Circular A-130 imposes a whole set of them.

Requirements also come in a broader sense: an organization defines its own enterprise- or system-specific requirements — protection needs, hardware/software/firmware specifications, configuration details — and some arrive in a contract's statement of work.

The common thread: a requirement is the what — the obligation or need. You don't invent it and you can't skip it; it's imposed or defined for you.

A control is the safeguard you implement to meet a requirement. Controls come from the SP 800-53 catalog and can be technical, administrative, and/or physical — and they're policy-, technology-, and sector-neutral, so they fit any environment.

So on MCMS, "restrict access to authorized users" is the requirement (the obligation). The catalog controls that satisfy it are the how: account management (AC-2), access enforcement (AC-3), and least privilege (AC-6), among others.

That's the fix for Dana's SSP line. Instead of restating the obligation, she names the controls and how each is implemented — accounts under AC-2, role-based enforcement under AC-3, least privilege under AC-6 — so the line is specific enough to test. Managing risk can even go beyond any single control.

The catalog holds two kinds of control. Security controls protect information and systems from unauthorized access, use, disclosure, disruption, modification, and destruction — they guard confidentiality, integrity, and availability. Privacy controls address the risks of processing PII across its whole life cycle: creation, collection, use, storage, dissemination, disposal.

For MCMS, which holds benefit records, both apply. Selection produces an agreed-upon set of controls matched to mission needs and risk tolerance, documented in the system security plan and privacy plan (separate or combined).

Controls chosen to serve both objectives need real collaboration between the security program (Dana's side) and the privacy program (Tom, the SAOP) so neither objective is missed.

Security and privacy aren't separate silos — they overlap. NIST's Privacy Framework shows it as a Venn diagram: in the middle are cybersecurity-related privacy events — problems individuals could suffer from how a system operates, from embarrassment and stigma to discrimination, economic loss, or physical harm.

Controls throughout the catalog address both the cybersecurity risks of unauthorized activity and the privacy risks of authorized PII processing. So a control like access enforcement protects the data (security) and limits who can see people's records (privacy).

The practical lesson for MCMS: don't treat privacy as an afterthought. Many of the controls you select will be doing double duty, and you choose them deliberately to cover that shared zone.

Worked example — Dana fixes the MCMS access line.

The requirement is "restrict access to authorized users." Dana doesn't restate it. She asks who imposed it (federal law and policy → it's a requirement, not optional), then how MCMS meets it, and writes three concrete SSP lines:

Accounts are provisioned, reviewed, and removed under AC-2.

Access is enforced by role under AC-3.

Permissions follow least privilege under AC-6.

Each line names a control and how it's implemented on MCMS — so Priya (the assessor) has something concrete to test. The artifact Dana just produced is the SSP: the place selected controls and their implementation are documented.

Lesson 3 — Anatomy of a Control (~10 min)

Open one control and read every part — identifier, base text, enhancements, ODPs.

Read a control end to end: identifier, name, base control, discussion, enhancements, and ODPs.

Every control has the same anatomy. The control identifier (e.g., AC-2) is numbered in the order it was added — order implies no importance. The control name states the topic. The base control text is a set of outcome-based statements to implement at the organization or system level — these are the basis for the specific requirements the system owner designs and builds.

A discussion section adds context: it defines terms, gives insight into the control's objective, and often includes examples of how the statements can be interpreted. A related controls list points to others that reinforce it.

One convention worth knowing: the first control in every family, the -1 (e.g., AC-1), is always about the policies and procedures that make the rest of the family effective.

Most controls have enhancements — add-ons that strengthen the base. An enhancement is written as the base id plus a number in parentheses: AC-2(1) is the first enhancement of AC-2.

Enhancements are never selected on their own; they ride on their base control. And the catalog changes over time: a base or enhancement can be withdrawn (marked "W") when its content is folded into another control. Crucially, withdrawn numbers are never renumbered or reused — so the identifiers in your SSP stay stable over the life of the system.

That stability is the point of the numbering: AC-2 means AC-2 forever, even as the catalog evolves around it.

Many controls contain an organization-defined parameter (ODP) — an open slot, written as an [Assignment] or [Selection], that you fill with a specific value.

For example, AC-2 might say accounts are reviewed "[Assignment: organization-defined frequency]." On MCMS, Dana fills that with "every 30 days." Until she does, the control isn't fully specified — and (as the assessment course shows) an undefined ODP makes the control not assessable.

ODPs are how an outcome-neutral catalog adapts to your system: the catalog sets the what, and your ODP values set the concrete how much / how often / which for your environment.

Lesson 4 — How the Catalog Is Organized (~9 min)

Twenty families, an alphabetical scheme with history, and a catalog that keeps moving.

Navigate the catalog by family, read the summary table, and handle catalog updates.

The catalog is organized alphabetically by control family. The original families come from FIPS 200, which named 17 security-related areas and the minimum requirements for each. Since then, three families were added: Program Management (PM), PII Processing and Transparency (PT) for privacy, and Supply Chain Risk Management (SR) — for 20 families today.

The family acronyms are alphabetical by the acronym chosen when the family was introduced — which is why some look dated. CA once meant "Certification, Accreditation, and Security Assessments"; the family is now "Assessment, Authorization, and Monitoring," but the CA id is kept so control identifiers stay consistent across the catalog's history.

Tap any family to see what it covers — that grid is your index into the whole catalog.

Appendix C of SP 800-53 is a summary table of every family's controls. Each base control has a number; each enhancement is the base number plus a parenthesized id. Numbers reflect when a control was added — again, not priority or sequence.

The "Implemented By" column carries quick markers. A "W" means the item was withdrawn (its content usually folded elsewhere; the number is retired, never reused). An "S" means it's typically a system/technical implementation; an "O" means it's typically an organizational/non-technical one.

Those markers let you scan a family and immediately see what's active, what's technical vs organizational, and what's been retired.

The catalog isn't frozen. Controls change as the understanding of how to manage security and privacy risk improves, and as laws, executive orders, regulations, policies, and standards change. Guidance is revised to match.

The single best habit: work from the current version. NIST's Cybersecurity and Privacy Reference Tool (CPRT) publishes the entire SP 800-53 catalog online — controls, enhancements, and the latest updates — and the RMF project site tracks changes.

Before you select or cite a control, confirm you're reading today's text, not last revision's printout. (This is exactly why this course carries a content as of date.)

Lesson 5 — Who Implements a Control (~9 min)

The same control can be yours, inherited, or split — and that decides who's accountable.

Assign a control to the right implementation approach: common, system-specific, or hybrid.

A control isn't only what to do — it's also who does it. There are three implementation approaches, and each splits responsibility for development, implementation, assessment, and authorization differently.

Common (inheritable) controls are implemented once and inherited by many systems. System-specific controls are built and owned by a single system. Hybrid controls are split — part provided centrally, part by the system.

For MCMS, choosing the approach per control is a real decision: it determines whether Dana builds it, inherits it from the platform, or does part of each — and therefore who an assessor talks to about it.

Common controls can be inherited by many systems, business units, or missions. A common control provider owns the full life cycle — development, implementation, assessment, authorization, and monitoring — and makes the results available so system owners can rely on them.

The upside is real: organization-wide services like email or anti-virus give cost and security benefits from a single managed solution. But there's a caution NIST states plainly: a common control is also a single point of failure — if it's weak, every system that inherits it is affected at once.

So inheriting isn't automatically the safe choice. MCMS inherits platform controls where that's sound, but Dana confirms the provider's protection actually covers MCMS's risk before relying on it.

Lesson 6 — Trustworthiness & Assurance (~7 min)

Controls earn trust two ways: they do the job (functionality) and you can show it (assurance).

Explain how functionality and assurance build trust, and how assessment validates it.

Why do controls matter to leadership? Because they build trust. A system is trustworthy when users and managers have confidence that mission and operational requirements are being met — that the system works correctly and provides reasonable protection for the data it collects, stores, processes, and transmits.

That trust has two ingredients. Functionality — the controls actually do their job. And assurance — there's a structured basis for believing they do. Selecting and effectively implementing the right controls is what provides both.

A control that works but can't be shown to work doesn't build trust; neither does paperwork with nothing behind it. You need both.

Where does assurance come from? From assessment. SP 800-53A provides the procedures to evaluate whether implemented controls are implemented correctly, operating as intended, and producing the desired outcome.

That three-part test is the validation behind trust: it turns "we implemented the controls" into "we have evidence the controls work." The authorizing official accepts risk on that evidence, not on assertion.

So the catalog (this course) gives you the controls; 800-53B baselines them by impact; and 800-53A assesses them. Selecting and implementing well here is what makes a clean assessment possible later — the next course in the path.

Lesson 1 — Access & People (~11 min)

The families that decide who gets in and whether they can be trusted.

Explain the AC, IA, AT, PS, and PE families and their key controls.

Module 2 tours all 20 families. We'll go theme by theme rather than straight down the alphabet, so the families that work together are learned together.

This first group is access and people — the families that decide who gets in and whether they can be trusted: Access Control (AC), Identification and Authentication (IA), Awareness and Training (AT), Personnel Security (PS), and Physical and Environmental Protection (PE).

Tap any family in the grid to drill into its controls as we go.

Access Control (AC) limits who — and what processes — can use a system, and what they can do. It addresses both security and the security/privacy overlap where PII must be protected.

The anchors: Account Management (AC-2) governs how accounts are requested, approved, and assigned to roles; Least Privilege (AC-6) limits each user (or process) to only the access and transactions their role genuinely needs; and Access Enforcement (AC-3) enforces those rules at run time. Further controls curb abuse of authorized access.

AC is usually where an SSP's "who can do what" story lives.

Identification and Authentication (IA) establishes who or what is trying to connect, before any access is granted. Where AC defines the rules, IA verifies identity as the prerequisite to applying them.

Users inside the organization (IA-2) and outside it (IA-8) submit an identifier (IA-4) and an authenticator (IA-5) — and devices and components authenticate too. Only after identity is verified does AC decide what that identity may do.

Think of IA as the checkpoint and AC as the rulebook: identity first, then authorization.

Awareness and Training (AT) ensures everyone understands the security and privacy policies for using information resources. As NIST puts it, users are the largest audience in any organization and the single most important group for reducing unintentional errors and vulnerabilities.

Literacy Training and Awareness (AT-2) makes sure all individuals understand the basic requirements. People with elevated privileges or special risk responsibilities get more thorough role-based training.

It's easy to forget training is a control — but a workforce that knows the rules prevents the mistakes no technical control can.

Personnel Security (PS) sets the criteria for trusting the people who hold access. Personnel Screening (PS-3) confirms individuals are suitable for access given the risk of their position and responsibilities (PS-2, PS-9).

Access Agreements (PS-6) capture a signed acknowledgement that someone has read, understood, and agreed to the rules — and understands the sanctions (PS-8) for violating them. (A Rules of Behavior, PL-4, is one such agreement.)

PS is the human side of access: technical controls assume the person behind the account was vetted and bound to the rules — PS is what makes that assumption true.

Physical and Environmental Protection (PE) addresses the risk of unauthorized physical access to where systems operate — the mirror image of AC, in the real world.

Like logical access, physical access needs authorization (PE-2), control measures like keys and electronic locks (PE-3), and monitoring of their use (PE-6). Visitors may be allowed when escorted (PE-8), and organizations minimize the privacy information they collect about visits.

PE matters even for cloud systems (the data center is someone's physical space), and physical controls can compensate when a logical control isn't feasible — a connection you'll use when tailoring and assessing.

Lesson 2 — Operate & Monitor (~12 min)

The families that keep a running system healthy, watched, and recoverable.

Explain the AU, CA, CM, CP, IR, and MA families and their key controls.

Once a system is running, a second group of families keeps it healthy, watched, and recoverable: Audit & Accountability (AU), Assessment, Authorization & Monitoring (CA), Configuration Management (CM), Contingency Planning (CP), Incident Response (IR), and Maintenance (MA).

These are the day-to-day operational controls — the ones that tell you what's happening, keep the system in a known-good state, and get you back on your feet when something goes wrong.

Audit and Accountability (AU) is about collecting and reviewing information on activity in the system and organization, to spot unlawful, unauthorized, or inappropriate behavior.

First decide what to capture: the events to log (AU-2) and the content of each record (AU-3); then generate the audit records (AU-12). A standing caution for a PII system like MCMS: limit or prohibit capturing personal identifiers in the logs themselves.

Good audit data is what makes accountability — and later, incident response — possible.

Assessment, Authorization, and Monitoring (CA) controls directly support the Assess, Authorize, and Monitor steps of the RMF.

Control Assessments (CA-2) periodically evaluate effectiveness; the results feed Plans of Action & Milestones (CA-5) for any deficiencies. Authorization (CA-6) is the AO's decision to operate, refreshed over time. Continuous Monitoring (CA-7) maintains ongoing awareness of the system's posture.

If you've taken the RMF and 800-53A courses, this family is those processes expressed as catalog controls.

Configuration Management (CM) establishes known-good component configurations, keeps an accurate asset inventory, and controls changes to the environment.

Many CM controls are documented in a Configuration Management Plan (CM-9). A system component inventory (CM-8) ensures owners know the full population of hardware, software, and data they're protecting, and configuration settings (CM-6) define the secure baseline each component implements.

CM is what keeps a system from quietly drifting away from its secure baseline over time.

Contingency Planning (CP) prepares the organization to maintain confidentiality, integrity, and especially availability when operations are disrupted — by natural events or human action. For some organizations a minute of downtime costs millions; others never recover from a catastrophic outage.

A Contingency Plan (CP-2) lays out response, recovery, and post-recovery activities; System Backup (CP-9) and System Recovery and Reconstitution (CP-10) make sure you can actually restore critical resources.

CP is the family that answers "what happens when it breaks?"

Incident Response (IR) establishes the capability to handle incidents when they happen. An Incident Response Plan (IR-8) defines preparation, detection, analysis, containment, and recovery — and how incidents are documented, tracked, and reported, including whether to notify oversight bodies or affected individuals.

Key operational controls include Incident Handling (IR-4), Incident Reporting (IR-6), and responding to information spillage (IR-9) such as data exfiltration or a breach.

IR ties the operational families together: it consumes AU's audit data and triggers CP's recovery.

Maintenance (MA) keeps system components operating effectively and up to date across their life — and protects against the risks that maintenance itself introduces.

Scheduled maintenance (MA-2) reduces failure risk; spare parts and service contracts (MA-6) ensure timely replacement. The family also guards the maintenance activity: specialized maintenance tools (MA-3) may need to be checked, and maintenance personnel (MA-5) may require escorting or clearance.

MA is a reminder that the people and tools fixing your system are part of its attack surface.

Lesson 3 — Protect the System & Its Data (~9 min)

The families that guard the data, the communications, the integrity, and the plan.

Explain the MP, SC, SI, and PL families and their key controls.

The next group protects the system and its data directly: Media Protection (MP), System and Communications Protection (SC), and System and Information Integrity (SI) — plus Planning (PL), which produces the plan that ties it all together.

These are the families that guard where data lives, how it moves, whether it can be trusted, and how the whole protection story is written down.

Media Protection (MP) safeguards the media — paper or digital — where data is accessed (MP-2) or stored (MP-4), and restricts certain media (MP-7) like portable drives.

Marking media (MP-3) flags the sensitivity of what's stored so the right protections apply — but marking also advertises where the sensitive data is, which is exactly why access to media (MP-2) is controlled. When media is transported (MP-5), protection follows it.

MP is a reminder that data is physical somewhere, and that 'somewhere' needs protecting too.

System and Communications Protection (SC) secures the communication pathways between systems and with the outside world.

Its anchor is Boundary Protection (SC-7) — protection not only at the system's external interfaces (gateways, routers, network firewalls) but also at key internal interfaces (separated subnetworks, host-based firewalls). SC controls also help ensure PII is processed only per established privacy rules.

SC is the family that draws and defends the lines around and within your system.

System and Information Integrity (SI) ensures the system performs its intended function and is free from unauthorized manipulation — intentional or accidental.

Software, Firmware, and Information Integrity (SI-7) detects unauthorized changes; Flaw Remediation (SI-2) identifies, reports, and fixes flaws on a schedule; and several controls block malicious code (SI-3) entering through vectors like email (SI-8) or user input (SI-10).

SI is what lets you trust that the system — and the data it produces — hasn't been tampered with.

Planning (PL) produces the security and privacy plan (PL-2) that describes the controls planned or implemented for a system — combined or separate, per the organization. (SP 800-18r2 guides system-plan development — the SSP plus system privacy and C-SCRM plans; the RMF Select step and SP 800-53B guide selection.)

Rules of Behavior (PL-4) set users' responsibilities and expectations — closely related to access agreements (PS-6).

PL is where the catalog work lands on paper: the SSP is a PL-2 artifact — the same plan Dana has been writing throughout this course.

Lesson 4 — Program, Risk & Privacy (~11 min)

The organization-wide families: the program, the risk view, acquisition, supply chain, and privacy.

Explain the PM, RA, SA, SR, and PT families and how the catalog wraps up.

The last group operates above any single system — at the organization and program level: Program Management (PM), Risk Assessment (RA), System and Services Acquisition (SA), Supply Chain Risk Management (SR), and PII Processing and Transparency (PT).

These families set the strategy, size the risk, fund and acquire the system, secure its supply chain, and govern how personal data is processed — the enterprise context every system sits inside.

Program Management (PM) holds the strategic, organization-wide policies that define the information security program, the privacy program, and the supply chain risk management program.

Controls name leadership roles — for the security program (PM-2), privacy program (PM-19), and risk program (PM-29) — and the program plans: the Information Security Program Plan (PM-1) and Privacy Program Plan (PM-18). Together with each system's plans, these identify all the controls the organization employs.

Unlike most families, PM controls aren't selected per system — they're the enterprise scaffolding every system stands on.

Risk Assessment (RA) is about understanding risk to operations, assets, and individuals. Risk Assessment (RA-3) examines threats, vulnerabilities, likelihood, and impact (SP 800-30 gives the method). Privacy risk assessments — informed by NIST IR 8062 and the PRAM — feed Privacy Impact Assessments (RA-8).

The family also includes Security Categorization (RA-2), the Low/Moderate/High rating that drives which baseline you start from (the 800-53B course).

RA is the input side of the whole process: you can't select controls commensurate with risk until you've assessed the risk.

System and Services Acquisition (SA) ensures there are enough resources to protect a system across its life. Allocation of Resources (SA-2) budgets for the controls; the System Development Life Cycle (SA-3) frames security throughout; and acquisition processes (SA-4) govern what can be bought and from whom — including ensuring only vendor-supported, approved components are in use (SA-22).

SA is the family that makes protection sustainable: security that isn't budgeted and built into acquisition tends not to last.

Supply Chain Risk Management (SR) confirms the trustworthiness of product sources and the authenticity and integrity of technology products and their components, across the whole supply chain. (Use it alongside SP 800-161's C-SCRM controls.)

Guided by the organization's SCRM Strategy (PM-30), organizations build a plan to identify and manage supply chain risks (SR-2) across research, design, manufacturing, acquisition, delivery, integration, operations, and disposal.

SR is one of the three families added after FIPS 200 — a recognition that you inherit the risk of everything you buy.

PII Processing and Transparency (PT) governs how an organization processes PII across the information life cycle — collection, use, storage, dissemination, disposal, plus logging, analysis, and data mining.

In line with law and policy, PT controls cover identifying the categories of PII collected (PT-7), the purpose for collecting it (PT-3), and the authority to process it (PT-2) — plus transparency to individuals about that processing.

PT is the second family added for privacy (with PT and PM-19); it's where the privacy program's obligations become concrete controls.

That's the whole catalog. The controls are policy-, technology-, and sector-neutral, so they apply across legacy and cutting-edge systems alike. Each one carries a discussion and references to deeper guidance, and the controls you select are documented in the security and privacy plans and updated to reflect planned and actual implementation.

You now have the map: what a control is, how one is structured, how the catalog is organized into 20 families, who implements each, and what every family is for.

From here the path continues: SP 800-53B turns the catalog into impact-based baselines you tailor, and SP 800-53A assesses what you implemented. Same catalog, three lenses.