---

Most ISSOs think Continuous Monitoring means:

• Run scans
• Upload results
• Update eMASS

That’s why their ATO slowly falls apart.

Because Continuous Monitoring is not a checklist.

It’s not a monthly task.

It’s a continuous understanding of your system’s risk — in real time.

And here’s the problem:

Most teams don’t actually understand their risk.

---

The Real Lesson From the Field (What Practitioners Are Saying)

In a real discussion among RMF practitioners, one theme came up over and over:

People weren’t struggling with tools…
They were struggling with what actually matters in monitoring.

One person basically described their process as:

“We run scans, track findings, update artifacts… but I still don’t feel like I understand the system’s risk.”

That right there?

That’s the core issue.

---

Insight (This is important)

Continuous Monitoring fails when it becomes activity-based instead of insight-based

---

The Lie About Continuous Monitoring

Most RMF guidance makes it sound like:

• Run scans weekly/monthly
• Review logs
• Update POA&M

Done.

---

Reality from practitioners:

• Scans happen… but no one analyzes trends
• Logs exist… but no one reviews them meaningfully
• POA&Ms get updated… but don’t reflect real risk

---

Hard Truth

Continuous Monitoring is not about doing tasks
It’s about maintaining situational awareness

---

What Continuous Monitoring Actually Is

Continuous Monitoring is:

The ability to answer — at any time — whether your system is becoming more or less risky

---

That’s it.

---

Why Most Systems Drift After ATO

Let’s talk real-world.

A system gets ATO.

Everything looks good.

---

Then over time:

• Engineers install new software
• Configurations change
• Patches are delayed
• Logging gets misconfigured

---

Nobody tracks it holistically.

---

Result:

The system that was authorized…

No longer exists in that same state

---

This aligns with the idea that monitoring is meant to catch control failures early, not just during audits (Wikipedia)

---

What Actually Matters in Continuous Monitoring

Let’s break it down — with real insights.

---

1. Vulnerability Monitoring (But Smarter)

Most teams:

• Run Nessus
• Export results
• Upload to eMASS

---

Practitioners pointed out:

“We collect tons of scan data… but it’s hard to tell what actually matters.”

---

That’s the problem

You’re measuring:

• Volume of findings

Instead of:

• Movement of risk

---

What actually matters:

• Are critical vulnerabilities increasing?
• Are fixes happening within timelines?
• Are the same findings repeating?

---

Real Insight

A system with 200 findings can be healthier than one with 20 —
if the 200 are being actively managed

---

2. Configuration Drift (The Silent Failure)

This is where most systems quietly fail.

---

From real discussions:

People assumed:

“If we passed STIG once, we’re good.”

---

Reality:

Configurations change constantly.

• New users added
• Permissions modified
• Services enabled/disabled

---

No one tracks it properly.

---

Result:

Your system slowly becomes something you never authorized

---

What actually matters:

• Baseline vs current configuration
• Unauthorized changes
• Drift over time

---

3. Log Monitoring (Where Most Teams Lie to Themselves)

Let’s be honest.

Everyone says:

“We monitor logs”

---

But in reality:

• Logs are stored
• Alerts are noisy
• No one is accountable

---

Practitioners highlighted:

“We have logs everywhere… but not sure what we should actually look for.”

---

That’s the issue

Logging without strategy = noise

---

What actually matters:

• Detecting meaningful events
• Reducing false positives
• Assigning ownership

---

This aligns with controls like monitoring and event detection (e.g., SI-4, AU-2) that emphasize actionable security data, not just volume (Wikipedia)

---

4. POA&M Tracking (Where Monitoring Becomes Real)

This is where everything comes together.

---

From real-world experience:

Teams often:

• Update POA&M only before audits
• Treat it like documentation

---

Practitioners insight:

“Our POA&M doesn’t reflect reality — it’s just something we update.”

---

That’s dangerous

Because POA&M is supposed to show:

Your system’s risk trajectory

---

What actually matters:

• Are risks being reduced?
• Are deadlines realistic?
• Are owners accountable?

---

5. Change Management (The Most Underrated Piece)

This is where everything connects.

---

From real practitioner insight:

A big struggle was:

“We don’t always know when systems change.”

---

That’s a massive gap

Because:

Every change = potential new risk

---

Examples:

• New software deployed
• Firewall rule modified
• Server added

---

What actually matters:

• Knowing when changes happen
• Understanding impact
• Re-evaluating risk

---

The Biggest Continuous Monitoring Mistake

Treating it like a schedule.

---

“We scan every month”

That’s not monitoring.

---

Monitoring is:

Always knowing your system’s security state

---

The Core Problem (From Real Practitioners)

The biggest struggle wasn’t tools.

It was:

“How do I connect all this data into actual understanding?”

---

That’s the breakthrough

Continuous Monitoring is not about:

• Tools
• Data
• Reports

---

It’s about:

Turning signals into decisions

---

What Top ISSOs Do Differently

They don’t track everything.

They track what matters.

---

They focus on:

• High-impact vulnerabilities
• Critical system changes
• Meaningful logs
• Real risk trends

---

They ignore:

• Low-value noise
• Over-reporting
• Busywork

---

The Continuous Monitoring Framework (Use This)

---

1. Collect

• Scans
• Logs
• Configurations

---

2. Analyze

• What changed?
• What matters?

---

3. Decide

• Fix
• Mitigate
• Accept

---

4. Track

• POA&M
• Risk trends

---

Real Scenario (Straight From the Field)

System gets ATO.

---

2 months later:

• New app deployed
• Logging not updated
• STIG drift introduced

---

4 months later:

• Vulnerabilities increase
• No one notices trend

---

Audit happens:

“System no longer meets authorization conditions”

---

Root cause:

Not lack of tools.

Lack of real monitoring

---

The 3 Questions That Define Strong Monitoring

At any moment, you should know:

---

1. What are my top risks?

---

2. Has my system changed?

---

3. Is risk increasing or decreasing?

---

If you can’t answer these instantly…

You’re not monitoring.

---

Final Takeaway

Continuous Monitoring is not about:

• Compliance
• Reporting
• Tools

---

It’s about:

Clarity over time

---

If You Do This Right

You don’t:

• Fear audits
• Scramble for artifacts
• Chase engineers

---

You:

• Understand your system
• Control your risk
• Stay ahead

---

If You Want to Level This Up

Turn this into a system:

• Use your Notion tracker
• Track risk trends (not just findings)
• Build a monitoring dashboard

---

Because the goal isn’t:

“Stay compliant”

---

It’s:

Always know what’s happening in your system

Related reading: RMF Continuous Monitoring Checklist: Daily, Weekly, Monthly

Related reading: Continuous monitoring work gets split across three roles that people constantly mix up. Sort them out here: ISSO vs ISSM vs ISSE: what is the actual difference (and which pays more).

On the tooling side: IA-2 findings around multifactor come up in almost every ConMon cycle. If you are evaluating phishing-resistant options for privileged accounts, here is a practitioner review of the hardware most DoD shops end up testing: YubiKey 5 NFC review.