RMFInsider

An ATO with conditions is a full Authorization to Operate in which the Authorizing Official accepts the residual risk on the condition that you complete specific actions by specific dates. It is not a lesser authorization and it is not an IATT. Your system is authorized to operate in production the day the letter is signed. What changes is that the letter now contains a list of obligations, each with a due date, and the AO has told you in writing that the authorization depends on meeting them. Miss them without a documented extension and the AO can downgrade, suspend, or revoke the ATO, and the DoDI 8510.01 language gives them the authority to do exactly that.

In my experience the conditional ATO is the normal outcome, not the exception. A clean ATO with zero conditions happens when a system is small, mature, and lucky. Everyone else gets a letter with an enclosure. This post covers what typically ends up in that enclosure, how the 30, 60, 90, and 180 day clocks work, how to track conditions so nothing slips silently, and what to do when you know you are going to miss one.

What the conditions usually are

Conditions come from two places: the findings in the Security Assessment Report that the AO was not willing to accept as open POA&M items for the full authorization term, and package deficiencies the AO staff flagged during review. Across the conditional ATOs I have worked, the conditions cluster into a handful of types:

• Remediate specific CAT I findings within 30 days. The AO authorized despite an open CAT I because the mission needed the system live, but the tolerance is short. This is the condition that gets systems revoked.
• Remediate CAT II findings or reduce the open count below a threshold within 90 or 180 days. Often written as “reduce open CAT II findings by 50 percent” or “close all CAT II findings older than 120 days.”
• Deliver a missing or deficient artifact. An approved contingency plan, a completed CP-4 test, a signed ISA, a privacy impact assessment, or an updated boundary diagram, usually within 60 days.
• Complete a technical action. Implement MFA for a privileged account population, migrate off an end-of-life operating system, enable audit forwarding to the CSSP, or fix a boundary protection gap.
• Provide a status report on a cadence. A monthly POA&M update to the AO staff, or a quarterly vulnerability trend brief, for the life of the authorization.
• Re-scan and re-submit evidence. A fresh ACAS scan set and STIG checklist import at 90 days demonstrating the remediation took.

Read the letter twice, then read the enclosure three times. The conditions are sometimes stated in the body of the letter, sometimes in an attached memorandum, and sometimes only in the AO’s decision comments inside eMASS. I have seen an ISSO track four conditions from the letter and miss a fifth that lived only in the eMASS approval comment field. Pull every source together on day one.

How the clocks work

The AO sets the timelines, and there is no DoD-wide table that dictates them, but the clocks follow a predictable logic based on risk tolerance. Here is what the numbers usually mean in practice:

• 30 days: Reserved for CAT I remediation or an action the AO considers a near-term threat. The AO staff will check at day 30, not day 45. Treat this as an operational task, not a paperwork task.
• 60 days: Missing documentation and moderate technical fixes that require a change request but not a procurement.
• 90 days: The default for CAT II remediation batches and for anything that requires coordination with another organization, like a CSSP onboarding or an enterprise service migration.
• 180 days: Larger technical efforts: operating system migrations, architecture changes, or funding-dependent fixes. Conditions this long usually come with an interim status report requirement at 90 days.

The clock starts on the authorization date printed on the letter, not on the day you received the email, and not on the day you found the enclosure. If the letter is dated the 1st and it reached your inbox on the 9th, you already lost eight days. Calculate every due date the day you get the letter and put them on a calendar that someone other than you can see.

Some AOs write hard dates; others write “within 90 days of authorization.” Convert relative dates immediately and confirm calendar versus business days with the AO staff, because their interpretation is the one that counts.

Tracking conditions so nothing slips silently

The failure mode I have watched repeatedly is not that an ISSO ignored a condition. It is that the condition lived in a PDF, the POA&M lived in eMASS, the technical work lived in a ticketing system, and nobody reconciled the three until the AO staff sent the 15-day warning. The fix is to make each condition a first-class tracked item with a single owner.

Step 1: Convert every condition into a POA&M item

If a condition maps to an existing finding, update that POA&M item’s scheduled completion date to match the condition due date and note in the comments that it is an authorization condition. If a condition is a deliverable rather than a finding (a contingency plan test, for example), create a POA&M item for it anyway, tied to the relevant control (CP-4 in that case), so it is visible in the same place as everything else. The walkthrough for entering a POA&M in eMASS covers the field-level detail; the key is that the scheduled completion date must be on or before the condition date, never after.

Step 2: Build a conditions tracker outside eMASS

eMASS is the system of record, but it is a poor dashboard. Keep a separate tracker, even a simple spreadsheet, with one row per condition: the exact condition text quoted from the letter, the source (letter body, enclosure, or eMASS comment), the due date, the responsible person by name, the linked POA&M item number, the current status, the evidence you will submit, and the date the AO staff acknowledged closure. That last column matters. A condition is not closed when you finish the work; it is closed when the AO staff accepts your evidence.

Step 3: Assign named owners and weekly checkpoints

Every condition gets a named owner who is not the ISSO unless the ISSO is genuinely doing the work. An OS migration belongs to the sysadmin lead; a signed ISA belongs to whoever owns the partner relationship. The ISSO owns the tracker and the AO staff communication. Review the tracker weekly in a meeting the program already has; a new meeting will get skipped.

Step 4: Collect evidence as you go

For a CAT I remediation condition, the evidence is the post-remediation scan, the updated STIG checklist, and the change record. For a documentation condition, it is the signed document and its eMASS upload. Stage evidence as each piece lands, so the closure submission is a memo pointing to items that already exist.

Communicating with the AO staff

The AO does not read your emails; the AO’s staff does, and they are the people who decide whether your closure package goes forward with a recommendation to accept or a recommendation to escalate. Treat them as the audience. A few habits that have served me well:

• Send an acknowledgment within a week of the letter that lists each condition as you understand it, the owner, and the target date. If you misread a condition, this is when you find out.
• Send status at the midpoint of the longest clock even if nobody asked. A short, factual note that three of five conditions are closed and two are on track costs nothing and buys credibility.
• When you submit closure evidence, submit one condition at a time with a clear subject line and the POA&M item number. Bundling five closures into one email guarantees one of them gets missed.
• Ask how they want to receive it. Some AO staffs want a memo uploaded to eMASS with a workflow notification; others want an email with attachments. The package submission mechanics in eMASS apply to the closure package too, but the staff preference wins.

What to do when you know you will miss one

You will know before the AO staff does. The migration slipped because the hardware arrived late, the partner organization has not signed the ISA, or the CAT I fix broke a production service and had to be rolled back. The moment you know, you have a decision: request an extension formally, or hope nobody checks. Only one of those is a strategy.

A formal extension request goes to the AO through the ISSM and contains five things: the condition as written, the original due date, what was completed so far with evidence, the specific reason for the slip, and a new date with the mitigations you have in place until then. Submit it before the due date, not after. An extension requested at day 85 of a 90-day clock is a professional courtesy. The same request at day 95 is a report of noncompliance, and the AO staff will treat it that way in their recommendation.

Include compensating measures in the request. If the CAT I cannot be fixed because the vendor patch does not exist yet, describe the network segmentation, the monitoring rule, and the access restriction you applied in the meantime. AOs extend conditions when the risk story holds together. They revoke when the story is “we did not get to it.”

What happens if you actually miss

The consequences escalate in a fairly consistent order. First, the AO staff sends a notice requesting status, usually with a short response window. Second, if the response is inadequate, the AO can issue a modified authorization: a shortened ATO term, additional conditions, or a Denial of Authorization to Operate with a grace period. Third, for CAT I conditions or repeated slips, the AO can revoke the ATO, which means the system must be disconnected from the network. I have watched this happen to a system that everyone assumed was too important to disconnect. The AO disagreed, and the program spent six weeks in an emergency reauthorization effort that would have been a two-week condition closure if anyone had answered the first status request.

Revocation also follows you. When you come back for reauthorization, the timeline for that ATO will be longer, the AO staff will scrutinize the package harder, and the new letter will likely carry more conditions and shorter clocks. The reasons ATOs get delayed compound when the AO has already seen your program miss a commitment.

Turning a conditional ATO into a clean reauthorization

The upside of a conditional ATO is that the AO has told you exactly what a clean package looks like next time. Every condition closed on time becomes a documented strength: you had a CAT I, you closed it in 22 days, here is the evidence. At reauthorization the AO staff will already know your name for the right reasons.

The whole thing comes down to tracking discipline. If you want the tracker structure I described, with the condition text, owner, due date, POA&M linkage, evidence, and AO acknowledgment columns already laid out, the POA&M Tracker is built for exactly this and it is what I use to keep conditional ATOs from turning into revoked ones.