RMFInsider

A scan finishes, and there they are: STIG CAT I findings, sitting at the top of the report in red. Every ISSO knows the feeling — the AO wants them closed, the system owner wants the mission system to keep running, and you’re the one standing between “immediately” and “not this week.” This is how to actually close CAT I findings without taking down a production system in the process.

What CAT I, CAT II, and CAT III Actually Mean

STIG severity categories aren’t a vague “high/medium/low” scale — each one maps to a specific kind of exposure, and that distinction drives how fast you’re expected to move.

Category	Risk level	What it means	Expected timeline
CAT I	Highest	Provides immediate access to the system or network, or superuser/root-level access	Address immediately
CAT II	Medium	Has a high potential for giving an intruder access to the system or network	Remediate promptly
CAT III	Lowest	Discloses information that could potentially lead to compromise	Lower urgency, still tracked

Your scan tools report these ratings automatically. Whether findings come from a manual STIG checklist review, ACAS scanning through Tenable Nessus, or DISA SecurityCenter (SCC), the CAT rating travels with the finding — it’s the same classification scheme across every tool, which is exactly why an AO expects consistent handling of CAT I findings regardless of where they were discovered.

Prioritizing STIG CAT I Findings Without Halting Operations

“Address immediately” doesn’t mean “apply the fix blind at 2 p.m. on a production system.” It means CAT I findings jump to the front of your queue and get a same-day risk conversation, even if the actual fix takes longer to implement safely. There’s a difference between acting immediately and fixing immediately, and conflating the two is how ISSOs break systems and lose credibility with system owners in the same afternoon.

A workable triage sequence for a fresh batch of CAT I findings:

• Confirm it’s a true positive. Scanner findings on legacy systems and unusual configurations produce false positives often enough that verifying against the actual STIG check-content before you touch anything saves you from breaking something over a finding that wasn’t real.
• Check for compensating controls already in place. A CAT I finding sitting behind a hardened network boundary and strict access control is a different risk conversation than the same finding on an internet-facing host.
• Separate findings that are safe to fix same-day from findings that need a maintenance window. Account lockout policy misconfigurations are usually low-risk to fix immediately. A finding that requires a service restart on a system supporting live operations is not.
• Loop in the system owner before, not after. Nobody wants a call explaining why the mission system went down because a STIG fix got pushed without warning.

The goal isn’t to slow-walk CAT I findings — it’s to make sure the fix doesn’t create a bigger risk than the finding did. An AO who sees a CAT I finding sit open for three weeks with zero documentation is a very different conversation than an AO who sees a CAT I finding with a same-day risk assessment, a scheduled fix window five days out, and a signed acceptance of the interim risk.

Common CAT I Scenarios ISSOs Actually See

A few CAT I findings show up on nearly every system, and each one carries its own set of trade-offs:

• Unnecessary services running with elevated privileges. Usually safe to disable outside business hours, but confirm nothing downstream depends on that service first — a quick check with the system admin beats an outage ticket.
• Weak or default account configurations. Often fixable same-day, but on systems with automated service accounts, changing authentication behavior can break integrations that were never documented anywhere.
• Missing security patches tied to a known exploit. The clock matters more here than almost any other CAT I type — if the vulnerability is actively being exploited in the wild, “scheduled maintenance window next month” is not going to satisfy an AO, and it shouldn’t.
• Legacy application dependencies that break when a STIG setting is applied. This is the hardest category — the fix is correct per the STIG, but the application wasn’t built to tolerate it. This is where mitigation, a documented exception request, and a modernization timeline usually replace an immediate fix.

That last category is where most CAT I findings actually live past their initial discovery date. A finding tied to a legacy dependency isn’t a documentation failure on your part — it’s a system architecture problem that needs a modernization conversation with the system owner, not just a POA&M line.

Mitigation vs. Remediation: Two Different Fixes

These two words get used interchangeably in casual conversation and mean genuinely different things in a POA&M.

• Remediation closes the finding outright — you apply the STIG-prescribed fix, the vulnerable configuration no longer exists, and a rescan comes back clean.
• Mitigation reduces the risk without eliminating the underlying condition — a compensating control, added monitoring, or a network restriction that makes the finding harder to exploit while a permanent fix is scheduled.

For a CAT I finding, mitigation is the bridge, not the destination. An AO will generally accept a documented mitigation as an interim step, but expects a remediation date on the calendar. A CAT I finding that’s been “mitigated” for eight months with no remediation plan reads as a finding the ISSO gave up on, not one that’s actively managed.

Documenting Residual Risk in a POA&M

Every CAT I finding that isn’t remediated same-day needs a POA&M entry that actually explains the situation — not a placeholder line that says “in progress.” At minimum, that entry should cover:

• The specific STIG check ID and what it’s testing for
• Why the fix wasn’t applied immediately (maintenance window, operational dependency, testing required)
• What compensating or mitigating control is in place right now
• A specific remediation date, not “TBD”
• Who owns the fix — usually the system administrator, not the ISSO

If you haven’t nailed down the mechanics of getting a finding entered correctly, walk through how to write a POA&M and, if your package lives in eMASS, how to enter a POA&M in eMASS step by step. A CAT I entry that’s missing a milestone date or an owner is the fastest way to get your package kicked back during an SCA review.

Coordinating with the AO on CAT I Findings

The AO’s job is to accept or reject risk, not to manage your fix schedule. Your job as the ISSO is to give them a clear enough picture that they can make that call without chasing you for details. For a CAT I finding specifically:

• Don’t wait for a scheduled continuous monitoring report to surface a new CAT I finding — flag it as soon as it’s confirmed real.
• Bring a mitigation plan to the conversation, not just the problem. An AO who has to ask “so what are you doing about it” hasn’t been briefed properly.
• Get the risk acceptance in writing if the fix timeline extends past what the AO would normally expect for CAT I severity. Verbal “that’s fine for now” doesn’t hold up during an audit.
• Track every CAT I finding’s fix status separately from CAT II/III — most AOs want a standing CAT I status view, not something buried in a quarterly summary.

If you’re still building out how STIGs get applied on your system in the first place, a practical STIG application checklist covers the scanning and implementation side that feeds into this whole triage process.

A Practical Workflow for Closing CAT I Findings

Put together, a workable cadence looks like this:

• Day 0: Finding surfaces via scan or manual check. Confirm it’s a true positive and check for existing compensating controls.
• Day 0–1: Notify the AO and system owner. Open the POA&M entry with an initial risk statement, even if remediation details are still being worked out.
• Day 1–3: Determine remediation path. Same-day fixes get applied same-day. Anything needing a maintenance window gets scheduled and documented.
• Ongoing: If remediation slips past the scheduled window, update the POA&M with the new date and the reason — don’t let it go stale silently.
• Close-out: Rescan to confirm remediation, update the POA&M status, and keep the evidence artifact (scan output, change record) attached for the next assessment.

None of this is complicated once it’s a habit — the failure mode is almost always inconsistency, not ignorance. A CAT I finding that gets full documentation once and then goes quiet for two months is how ISSOs end up explaining a stale POA&M to an assessor instead of a managed one. Set a recurring review — weekly at minimum for anything with open CAT I findings — so status updates happen on a schedule instead of only when someone asks.

If you want a repeatable structure for this instead of rebuilding your triage process every scan cycle, the RMF Checklist walks through STIG prioritization and POA&M documentation side by side, and the POA&M Tracker gives you a template built specifically for tracking CAT I/II/III findings from discovery to close-out.