How to import and export eMASS data
Import as a reviewable session that a person accepts, never as a silent write. Export with POA&M items upserting on their eMASS external identifier. Keep imported data labeled as imported, and refuse any proposal whose target changed since it was prepared.
Moving data in and out of eMASS is mostly a solved technical problem. What is not solved on most programs is doing it repeatedly without degrading the record on either end.
This page is about the rules that make a round trip safe, and the specific failures that happen when they are missing.
What can move
Out of eMASS, into your working record:
- The control baseline and per-control implementation information
- POA&M items, with the external identifiers eMASS assigned them
- Inheritance relationships recorded upstream
- Inventory
Into eMASS, from your working record:
- Control information — implementation state per control
- CCI test results — per-CCI assessment outcomes
- POA&M items — updated, not duplicated
- Inventory — the current asset picture
Both directions matter. A program that already has an ATO is not starting from zero, and a tool that can only push is assuming a situation almost nobody is in.
Rule 1 — import is a proposal, not a write
The single most important rule. An import should never write directly into an authorization record.
It should arrive as a reviewable session: here is what was found, here is what it would change, accept or reject. A person accepts, and the acceptance is the authoritative act, audited with a timestamp and a name.
The reason is not caution for its own sake. It is that an authorization record whose contents may have arrived from an external system without anyone noticing cannot be defended. Six months later, when a reviewer asks who established a fact, “an import, probably” is not an answer.
Rule 2 — imported data stays labeled
A control marked as inherited in eMASS should still be identifiable as inherited after import. A statement that came from an import should carry that fact.
This sounds like bookkeeping and it prevents a specific expensive failure. Inheritance means another system’s common control provider is carrying that control for you. If the label is lost, your record now asserts local implementation of something you do not implement — and the first person to notice will be an assessor asking for evidence you never had.
Rule 3 — refuse stale proposals
If the target of an import changed between the session being prepared and someone accepting it, refuse rather than overwrite.
Somebody made a more recent decision. The queued import represents an older state. Applying it silently reverts a human decision to an external system’s older view, and nobody will notice until the reverted decision matters.
Refuse, tell the user what changed, and let them decide.
Rule 4 — POA&M items upsert on the external identifier
This is the export-side rule and it is the one that gets missed most often.
When a POA&M item is exported to eMASS, eMASS assigns it an external identifier. That identifier must be stored against your local item. On the next export, the item is matched on it and updated.
Without this, every export cycle creates a fresh copy of your entire POA&M alongside the items your reviewer already has open. The consequences compound: the reviewer cannot tell which copy is current, closed items reappear as open, and your program looks like it is not tracking its own remediation.
Ask any vendor to demonstrate two consecutive exports. It is a two-minute test and it is decisive.
Rule 5 — audit both directions
Every import and export should produce an audit event: timestamp in UTC, the user, the action, the target, the result, and a correlation identifier that ties the whole operation together.
When somebody asks in eight months why a control status changed, this is the record that answers. When a partial export fails halfway, this is how you determine what made it across.
The transport
eMASS API access uses mutual TLS with a client certificate. Two things to get right:
The certificate belongs in an environment secret or a vault, not in a configuration file and certainly not in source control. It is a credential to a government system of record.
The API account should hold the narrowest scope that does the job. If the integration only needs to write POA&M and control information, it should not be able to do more.
The bundle alternative
Not every submission goes over the API. Where it does not, the shape that works is a single archive carrying inventory, control information, CCI test results and POA&M exports.
Include a SHA-256 checksum manifest. It costs nothing to produce and it lets the receiving end verify the contents rather than assume them. It also gives you a defensible answer to “are you sure that is what you sent?”
A sequence that works
For a program with an existing ATO bringing its record into a working system:
- Import the baseline and POA&M from eMASS as a review session.
- Work through the session. Accept what is right, reject what is not, and note what looks wrong — an eMASS record is frequently the most accurate statement of what the program agreed to, and frequently out of date relative to what the system now is.
- Reconcile against reality. Inventory drift, applicability drift, expired evidence. This is where the gap between the authorized system and the running system becomes visible, and it is usually larger than expected.
- Do the work in the operational record from that point on.
- Export back on your submission cadence, with upsert, and verify the reviewer’s view matches yours.
Step 3 is uncomfortable and it is the point of the exercise. Most programs have never seen that gap laid out explicitly.
What to watch for
- Silent writes. If import does not produce a review session, the record is being modified by an external system without human authorization.
- Lost inheritance. Check a known-inherited control after import.
- Duplicate POA&M items. Two consecutive exports. The decisive test.
- Certificates in config files. A credential to a government system of record, stored where the next person to clone the repository will find it.
- Partial failures with no record. Ask what happens when export three of four fails.