SP 800-53A: Assessing Controls Course — RMF Coach

Lesson 1 — What a Control Assessment Is (~9 min)

Before the how, the what: a control assessment proves a control works — it's not an audit.

Define a control assessment, distinguish it from an audit/compliance check, and say who relies on it.

Your team finished implementing the controls and wrote them up in the plan. Then the authorizing official asks the question that matters: how do you know they actually work?

"We turned them on" isn't an answer. Someone has to determine — with evidence — that each control is doing its job. That determination is a control assessment, and SP 800-53A is the playbook for doing it consistently.

Hold that question. By the end of this lesson you'll know exactly what a control assessment is, what it is not, and who depends on it.

Here's the definition, and it's worth memorizing word for word. A control assessment verifies that a control is implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security or privacy requirements.

Those are three distinct tests. Implemented correctly — it's actually built the way the plan says. Operating as intended — it works in practice, not just on paper. Producing the desired outcome — it achieves the protection the requirement was after.

An assessment is an information-gathering activity about the as-implemented state of the system. It produces evidence of effectiveness and an assessment report that gives officials credible information about strengths and weaknesses.

Just as important is what a control assessment is not.

It is not an audit with a binary pass/fail outcome. It is not a compliance check — you're not ticking boxes to prove you followed a rule. A control assessment gathers information about how well controls actually work, so the organization can make good risk decisions.

Why does this matter on the job? If you treat an assessment as a test to pass, people hide problems and the assurance is worthless. If you treat it as honest information-gathering, weaknesses surface early and get fixed. The output isn't a grade — it's credible input to a risk response.

SP 800-53A gives organizations a consistent, repeatable way to assess the controls in SP 800-53. That consistency is the point: it lets results be compared across systems and trusted by decision-makers.

It powers two RMF steps. It's the backbone of the Assess step — the guidance and procedures for evaluating whether controls are effective. And it supports the Monitor step — keeping awareness of changes so controls stay effective across the whole system development life cycle.

One more fact you'll lean on constantly: every control and control enhancement in SP 800-53 has a matching assessment procedure in SP 800-53A. You're never inventing how to assess a control from scratch.

Assessments touch almost everyone in the risk program. The assessor (also called the security control assessor) does the evaluating. But system owners, common control providers, ISSOs, authorizing officials, senior agency officials for privacy, inspectors general, auditors, and independent verifiers all rely on the results.

Whoever runs it, one quality matters above all: objectivity. Risk decision-makers depend on the assessor's accuracy and independence — a finding has to report what's actually there, not what anyone hopes is there. The more independent the assessor, the more confidence the AO can place in the result.

That's the whole frame: a control assessment is honest, evidence-based verification that a control works — trusted because it's objective.

Lesson 2 — Anatomy of an Assessment Procedure (~8 min)

Open one assessment procedure and learn its parts — the rest of the course is detail on these.

Name the parts of an assessment procedure and explain why the rationale matters more than the recipe.

Every control's assessment procedure has the same shape. It contains one or more assessment objectives, and each objective is built from determination statements — the specific, checkable things the assessor must determine.

Determination statements are the decomposition of the objective: they break a control down into the individual items you can actually evaluate in the controls and enhancements.

To determine each one, the procedure offers potential assessment methods (how you'll evaluate) and potential assessment objects (what you'll evaluate). That's the whole anatomy: objective → determination statements → methods + objects. The next lessons take each part in turn.

Two parts of the procedure are easy to mix up, so pin them down now.

A method is the nature of the assessor's action — the process for evaluating something. There are three: examine, interview, and test.

An object is what that action is applied to — a document, a piece of technology, an activity people perform, or an individual.

So "examine the access-control policy" is a method (examine) applied to an object (the policy). "Test the firewall" is a method (test) on an object (the mechanism). Keeping how and what separate is what lets you read — and write — a procedure cleanly.

Here's the idea that separates a real assessor from a checklist-runner. The potential methods and objects in a procedure are a starting assortment, not a mandatory list. Organizations use judgment to pick the ones that best make the determination.

And this is the key line from 800-53A: the quality of the results rests on the soundness of the rationale for selecting methods and objects — not on the specific set chosen. Two competent assessors might pick different objects and both be right, if both can justify why their choices make the determination.

That's why this is a skill, not a form. The rest of the course builds the judgment behind those choices.

Lesson 3 — Methods, Depth & Coverage (~11 min)

Three ways to gather evidence — and two dials that set how hard you look.

Choose among examine/interview/test and set depth & coverage to the assurance needed.

There are exactly three assessment methods. The first is examine.

Examine means reviewing, inspecting, observing, studying, or analyzing one or more objects — usually document-based artifacts like policies, procedures, and the system security and privacy plans. The goal is to understand how a control is meant to be implemented.

Good artifacts clearly reflect the risks and the strategies, policies, and procedures used to implement the controls. But examine has a limit: it tells you what's written, not necessarily what's running. That's why it's usually combined with the other two methods.

The second method is interview.

Interview means discussing the system's operation and the control's implementation with the people who'd know — users, system administrators, security and privacy staff, and other individuals or groups. They provide insight into how effective a control really is.

Interviews catch what artifacts miss: the workarounds, the "we actually do it this way," the gaps between the documented process and the lived one. A control can look perfect on paper and fall apart in practice — the interview is often where you find out.

The third and most concrete method is test.

Test means generating results from automated or manual procedures that exercise the implemented configuration or component behavior against the organization's defined requirements — letting you compare actual behavior to expected behavior. Think vulnerability scans, audit-log analysis, configuration scoring, inventory tools.

One caution worth carrying to the job: a test result usually demonstrates only a portion of a control's implementation. A clean scan doesn't prove the whole control works — it proves the part the scan checked. That's why strong assessments combine examine, interview, and test rather than leaning on any one.

Each method carries two dials: depth and coverage. Together they define the level of effort — and the assurance the assessment produces.

The organization sets them based on the system, the assurance required, and the determinations to be made. The shorthand is three levels: a basic assessment gives limited information about the security posture; a focused one looks harder at selected areas; and a comprehensive one demands more — a larger team, more evidence, more testing, a longer engagement.

More rigor isn't automatically better; it's more expensive. The skill is matching the dial to the decision: a brand-new high-impact system warrants comprehensive; a small change after authorization may only need focused.

Bring it down to earth with a routine doctor's visit — the doctor needs information before any diagnosis.

They examine artifacts: your chart and past lab results. They interview you: "What brings you in? Where does it hurt? How long?" They test: heart rate, blood pressure, height and weight, cultures, reflexes — and observe how you move.

And they pick a depth. A basic visit is a few questions and vitals. A focused visit adds targeted screening. A comprehensive physical runs the full battery. Same three methods, different rigor — chosen to fit the decision. A control assessment works exactly the same way.

Lesson 4 — Assessment Objects (~8 min)

Methods need targets — the four kinds of thing you examine, interview, or test.

Classify the four object types and select a necessary-and-sufficient set for an objective.

A method always acts on an assessment object. SP 800-53A sorts objects into four kinds.

Specifications are document-based artifacts — policies, procedures, plans, requirements, functional specifications, architectural designs. Mechanisms are the technical safeguards — hardware, software, and firmware. Activities are protection-related actions people perform — running backups, monitoring network traffic, exercising an incident-response test. Individuals are the people in the roles that apply the specifications, mechanisms, and activities.

Four buckets, and almost anything you'd assess drops into one of them.

Objects and methods fit together in a natural way.

You examine a specification (a document). You interview an individual (a person). You test a mechanism (a piece of technology). And you examine or observe an activity (a protection action in progress).

These aren't rigid rules — you might examine a mechanism's configuration file too — but the pairings are the intuition that makes a procedure read cleanly. When you see an objective, you can quickly imagine which objects you'd gather and which method you'd apply to each.

The objects listed in a procedure are explicitly not mandatory and not limiting. They're an initial assortment — a menu from which you choose.

The standard to aim for is necessary and sufficient: enough objects to actually make the determination, and no more. Collect too few and the finding isn't defensible; collect too many and you've burned time and budget for no added assurance.

This ties straight back to Lesson 2: the quality is in the rationale. You should be able to say, for each object you chose, why it helps make this determination — and why the ones you skipped weren't needed.

Lesson 5 — Objectives & Determination Statements (~10 min)

See how a control becomes the exact items an assessor checks — including the security/privacy split.

Read how control items map to determination statements and handle the security/privacy split.

Here's the part people miss: you don't assess a control as one lump. SP 800-53A transposes each control item into determination statements.

Take AC-17a (remote access). It has three elements — usage restrictions, configuration/connection requirements, and implementation guidance — so it becomes three determination statements: AC-17a.[01], [02], [03], each with bracketed sequential numbers. A simpler item like AC-17b has no sub-elements, so it's just AC-17b.

This is done for every control and enhancement, which gives you traceability: every determination statement maps back to a specific control item, so nothing is assessed that isn't in the catalog, and nothing in the catalog is missed.

Watch for the phrases "each type" or "for each type" in a determination statement. They're a signal that one statement can mean many assessments.

Why? Because a control may apply across different components, functionalities, operating systems, applications, operational environments, sites, or physical locations. "Establish usage restrictions for each type of remote access" means you assess dial-up, VPN, and wireless separately if all three exist.

Missing this is a classic under-scoping mistake: you assess one case, mark the statement satisfied, and leave the others untested. When you see "each type," stop and list the actual types in your environment.

Some procedures split a control into security and privacy determinations so each can be judged on its own.

The example is CM-4 (impact analysis): "Analyze changes to the system to determine potential security and privacy impacts prior to change implementation." The procedure gives separate determination statements for the security impact and the privacy impact.

Now the useful part: if the system processes no PII, the privacy determination may simply be not applicable — and the assessor can disregard it and still find the objective satisfied. Not-applicable is a legitimate, documented result, not a failure. The procedure even lists distinct security and privacy objects, which makes a security-only or privacy-only plan easy to assemble.

That security/privacy split isn't just bookkeeping — it's a tailoring tool.

Because the procedure separates the security objectives and objects from the privacy ones, an assessor can quickly pull together a security-focused, privacy-focused, or combined plan by selecting only the determinations and objects in scope.

On the job this saves real effort: a privacy assessor of a PII system can lift exactly the privacy determinations across many controls without wading through the security ones, and vice versa. The decomposition you learned this lesson is what makes that possible — small, labeled, traceable pieces you can recombine to fit the assessment's purpose.

Lesson 6 — Organization-Defined Parameters in Procedures (~11 min)

ODPs are the blanks in a control — and assessors check them first, before anything else.

Read ODP determination statements and worked examples (CM-2, MP-7, CA-3).

Recall an ODP (organization-defined parameter): the open slot in a control — an [Assignment] or [Selection] — that your organization fills with a specific value.

In an assessment procedure, the ODP determination statements come first and separately from the control's other determinations. There's a sharp reason: if an ODP isn't defined, the assessment objective isn't assessable. You can't evaluate "reviews accounts every [Assignment]" until the organization has said what that period is.

So the assessor's first move is to confirm the ODPs are defined or selected. It's a quick filter that prevents you from assessing a control that was never fully specified.

ODP identifiers have a tidy format: the control family, the control number, the enhancement number if any, then "ODP", plus a bracketed sequential number when a control has more than one — for example CM-02_ODP[01]. Spoken aloud it's fine to say "C-M-two, ODP one."

Think of it like declaring a variable in code: you define the ODP value once, then reference it wherever the control statement uses it. In later determination statements the value is referenced by its identifier plus a short description in angle brackets, so the assessor always knows which parameter is in play.

That variable-style indirection is what lets one defined value flow consistently into every determination that needs it.

Take CM-2 (baseline configuration). Its procedure has two ODPs: CM-02_ODP[01] for the frequency of reviews and updates, and CM-02_ODP[02] for the circumstances that trigger a review and update.

Those two values are referenced inside the CM-2b determination statements (CM-02b.01 and CM-02b.02) to complete what the assessor must check — e.g., "reviews the baseline configuration every <CM-02_ODP[01] frequency> and when <CM-02_ODP[02] triggers> occur."

Real systems complicate this nicely: a system might have distinct baseline configurations reviewed on separate schedules. The assessment plan has to account for those different use cases — one ODP value won't necessarily cover every configuration.

A Selection ODP offers a choice. In MP-7 (media use), the ODP MP-07_ODP[02] offers a choice between "restrict" and "prohibit" as the parameter for the control item. The organization's plan tells you which one was selected — and that's what you assess against.

The complete MP-7a determination pulls in all the ODP values, MP-07_ODP[01] through [04]. And again, use cases multiply: a system might restrict some media types while prohibiting others on different components, so multiple ODP values can apply within one control.

The assessor's job: read the plan, find the selected values, and verify the implementation matches the choice the organization actually made.

The last shape is the trickiest: an embedded ODP, where a Selection contains an Assignment.

In CA-3 (information exchange), the Selection CA-03_ODP[01] includes the Assignment CA-03_ODP[02] as one of its possible values. That lets the organization pick from the provided choices or define a custom option of its own — assigning one or several values for CA-03_ODP[02] to extend the selectable list.

Why care? Because some ODP determinations only apply if a particular value was selected. As an assessor you follow the chain: which selection was made, and did it trigger an assignment that now needs its own value checked? Read the plan, follow the nesting, and assess only the determinations the organization's choices actually activated.

Lesson 7 — Updates, the SDLC & the Assurance Case (~11 min)

Where procedures come from, when to assess, and how evidence becomes confidence.

Explain procedure updates, assessing across the SDLC, and what evidence builds the assurance case.

Assessment procedures aren't frozen. They're updated as understanding improves about mitigating security and privacy risks, and to stay aligned with changes to the controls and enhancements in the SP 800-53 catalog.

That means part of doing this well is working from the current version. NIST's Cybersecurity and Privacy Reference Tool (CPRT) gives interactive online access to the latest controls and their 800-53A assessment procedures, alongside news and updates on the current revision.

The habit to build: before you plan an assessment, confirm you're using today's procedures — not last year's printout.

Assessment can — and should — happen throughout the system development life cycle, not only at the end.

During the early phases, assessing specific controls promotes early detection of weaknesses and a far more cost-effective risk response. The sooner you find a weakness, the faster you can fix it and the less damage it can do to confidentiality, integrity, availability, or individuals' privacy.

The contrast is stark: a flaw caught in design is a quick correction; the same flaw caught after go-live is a finding, a POA&M item, and rework under pressure. Early assessment is cheaper risk management, full stop.

After the authorization to operate is granted and the system is in operations and maintenance, you don't reassess everything constantly. Instead, targeted assessments focus on the controls affected by a change — to the system, a specific control, a common control, or the environment of operation.

Better still, the 800-53A procedures plug into an Information Security Continuous Monitoring (ISCM) strategy: a steady stream of evidence about whether controls remain effective. ISCM can support ongoing authorization — keeping the AO's risk picture current rather than waiting years for a big reassessment.

The principle: assess what changed, continuously, and keep the assurance fresh.

All of this evidence adds up to an assurance case: a compiled body of evidence that gives the system owner, the authorizing official, and other risk officials confidence that the implemented controls are effective.

Assessors gather the evidence and the information needed to make accurate observations and objective determinations about each control — including how system controls are implemented and which common controls are inherited.

The initial evidence comes from building the system: development artifacts like functional specifications, system design documentation, and testing and code-analysis results (developer testing, SA-11, is a rich source). These show the components are reliable and trustworthy — that the security and privacy functionality is correct, complete, and able to resist attack and tampering.

Beyond build artifacts, operations produce evidence continuously: records of remediation actions, continuous monitoring output, and incident reports — including reports of breaches involving PII. These show how controls behave in the real environment over time.

Evidence also includes results from individual component product assessments, the information in the system security and privacy plans, other control documentation, and previous assessment results. Crucially, it includes the assessment results of controls the system inherits — common controls and the inherited portions of hybrid controls.

The takeaway for the job: strong evidence is specific, current, and tied to a determination. "We have a policy" is weak; "here's the policy, the config that enforces it, and last month's monitoring showing it held" is strong — and it's what lets an assessor make an objective call.

Lesson 1 — Prepare for the Assessment (~9 min)

A good assessment is won before it starts — in scoping and team preparation.

Set the assessment's objective and scope, and prepare the assessment team.

Preparation starts by establishing the objective and scope — the purpose of the assessment and exactly what's being assessed. Several decisions set the scope:

Is it security-focused, privacy-focused, or both? Is it performed in-house by the system owner/common control provider, by an internal third party, or by an external service provider? Is it a complete assessment of all controls, a partial or targeted selection, or an evaluation of common controls? And does it cover the entire authorization boundary or only specific components, functions, or services within it?

Getting these answers up front is what keeps an assessment from sprawling — or from quietly missing something that mattered.

Preparation is a team sport. A successful assessment needs the cooperation of everyone in supporting roles — control assessors, system owners, common control providers, and authorizing officials.

The authorizing official, working with the senior agency official for privacy (SAOP) and the system owner, coordinates with management to settle the objectives, the scope, and the resources needed to complete the assessment. That includes practical logistics like notifying key organizational stakeholders so the right people and systems are available.

The lesson: assessments don't just happen because an assessor shows up. Someone with authority scopes it, funds it, and clears the path — usually the AO with the SAOP and system owner.

Once the AO selects the assessment team, the team prepares. A clear line of communication between assessors and organizational officials ensures a shared understanding of the purpose, rigor, and scope.

The team reviews artifacts to understand the organization's operations and its security and privacy architectures — how the controls are actually implemented to support the mission. They lean on the system security plan and privacy plan to identify the implemented controls and the defined ODPs that will be in scope.

This is the homework that makes an assessment competent. An assessor who understands the architecture asks sharper questions and selects better objects than one who walks in cold.

Two more preparation habits matter.

First, safeguard the information. The material assessors receive and collect can be sensitive — details about the system and organization. Assessors must protect it commensurate with the organization's security and privacy policies and the system's categorization.

Second, learn from history. The team reviews prior assessment reports to spot past weaknesses and deficiencies that may need attention again, and reviews the assessment reports of common control providers the system inherits from. They also request any additional artifacts they need.

Good preparation means you arrive informed by what's already known — not rediscovering last year's findings from scratch.

Lesson 2 — Develop the Assessment Plan (~13 min)

Five moves turn a scope into a Security Assessment Plan the AO can approve.

Build a SAP: determine controls, select & tailor, develop additional, optimize, finalize.

The assessment team develops the Security Assessment Plan (SAP) with input from system and organization personnel. Because objectives were set during preparation, a plan may be security-focused, privacy-focused, or integrated into one.

There are five steps: (1) determine the controls to assess; (2) select and tailor the assessment procedures; (3) develop additional procedures; (4) optimize the procedures; and (5) finalize the plan and obtain approval.

Two freedoms worth noting: SP 800-53A does not mandate a plan template or a fixed duration. The team works with system officials to choose a format. What it does require is that the plan be complete, tailored, and approved before any assessing begins.

Step one: determine the controls to assess, starting from the controls in the security or privacy plan that support the assessment's purpose.

For an initial authorization, that's all controls in the plan. For a partial assessment, system owners and common control providers collaborate with officials to pick the relevant subset — and assessing controls early in the SDLC lets weaknesses be fixed before the system is operational. After an ATO, targeted assessments focus on what a change affected.

A common control assessment is its own case: it may cover all inheritable controls or a targeted selection a provider offers, documented in the provider's plan or equivalent artifact.

Step two: for each control and enhancement, select the 800-53A procedure and tailor it. First check whether the organization has tailoring guidance, then adjust:

Pick the methods and objects that satisfy each objective — watching for "for each"/"each type" language that means distinct object types in your environment. Set depth and coverage to the rigor needed: an initial ATO assessment may be comprehensive, while a re-authorization may be focused, at the AO's discretion. Identify common controls and inherited hybrid portions already assessed so you don't redo them. Build platform- or organization-specific procedures where multiple platforms need different tests. And reuse prior assessment results where they're still valid.

This is tailoring from Lesson 5/6 applied at plan scale.

Step three: develop additional procedures. Organizations often add organization-specific controls or enhancements to address their own policies, unique mission needs, or risks from the risk assessment. These may be beyond SP 800-53 — documented in the plan as "controls not found in SP 800-53."

Because they aren't in the catalog, they have no ready-made procedure in 800-53A. So you build one: use 800-53A's guidance to write the assessment objective, then identify potential methods and objects — exactly the anatomy from Module 1. The custom procedures are then integrated into the plan alongside the standard ones.

The principle: a control without a procedure is a control you can't assess — so every in-scope control, standard or custom, gets one.

Step four: optimize — save time and cost while keeping the assurance.

When a method is applied to many objects across a control family, combine or consolidate the procedures. The classic example: consolidate interviews with key officials so one sitting collects information for several controls — precious when people's availability is limited. Sequence the work: assess controls that give general system context first, then use that to assess more targeted controls. And use the related controls listed for each control in the catalog to find shared objects, so evidence gathered for one control can be reused for related ones.

Optimization is where an experienced assessor's plan pulls ahead — same coverage, far less wasted motion.

Step five: finalize and approve. The plan is finalized before the team is authorized to conduct the assessment, through an approval process with designated authorities — most often the system owner (or common control provider) and the authorizing official (and the SAOP where privacy applies).

The final plan includes the scope and purpose; the tailored and optimized procedures with their methods, objects, and depth/coverage; and the resources needed. It often adds key participants and approval authorities, the assessment team members, and logistics for execution.

Approval hinges on one question: is the plan consistent with the organization's security and privacy risk-management objectives? If yes, the team is cleared to begin.

Worked example — Priya scopes the assessment plan for MCMS.

MCMS is going for its initial authorization, so Priya (the assessor) starts the SAP by pulling every control in the system security plan — an initial ATO assesses them all. Working with Marcus (the system owner), she sets depth and coverage to comprehensive: it's a new, Moderate-impact system and Karen (the AO) wants real assurance.

She checks what MCMS inherits — several common controls already assessed by the agency platform — and references those provider results instead of reassessing them. For two organization-specific controls "not found in SP 800-53," she writes custom procedures using 800-53A's guidance, then optimizes (one interview with Dana covers several controls).

Nothing is assessed until Karen approves the SAP. The artifact Priya just produced — the SAP — is the contract for everything that follows.

Lesson 3 — Conduct & Record Findings (~10 min)

Run the plan, gather evidence against the system's requirements, and grade each determination.

Conduct an assessment and record findings as satisfied or other than satisfied.

With the plan approved by the AO, the team conducts the assessment: apply the methods to the objects to obtain evidence that demonstrates how each control is implemented.

Now the subtlety that trips people up: you evaluate the evidence against the system's own security and privacy requirements — not directly against the NIST guidance. NIST tells you how to assess; the system's requirements define what correct means here. Measuring against the wrong yardstick yields findings nobody can act on.

As you go, you look for gaps between what you observe and the planned, expected state in the plans. Those gaps are the weaknesses and deficiencies you'll record — the raw material of the findings.

How you conduct matters as much as what you find. System owners and common control providers rely on the assessor's expertise and objectivity — the result is only as good as the assessor's accuracy and independence.

Open communication keeps the assessment honest and on track: it helps the work stay within the agreed scope, and it lets weaknesses be explained as they're discovered rather than landing as a surprise in the report. Sometimes assessors need to discuss a specific observation to clear up a misunderstanding or a subjective reading of the evidence.

And the bar for evidence is firm: the evidence collected must fully support the finding for each evaluated object. A finding you can't back with evidence isn't a finding — it's an opinion.

Each determination statement gets a finding. A finding is an unbiased, factual report of the control's actual state versus the planned, expected, desired state in the plans.

Satisfied means that, for the part of the control that determination covers, the objective is met — implemented correctly, operating as intended, producing the desired outcome. Two sharp rules: it's true only at the time the assessment was conducted (the threat landscape changes), and a control or enhancement is satisfied only if every determination statement in its objective is satisfied.

There is no "partially satisfied." All the determinations pass, or the control is not satisfied. That all-or-nothing rule is what keeps "satisfied" meaningful.

The other outcome is other than satisfied. It means one of two things for the part of the control addressed: the assessor sees a potential security or privacy weakness to be addressed, or the assessor couldn't obtain enough information to make the determination.

That second case is important and often missed: "we couldn't get the evidence" is not a pass. If you can't confirm satisfied, the honest label is other-than-satisfied — and it prompts either remediation or a renewed effort to gather evidence.

These other-than-satisfied findings are exactly what flow into the POA&M and shape the risk response the next lessons cover. They're not failures to hide; they're the whole point of assessing.

Worked example — Priya grades AC-2 (account management) on MCMS.

She examines the SSP and the account procedure, interviews Dana (the ISSO) about how accounts are provisioned, and tests the mechanism. Three of the four determination statements clearly check out. For the fourth — periodic account review — Dana believes it happens but there's no evidence: no records, no logs.

Priya doesn't round up. With one determination unmet, the control is other than satisfied — there is no "partially satisfied." She measures the evidence against MCMS's own requirements, not the NIST text, and writes the finding factually, noting exactly what evidence was missing so it can be fixed.

Lesson 4 — Report the Findings (SAR) (~8 min)

Turn findings into a report decision-makers can act on.

Explain the SAR's purpose and the key elements a good report includes.

The Security Assessment Report (SAR) has one primary purpose: to convey the results of the assessment to the system owner, the authorizing official, and other risk-management officials.

Results are documented at a level of detail and in a format appropriate for the assessment. Like the plan, SP 800-53A does not prescribe a format — but organizations usually benefit from a standardized template.

Keep the audience in mind: these are the people who will accept or reject risk based on what you write. The SAR isn't a private worklog; it's the bridge between what the assessor found and the decision the AO has to make.

SP 800-53A lists key elements a SAR should consider including:

Information about the system (name, categorization, SDLC stage, purpose); the assessment's purpose and scope; logistical details; the system and organization roles; the assessment team; the controls in scope; the objects and methods selected with their depth and coverage values; an assessment finding summary for each objective; the assessor's comments on weaknesses identified; and the assessor's recommendations on risk-response priorities or other improvements.

Notice the report records not just what was found but how it was assessed (methods, objects, depth/coverage) — so the AO can judge how much confidence to place in each finding.

The best practice here is discipline and structure. A disciplined reporting approach — documenting each finding consistently and pairing it with recommendations to correct the weakness or deficiency — lets the system owner and AO quickly understand the threat picture and decide.

Write each finding so a reader can see: which determination, what was observed, why it's satisfied or other-than-satisfied, and (for the latter) what to do about it. Vague findings create back-and-forth; precise, recommendation-bearing findings move straight to a risk response.

A SAR is judged by how easily someone who wasn't in the room can act on it. That's the standard to write to.

Lesson 5 — Analyze Results & Respond to Risk (~9 min)

Findings become decisions: the AO weighs risk, chooses a response, and updates the package.

Turn assessment results into a risk response and an updated authorization package.

After the final report arrives, the post-assessment work begins — done by the organization's decision-makers, not the assessment team.

The report gives officials visibility, through the satisfied and other than satisfied labels, into the specific weaknesses and deficiencies in the controls within, or inherited by, the system. That clarity is the whole payoff of a disciplined assessment: leaders can see exactly where the risk sits.

From here the system owner or common control provider works with the authorizing official to decide what to do about each weakness. The assessor informed the decision; now the accountable officials make it.

For each weakness, officials choose a risk response. The options are to reduce/mitigate the deficiency, or to accept, share, transfer, or avoid the residual risk.

One rule is absolute, and it comes from SP 800-37: only the authorizing official can accept the residual risk of operating the system. An assessor never accepts risk; a system owner doesn't unilaterally accept it; the AO does.

So a finding's journey is: the assessor reports it objectively, officials weigh it, and the AO decides whether the residual risk is acceptable. That separation — assess, then decide — is what keeps the whole process honest and accountable.

Assessment results don't just inform a one-time decision — they update the record. The results and the responses to findings influence whether the system is authorized to operate, and any conditions attached to continued operation.

The authorization package is then updated to reflect the as-implemented state: the system security and/or privacy plan(s), the assessment report(s), the plan of action and milestones (POA&M) for the open weaknesses (control CA-5), and an optional executive summary.

That's the Assess step closing into Authorize: an objective assessment, an accountable risk response, and an updated package that tells the truth about where the system stands.

Worked example — Karen acts on MCMS's assessment report.

The SAR lists several other than satisfied findings. Marcus (the system owner) works through each with Karen (the AO). Two low-severity gaps get a quick mitigation; for one moderate gap with a fix already underway, Karen accepts the residual risk for now and it's tracked. Every open weakness lands in the POA&M with an owner and a date.

Karen — and only Karen — accepts the residual risk of operating MCMS; Priya and Marcus inform the decision but don't make it. With responses set, the team updates the authorization package (SSP, SAR, POA&M) to the as-implemented state, and Karen issues the ATO with conditions.

Lesson 6 — Capabilities, Ongoing Assessment & Pen Testing (~10 min)

Beyond control-by-control: assess capabilities, automate the routine, and pressure-test for real.

Explain capability-based assessment, ongoing/automated assessment, and penetration testing.

Assessments are traditionally done control by control — but effective protection usually needs several controls working together. Grouping related controls and enhancements into capabilities (combinations of mutually reinforcing controls) brings real benefits.

Assessing capabilities supports root-cause analysis: when something's weak, the relationships between controls help you trace it to the actual deficient control(s). It also lets you reuse the assessment objects common to the whole group, reducing the overall effort.

And it adds precision that matters upstream: capability-level insight strengthens the continuous monitoring strategy and the ongoing authorization decisions senior leaders make. It's the same instinct as the RMF's 'capability' idea, applied to assessment.

Integrating the 800-53A procedures into an Information Security Continuous Monitoring (ISCM) strategy (based on SP 800-137) turns assessment into an ongoing process of collecting and analyzing control information. Catching weaknesses continuously means faster risk responses than waiting for the next periodic assessment.

Much of this can be automated. The NIST IR 8011 series describes using automation for control assessments, and the 800-53A procedures help you decide which controls benefit from automated testing. Automation rests on a clear understanding of the desired state versus the actual state — and how the organization defines and detects defects in an implementation.

The direction of travel across the field is exactly this: less manual snapshotting, more continuous, automated assurance.

Penetration testing is a highly specialized form of technical testing: assessors simulate an attacker and try to defeat the system's security or privacy features.

It goes beyond vulnerability scanning — a scan lists potential weaknesses; a pen test provides explicit proof of exploitability under real attack conditions by simulated threat sources. It can be part of the assessment for an ATO determination, or a separate effort. Either way, the rules of engagement must clearly define the attack techniques allowed and the attack surfaces in scope.

What it validates is telling: a system's ability to recognize an attack automatically, execute a defined response, and drive the recovery — the detect-respond-recover chain working under pressure.

Step back and the whole course is one loop. A control assessment verifies that controls are implemented correctly, operating as intended, and producing the desired outcome — and it's a vital part of the risk program, run again and again as conditions change (new threats, new requirements, new technology, new mission).

You plan from the 800-53A procedures (objectives, determination statements, ODPs, methods, objects), conduct against the system's requirements, record findings (satisfied / other than satisfied), report them in the SAR, and the AO turns them into a risk response. The results then update the security and privacy plans and the POA&Ms.

That objective, repeatable verification is what lets risk officials decide, with confidence, whether a system is adequately protected and can operate.