RMFInsider

Your eMASS package rejected reasons usually trace back to the same handful of gaps: artifacts that don’t match what the control response claims, test results that were never uploaded, or a POA&M that contradicts the SSP. If your package just bounced from an AO or SCA reviewer, the fix isn’t a rewrite — it’s a systematic pre-submission pass through the same checklist reviewers use.

I’ve watched packages get kicked back for the same errors over and over, and every one of them was preventable. This checklist walks through what DCSA-published guidance flags as the recurring failure modes, then turns each one into something you can actually check before you hit submit in eMASS.

Why eMASS Packages Get Rejected

Reviewers aren’t grading on effort. They’re checking whether the body of evidence actually proves the control is implemented the way the SSP says it is. According to the Assessment & Authorization Process Manual (DAAPM) and the DISA eMASS User Guide, packages get bounced for a narrow set of reasons that show up again and again:

• Insufficient artifacts — a control is marked implemented, but there’s nothing uploaded that proves it
• Weak evidence chains — the artifact exists, but it doesn’t clearly connect to the specific control requirement it’s supposed to satisfy
• Control-response and test-result misalignment — the narrative in the control response describes one implementation, and the test procedure or scan result shows something else
• Stale or missing POA&M entries for known open findings
• Copy-paste control narratives that don’t reflect the actual system

Every one of these is a documentation problem, not a security problem. The system might be genuinely secure and still get rejected because the package can’t prove it on paper.

The Pre-Submission Checklist

Run this before you route the package for review. It’s built around the same failure modes DCSA and DISA guidance calls out, organized so you can work through it control by control instead of trying to review the whole SSP at once.

Failure Mode	What to Check	How to Fix It Before Submission
Insufficient artifacts	Every control marked “Implemented” or “Inherited” has at least one uploaded artifact attached in eMASS	Pull the control list filtered by implementation status; for any control with zero attachments, either upload evidence or change the status to reflect reality
Weak evidence chains	Each artifact’s filename and description clearly ties back to the control ID it supports	Rename generic files (e.g., “screenshot1.png”) to something a reviewer can map to the control without opening it — “AC-2_account_review_log_Jun2026.pdf”
Control-response/test misalignment	The control implementation narrative matches what the SCA’s test procedure actually found	Read the test result against the narrative side by side; if the scan or interview notes contradict the write-up, fix the narrative or open a POA&M — don’t leave the contradiction in place
Stale POA&Ms	Every open finding has a current POA&M entry with a realistic milestone date	Cross-check the vulnerability scan output against the POA&M list; anything scanning as open that isn’t tracked is a red flag to a reviewer
Copy-paste narratives	Control responses reference actual system components, not generic boilerplate	Search the SSP for narrative text that repeats verbatim across unrelated controls — that’s usually a sign it was templated and never customized
Outdated artifacts	Evidence dates fall within the current assessment or continuous monitoring window	Flag any artifact older than your organization’s evidence currency window (often 12 months, confirm your local DAAPM guidance) and refresh it
Missing hardware/software list	The HW/SW baseline in eMASS matches what’s actually deployed	Reconcile the inventory against your latest ACAS/Nessus scan target list before submission

Artifact Quality: What “Sufficient” Actually Means

A common misread among new ISSOs is thinking “artifact uploaded” equals “control satisfied.” It doesn’t. Reviewers are looking for evidence that is current, specific to the system under review, and traceable to the exact control language.

A screenshot of a config setting proves the setting exists at a point in time. It doesn’t prove the control is operating continuously unless you pair it with something like a change-log excerpt or a recurring scan result. If your control response claims ongoing enforcement, your evidence needs to show more than a single snapshot.

The same logic applies to policy documents. Uploading the organization-wide security policy as evidence for a system-specific control is a weak chain — reviewers want to see how that policy was implemented on this system, not just that the policy exists somewhere.

A useful gut check: if you handed the artifact to someone who has never seen your system, could they trace it back to the control requirement without asking you a follow-up question? If the answer is no, the evidence chain is the part that needs work, not necessarily the underlying implementation. This is also where naming conventions pay off — a reviewer working through dozens of controls in one sitting relies on filenames and descriptions to move quickly, and a package that makes that easy tends to get a faster, more favorable read than one that doesn’t.

Control-Response and Test-Result Alignment

This is the failure mode that catches experienced ISSOs off guard, because it’s not about missing work — it’s about work that doesn’t match its own description.

Here’s how it happens in practice: the control response was written early, based on the planned implementation. Then the actual build changed — a different logging tool got deployed, or a compensating control replaced the original plan. The narrative never got updated. When the SCA tests the control, the test procedure documents what’s actually there, and now the SSP and the test result tell two different stories.

Before submission, walk through every control that has a completed test result and read the narrative next to it. Any mismatch needs one of two fixes: update the control response to match reality, or if the control genuinely isn’t meeting the requirement, open a POA&M instead of letting the contradiction sit in the package. A package with an honest POA&M for a known gap reviews better than one with a narrative that doesn’t hold up under a test result.

If you’re still building out your eMASS workflow from scratch, our eMASS for beginners guide walks through the registration and control-entry process this checklist assumes you’ve already completed.

POA&M Hygiene Before Submission

A package with zero POA&Ms and a system that scans clean on every single control is rare enough that it draws scrutiny on its own. Reviewers expect some open findings — what they’re checking is whether those findings are tracked honestly.

Before you submit, cross-reference three things against each other: the latest ACAS/Nessus scan output, the POA&M list in eMASS, and the control status. Any finding that shows up in the scan but not in the POA&M is a gap a reviewer will find in minutes. Any POA&M with a milestone date that already passed needs an update — a stale milestone reads as an abandoned remediation plan, not an active one.

If you haven’t built out your POA&M process yet, walk through how to write a POA&M and how to enter a POA&M in eMASS before your next submission cycle — clean POA&M entries are one of the fastest wins on this checklist.

A Quick Pre-Submission Routine

Here’s the order I run through before routing a package for AO or SCA review:

• Export the control list and filter for any implementation status with zero attached artifacts
• Spot-check artifact filenames and descriptions for traceability back to the control ID
• Read every control response against its paired test result, starting with the highest-risk controls first
• Reconcile the current vulnerability scan against the POA&M list
• Confirm the hardware/software inventory matches the scan target list
• Check evidence dates against your organization’s currency window

None of this is glamorous work. It’s also the difference between a package that clears review on the first pass and one that comes back with a rejection memo that costs you another two to three weeks on the calendar.

If your package has already bounced once, the common patterns in common eMASS mistakes that delay your ATO are worth a second read — rejection memos tend to repeat the same handful of root causes.

When You Genuinely Can’t Fix It Before the Deadline

Sometimes the checklist surfaces a real gap you can’t close before your submission window — a control that’s genuinely not implemented, or a test result that exposes something you didn’t know about. In that case, don’t submit and hope the reviewer doesn’t notice. Open an honest POA&M with a realistic remediation date and a compensating control if one exists. A package with a known, tracked gap moves through review faster than one where the reviewer finds an undisclosed contradiction on their own.

Reviewers reject packages that hide problems. They work with ISSOs who document them.

Build the Checklist Into Your Workflow

Running this checklist once before a big submission helps. Running it every time you touch the package is what actually prevents rejections. If you want a version of this checklist built out as a standing document you can reuse across systems and assessments, the RMF Checklist ($27) walks through the full pre-submission process control by control, and the POA&M Tracker ($37) keeps your open findings reconciled against scan data automatically instead of by memory.

A rejected package isn’t a security failure. It’s usually a paperwork gap that a careful pass through the SSP, the artifacts, and the POA&M list would have caught. Build that pass into your routine before every submission, and rejections stop being a surprise.