NIST 800-137 Continuous Monitoring: What to Track on Devices

Most advice on continuous monitoring stops at the definition. It tells you to monitor continuously, then leaves you to guess what that means for a fleet of laptops, servers and workstations on a Tuesday afternoon.

NIST's guidance is more specific than its reputation. It says what to monitor, how to decide how often, and how to tell whether your program works. This post walks through those answers for devices.

What does NIST SP 800-137 mean by continuous monitoring?

NIST SP 800-137 defines information security continuous monitoring (ISCM) as "maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions." The goal is a steady flow of evidence that feeds risk decisions, not a scan that runs more often. The document was published in September 2011 as a guideline.

Two details in that definition matter for devices:

• It is about decisions. Monitoring output exists so someone can accept, fix or transfer a risk.
• It names visibility into assets. The publication's abstract says the program should provide "visibility into organizational assets." You cannot monitor a host you do not know exists.

The guidance describes a cycle: define a strategy, establish a program, implement it, analyze and report findings, respond, then review and update. It is a loop, not a one-time project.

Is NIST 800-137 a requirement, or just guidance?

SP 800-137 is guidance. The requirement that carries the same idea into contractor environments is requirement 3.12.3 in NIST SP 800-171 Rev. 2: "Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls."

The discussion text under 3.12.3 reuses the 800-137 vocabulary almost word for word, including "ongoing awareness of threats, vulnerabilities, and information security to support organizational risk management decisions." It adds that the terms continuous and ongoing imply assessing controls and risks "at a frequency sufficient to support risk-based decisions."

Read together, the two documents give you a usable test. You are not asked to run a particular tool every N minutes. You are asked to monitor often enough that your risk decisions rest on current information.

How often do devices need to be monitored?

It depends on how fast the control changes. SP 800-137 lists "security control volatility" as the first criterion for setting frequency, and says volatile controls "are assessed more frequently." Its own example of a volatile family is configuration management, because "information system configurations typically experience high rates of change."

The guidance names two controls from that family:

1. CM-6, Configuration Settings. Whether a device is still set the way you intended.
2. CM-8, Information System Component Inventory. Whether your list of devices is complete and accurate.

For both, the document says they "may require more frequent assessment and monitoring, preferably using automated, SCAP-validated tools that provide alerts and status on demand."

By contrast, it describes personnel screening controls as static over long periods, so they need less frequent assessment. The practical reading is that device state belongs at the frequent end of the scale. A laptop's encryption, patch level and security settings can change in a day, so a quarterly look is a mismatch with the guidance itself. We covered the same decay problem from the auditor's side in your device posture check expires.

What should you actually monitor on a device?

Start with the two controls NIST names, then add the checks your own risk decisions depend on. NIST does not publish a device checklist, so the list below is our reading of how CM-6 and CM-8 apply to hosts, not a quotation of the standard.

For inventory (CM-8):

• Which hosts exist, from a source independent of enrollment
• When each one last reported
• Who owns it

For configuration (CM-6):

• Disk encryption state, covered in how to prove laptop disk encryption to a SOC 2 auditor
• Patch and update state, covered in SOC 2 patch management evidence
• Whether the operating system and firmware are still supported by their vendor
• Endpoint protection status, with a check-in time

Each item should be a timestamped record, not a status flag. A device that has not reported should appear as unknown, which is a different answer from "compliant." We explain why in unknown is an answer.

Does continuous monitoring have to be automated?

Mostly, yes, but not entirely. SP 800-137 states that "organization-wide monitoring cannot be efficiently achieved through manual processes alone or through automated processes alone." Where manual steps remain, they should be "repeatable and verifiable to enable consistent implementation."

It is firmer about technical controls. Many of the SP 800-53 technical controls, it says, "are good candidates for monitoring using automated tools and techniques," and real-time monitoring "can provide an organization with a much more dynamic view of the effectiveness of those controls and the security posture of the organization."

The 800-171 discussion says the same thing about inventory: "Automation supports more frequent updates to hardware, software, firmware inventories, and other system information."

For device evidence, that means sensors on the hosts themselves for the high-volatility checks, and documented manual procedures only where automation is not practical. A spreadsheet updated before an assessment is neither repeatable nor continuous.

What do assessors want to see from a monitoring program?

The 800-171 discussion text points to outputs. It says that "providing access to security information on a continuing basis through reports or dashboards gives organizational officials the capability to make effective and timely risk management decisions," and that outputs are most useful when they are "specific, measurable, actionable, relevant, and timely."

A companion document looks at the program itself. NIST SP 800-137A, published in May 2020, describes how to assess an ISCM program, reviewing "strategies, policies, procedures, operations, and analysis of continuous monitoring data." It evaluates the program's effectiveness and completeness, so an assessor can ask not only "what does the dashboard say" but "does the process behind it work."

A defensible evidence set for devices includes:

1. A written monitoring strategy that names the device checks and their frequencies
2. A complete device population with its source
3. Dated history for each check, not only the current state
4. Records of findings and the response to each one
5. Evidence that the program is reviewed and updated

Item four is where many programs fall short. Monitoring that detects a problem and records no response has only done half the loop. Remediation should end in a dated, human-approved action tied to the original finding. For a contractor preparing for assessment, what compliance software proves and does not prove explains where the tooling stops and the assessor begins.

How do you start without rebuilding everything?

Work from the volatile end first. A week of effort is enough to set a baseline:

1. Pick the two controls NIST names, configuration settings and component inventory, and write down the device checks for each.
2. Build the device population from at least two sources and reconcile the differences.
3. Set a frequency for each check and record why, using volatility as the criterion.
4. Make the output a dated record per device, with unknown as a valid state.
5. Decide who reviews findings, and how often, and write it down.

None of this requires a particular product. It requires treating the device population and its state as something you measure continuously rather than assert at assessment time.

Key takeaway

NIST SP 800-137 and requirement 3.12.3 ask for the same thing: ongoing awareness that supports risk decisions, at a frequency matched to how fast each control changes. For devices, that puts configuration and inventory at the frequent end, with automated, timestamped, historical records and an honest unknown when a host goes quiet.

See how SAUTERA scores hosts from live telemetry and shows an honest "unknown" instead of a false pass — start free at sautera.com.