Most of the technical and documentation work for an ATO happens before anyone touches eMASS. But eMASS is where it all gets assembled, reviewed, and routed, and it’s also where packages stall for reasons that have nothing to do with the underlying security posture. A system can be genuinely secure and still sit in eMASS for weeks because of avoidable mistakes in how the package was put together.
This guide covers the mistakes that show up again and again, the ones that cost time without reflecting anything wrong with the system itself.
Mistake 1: Artifacts That Don’t Match What’s in eMASS
Every control in eMASS has an implementation status and a narrative. The supporting artifacts attached to the package, the SSP, diagrams, scan results, configuration screenshots, need to actually back up what that narrative claims. The most common gap is version drift: the SSP gets updated, but the version uploaded to eMASS is from three revisions ago, or a control’s narrative was rewritten but the linked artifact still reflects the old implementation.
Assessors notice this quickly, because it’s often the first thing they check. A narrative describing one configuration with an attached screenshot showing something different is an immediate credibility problem, even if the actual current implementation is fine.
Real-World Example: The Outdated Diagram
A package went up for assessment with a network architecture diagram attached that was about a year old. In the time since that diagram was created, a new segment had been added to support a secondary data feed, and several control narratives referenced that segment’s logging and access controls.
The assessor flagged every control that referenced the new segment, because the supporting diagram didn’t show it existing at all. From the assessor’s side, there was no way to verify a configuration for something that, according to the attached documentation, wasn’t part of the system. The fix took an afternoon: update the diagram and re-upload. But it added a full review cycle to the timeline, because the package had already been submitted and had to be returned for correction.
Before submission, walk through every artifact and ask: does this still match what the system looks like today?
Mistake 2: Control Status That Doesn’t Match the Narrative
eMASS tracks a status for each control (implemented, partially implemented, planned, not applicable, and so on) separately from the narrative text describing the implementation. These two fields drift out of sync more often than people expect. A control might be marked “implemented” while its narrative still contains placeholder language describing a planned future state, or a control might be marked “partially implemented” with a narrative that actually describes a complete implementation, just written before the last piece was finished and never updated.
Either direction creates confusion for an assessor trying to scope their review, and either direction can generate a finding even when the underlying control is fine, simply because the package is internally inconsistent about its own status.
Mistake 3: POA&M Entries That Don’t Link Back Cleanly
Every POA&M entry in eMASS should trace back to a specific control and a specific finding, with a severity that matches what the assessment actually identified. A common issue is POA&M items that get created in a hurry after a scan, with a generic description that doesn’t clearly map to the control it affects, or a severity rating that was copied from a template rather than assessed for the specific finding.
Real-World Example: The Mismatched Severity
A POA&M item for an unpatched component was entered as a moderate-severity finding, copied from a similar entry on a previous package. The actual vulnerability scan that generated the finding rated it as high severity for this specific system, because of how the component was exposed in this particular architecture.
When the assessor cross-referenced the POA&M against the raw scan results, the mismatch stood out immediately, not just as an error, but as a sign that POA&M entries weren’t being individually reviewed against their source findings. That one mismatch led to a broader review of every POA&M entry in the package, which took far longer than getting the severity right the first time would have.
Mistake 4: Submitting to the Wrong Workflow Stage
eMASS routes packages through a defined workflow with specific roles responsible for each stage. Submitting a package before it’s actually ready for that stage, or routing it to the wrong role, results in it bouncing back, sometimes after sitting in a queue for days before anyone notices it’s in the wrong place.
This sounds like a minor administrative issue, but on a tight timeline, a package that bounces back after sitting untouched for a week has effectively lost that week for no reason related to the system’s actual security posture. Knowing your organization’s specific workflow configuration, who reviews what, in what order, and what “ready” looks like at each stage, prevents this entirely.
Mistake 5: Artifact Organization That Makes Assessors Work Harder
This one doesn’t generate a formal finding, but it shapes how an assessor approaches the whole package. A package where artifacts are clearly named, organized, and mapped to the controls they support reads as a package from a team that has its act together. A package where every artifact is named “Document1.pdf” or “Untitled scan export” and the assessor has to open each one to figure out what it is creates friction before the technical review even starts.
Assessors are people, and a package that’s easy to navigate gets a different kind of attention than one that requires detective work just to understand what’s been submitted. Clear naming conventions and a short index of what each artifact covers cost almost nothing to produce and pay off throughout the entire review.
A Pre-Submission Checklist
Before submitting a package, go through it with these questions in mind: Does every uploaded artifact reflect the current state of the system, not an earlier version? Does every control’s status in eMASS match what its narrative actually describes? Does every POA&M entry trace back to a specific finding with an accurate severity? Is the package being submitted to the correct workflow stage and role for where it actually stands? And could someone unfamiliar with this system navigate the artifacts and understand what they’re looking at without opening every file?
None of these questions are technical. All of them are about whether the package presents an accurate, navigable picture of the system. That’s a different skill than securing the system itself, and it’s the skill that determines how smoothly a technically sound system moves through eMASS.
Final Thoughts
The mistakes that delay ATOs in eMASS are rarely about whether a system is secure. They’re about whether the package accurately and consistently represents that security to someone who has to verify it without being able to walk over and look at the system themselves. Every inconsistency, an outdated diagram, a mismatched status, a miscategorized finding, adds a question the assessor has to resolve before they can move forward, and those questions compound into weeks.
If you’re building out your eMASS package, the Complete eMASS Guide covers the broader workflow this fits into.
Leave a Reply