RMFInsider

To upload an artifact in eMASS, open your system, go to the Artifacts tab, click Add Artifact, choose the file, fill in the name, type, and description, and save. Then, and this is the step that separates packages that move from packages that sit, open the Controls tab and associate that artifact with every control and CCI it supports. An artifact nobody can find from the control they are validating is, for practical purposes, an artifact you never uploaded.

Here is the full procedure, plus the naming and association habits that keep validators from sending your package back with a note that says “evidence not located.”

Before you upload: know what the artifact proves

Every artifact in eMASS exists to answer one question for one or more controls: “show me.” A screenshot of your audit policy answers AU-2. A signed ISSO appointment letter answers PL-related and CA-related requirements. A STIG checklist export answers dozens of CM and SI CCIs at once. If you cannot say which controls a file supports, do not upload it yet. Unlinked files clutter the Artifacts tab and make the package look unfinished during review.

If you are still assembling the evidence set, the RMF artifacts checklist lists what a complete DoD package normally contains, and the seven artifacts missing from 90% of packages covers the ones that get forgotten.

Step 1: Open the Artifacts tab

From the eMASS home screen, search for or select your system. On the system record, click the Artifacts tab in the top navigation. You will see a table of everything already uploaded: name, type, upload date, who uploaded it, and how many controls it is associated with. That last column is your health metric. A package full of artifacts with “0” in the associations column is a package that is about to get rejected.

Step 2: Add the artifact

• Click Add Artifact (some instances label it New Artifact).
• Choose the file. eMASS accepts common office formats, PDF, images, and zip archives. Size limits vary by instance; if the upload fails silently, check the file size first.
• Fill in Artifact Name. Use the convention below, not the file’s original name.
• Pick the Artifact Type from the dropdown (policy, procedure, plan, evidence, diagram, and so on). Validators filter on this field.
• Write a one-line Description that says what it proves and the date it was captured.
• Set the Artifact Date (when the evidence was produced, not when you uploaded it) and, if your instance supports it, the review or expiration date.
• Save.

The naming convention that saves you during validation

Name artifacts so a stranger can identify them from the list without opening them. A pattern that has worked on every package I have touched: [Control family or ID] - [What it is] - [YYYY-MM]. For example, AU-2 - Audit Policy Screenshot - 2026-08 or CM-6 - Windows Server 2022 STIG Checklist - 2026-08. Compare that to Screenshot (14).png, which is what validators usually get, and which is why they usually get cranky.

Step 3: Associate the artifact with controls and CCIs

This is the step that matters. There are two directions you can do it from, and both end up in the same place.

From the artifact

Open the artifact you just saved. Look for an Associated Controls or Controls section and click Add or Associate. A picker lists the controls in your system’s baseline. Check every control the artifact supports, then save. One STIG checklist can legitimately support twenty controls, so do not stop at one.

From the control

Open the Controls tab, select the control, and go to its implementation or assessment-procedure view. Each CCI (Control Correlation Identifier) has a place to attach artifacts. Pick from artifacts already uploaded to the system. Working from the control side is slower but forces you to think at the CCI level, which is the level validators actually test.

If you are new to how controls, CCIs, and assessment procedures fit together, the complete eMASS guide walks the whole structure, and eMASS for beginners is the gentler on-ramp.

Step 4: Reference the artifact in the implementation statement

Association makes the artifact findable. The implementation statement tells the validator what to look for inside it. A sentence like “Audit event categories are configured per the settings shown in artifact AU-2 – Audit Policy Screenshot – 2026-08, page 1” turns a five-minute evidence hunt into a thirty-second confirmation. Validators remember ISSOs who do this. They also remember the other kind.

Common mistakes that get artifacts rejected

• Uploaded but not associated. The number one cause of “evidence not provided” findings on packages where the evidence was, in fact, provided.
• Stale evidence. A screenshot from two ATO cycles ago with an old hostname. Set the artifact date honestly and replace evidence older than your ConMon cadence allows.
• One giant zip for everything. Validators will not unzip 400 files to find one. Break evidence into artifacts that map to control families.
• Screenshots with no context. Include the hostname, the date/time, and the setting path in the capture. A cropped checkbox proves nothing.
• Duplicate uploads. Uploading the same policy five times under five names makes the package look chaotic. Upload once, associate many.

The pre-submission checklist for rejected eMASS packages covers the rest of the ways a package bounces.

Bulk uploads and replacing an artifact

Some eMASS instances offer a bulk artifact import that accepts a zip plus a spreadsheet mapping each file to its metadata. It is worth learning if you are onboarding a system with fifty-plus evidence files, but test it on two files first; a bad mapping sheet creates fifty artifacts with blank names, and deleting them one at a time is a special kind of afternoon.

To replace an artifact with a newer version, open the existing record and use the Replace or Upload New Version option rather than adding a fresh artifact. That keeps the control associations intact, so you do not have to redo Step 3.

A quick sanity check before you submit

Sort the Artifacts tab by the associations column. Anything at zero either needs to be associated or deleted. Then open three random controls that are marked Compliant and confirm each one has at least one attached artifact and an implementation statement that names it. If those three pass, the package is in better shape than the average package that reaches a validator.

If you want the complete, ordered list of everything an ATO package needs from Categorize through Monitor, the RMF Checklist is the printable version of what I use on every system.