RMFInsider

In eMASS, the Control Approval Chain (CAC) is the review path for individual controls, and the Package Approval Chain (PAC) is the review path for the whole authorization package. Controls move through the CAC as you mark them compliant and validators confirm them. The package moves through the PAC when you submit it for authorization and it travels from ISSO to ISSM to SCA to the AO’s office. When a package “just sits there,” it is almost always waiting on a specific person at a specific stage of one of these two chains, and eMASS will tell you which one if you know where to look.

Why there are two chains

RMF separates the work of proving controls from the decision to accept risk. The CAC handles the first job control by control, so a validator can push back on AC-2 without rejecting the whole package. The PAC handles the second job, gathering the validated controls, the POA&M, the SAR, and the risk assessment into one decision for the Authorizing Official. Two chains means two places to stall, but it also means you can fix a control finding without restarting the authorization workflow.

If the RMF steps themselves are fuzzy, how to get an ATO step by step is the process view; this post is the eMASS mechanics view.

The Control Approval Chain (CAC)

Each control in your baseline has a status and an approval position. The typical CAC has these roles, though your organization’s eMASS instance can configure more or fewer:

• ISSO / system owner staff enters the implementation statement, attaches artifacts, sets the compliance status, and submits the control forward.
• ISSM reviews for completeness and internal consistency and either approves or returns the control with comments.
• Validator / SCA representative tests the control against the assessment procedures and CCIs, records test results, and marks it validated or returns it as a finding.

The important behavior: a control returned from any stage comes back to you with comments and drops out of the approved count. Your control status dashboard will show it as not compliant or not validated until you address the comment and resubmit. Nothing about the PAC has to change for that to happen.

Reading the CAC on a control

Open the Controls tab, select the control, and look for the approval or workflow section. It lists each CAC stage, who holds it, and whether that stage is pending, approved, or returned. Sort the controls list by approval stage and you get an instant view of how many controls are sitting with the ISSM versus the validator. That sort is the single most useful five seconds in eMASS during assessment.

The Package Approval Chain (PAC)

The PAC is triggered when you create a package (assess-and-authorize, assess-only, reauthorization, or a decommission package) and submit it. Stages commonly look like:

• ISSO assembles the package: selected controls, artifacts, POA&M, system details, and any required attachments such as the SSP or the boundary diagram.
• ISSM reviews and concurs, or returns it.
• SCA completes the Security Assessment Report and assigns risk levels to open findings.
• AO representative / AODR reviews the risk picture and prepares the recommendation.
• Authorizing Official issues the authorization decision: ATO, ATO with conditions, IATT, or denial.

The choice between assess-only and a full authorization package changes which PAC you enter; assess only vs full ATO explains when each applies.

What each PAC approver actually sees

Approvers do not read your package the way you built it. The ISSM checks that every control in scope has an implementation statement and a status. The SCA checks test results and looks hard at anything marked compliant with thin evidence. The AO’s staff looks at the risk summary, the POA&M’s open CAT I and CAT II counts, and the milestone dates. Build the package for those three readers and it moves. Build it as a pile of controls and it waits.

Where packages stall, and what to do

Stalled in the CAC

Symptom: the package cannot be submitted because controls are not validated. Fix: sort controls by approval stage, find who is holding them, and send a short list. Validators respond to “these twelve controls are waiting on you, here is the artifact for each” far better than to “can you look at my system.”

Stalled in the PAC

Symptom: package shows submitted, status unchanged for weeks. Open the package record and read the current stage and assignee. If the assignee has left the organization (this happens more than anyone admits), the eMASS administrator for your instance has to reassign the role. No amount of waiting fixes an orphaned approval stage.

Returned from the PAC

Read the return comments before touching anything. A package returned by the SCA usually needs specific controls reworked, which means those controls go back through the CAC first. A package returned by the AO’s office usually needs POA&M or risk narrative changes, not control changes. Fixing the wrong layer is how a two-week delay becomes a two-month delay. Why your ATO is delayed covers the other classic causes.

Habits that keep both chains moving

• Submit controls to the CAC in batches by family, not one at a time and not all 300 at once. Validators can plan around a batch.
• Never submit a package with controls still pending in the CAC unless your process explicitly allows it. It will be returned, and you will have lost your place in the AO’s queue.
• Keep the POA&M current before the PAC, not after. The SCA reads it as the honesty test for the whole package. How to enter a POA&M in eMASS has the mechanics.
• Check who holds each stage before you go on leave. A package that reaches you while you are gone stalls just as surely as one stuck with a validator.

The one-line version

CAC is per control, PAC is per package, and every stall has a name attached to it. Find the name, send the list, and keep the POA&M honest. That is the entire art of getting an eMASS package through faster than the ISSO down the hall, who is still waiting for the validator to “look at their system.”

For the ordered checklist of everything that has to be true before you hit submit, grab the RMF Checklist.