NIST SP 800-137 Information Security Continuous Monitoring Guide: designing, running and assessing an ISCM programme

An authorisation that is three years old says very little about a system that changes every week. NIST SP 800-137 sets out how to replace that snapshot with information security continuous monitoring (ISCM): a strategy and programme that keep risk owners informed about assets, threats, vulnerabilities and control effectiveness often enough to make real decisions. Its companion, SP 800-137A, shows how to assess whether an ISCM programme actually works. This guide covers the six-step ISCM process, the three organisational tiers, how to set monitoring frequencies, how ISCM supports ongoing authorisation under the RMF Monitor step, how to run an 800-137A assessment, and where machine identities fit. It is for CISOs, ISCM and GRC programme leads, authorising officials, system owners and assessors. Status was checked on csrc.nist.gov on 27 October 2026.

Key takeaways

• ISCM is a programme, not a tool: SP 800-137 defines it as maintaining ongoing awareness of information security, vulnerabilities and threats to support organisational risk management decisions.
• Six steps, three tiers: define, establish, implement, analyse and report, respond, review and update, run at organisation, mission and business process, and system level.
• Frequency is a risk decision: SP 800-137 lists factors such as control volatility, impact level, known weaknesses, threat and vulnerability information and reporting requirements; "continuous" does not mean everything every minute.
• SP 800-137A makes the programme assessable: 128 assessment elements organised by the six steps, judged "Satisfied" or "Other than Satisfied", with optional criticality-weighted scoring.
• Identity data is monitoring data: inventories of service accounts, API keys, certificates and agent identities, and their privilege changes, belong in the ISCM strategy alongside vulnerabilities and configuration.

What it is and who it applies to

SP 800-137 is written for federal agencies, and it underpins the RMF Monitor step and the SP 800-53 controls CA-7 Continuous Monitoring and PM-31 Continuous Monitoring Strategy. Its approach is used well beyond government, in FedRAMP continuous monitoring and in any programme that needs to show a regulator that controls keep working between audits. The 2011 date means control references predate SP 800-53 Rev. 5, so map them to current control identifiers, but its process and its reasoning about frequency remain current. For evidence quality and control testing between audits, see the Audit Evidence and Continuous Controls Monitoring Guide.

Structure and key requirements

The six-step ISCM process

The three tiers

• Tier 1, organisation: risk tolerance, ISCM policy, organisation-wide metrics and common tooling. The risk executive function oversees the strategy and programme.
• Tier 2, mission and business processes: monitoring that reflects how risk to a business process aggregates across systems.
• Tier 3, information systems: system-level monitoring of controls, configurations, vulnerabilities and events, owned by the system owner and common control providers.

Roles

• Chief Information Officer: leads the ISCM programme and ensures it is established and implemented.
• Senior information security officer: establishes, implements and maintains the programme and develops its guidance.
• Authorising official: ensures ISCM is applied to the system and decides whether the risk of operating it remains acceptable.
• System owner and common control provider: set up system-level and common control monitoring, assessments and status reporting.

Setting monitoring frequency

SP 800-137 Section 3.2.2 lists the factors to weigh: security control volatility; system categorisation or impact level; controls or assessment objects providing critical functions; controls with identified weaknesses; organisational risk tolerance; threat information; vulnerability information; risk assessment results; output of monitoring strategy reviews; and reporting requirements. A practical frequency table:

SP 800-137 also names the processes that ISCM informs and is informed by, including patch management, asset management, license management, configuration management, vulnerability management and system authorisation. It gives metric examples such as the number of unauthorised access attempts, the number and severity of vulnerabilities revealed and remediated, and contingency plan testing dates and results.

ISCM and ongoing authorisation

SP 800-137 states that ongoing assessment of security control effectiveness supports a system's security authorisation over time, and SP 800-37 Rev. 2 describes the RMF as promoting near real-time risk management and ongoing authorisation through continuous monitoring. In practice, an authorising official can move from a fixed reauthorisation cycle to ongoing authorisation only when the ISCM programme produces trustworthy, timely data for that system, with clear triggers (a significant change, a new critical vulnerability, a failed control) that prompt a fresh risk decision. See the NIST Risk Management Framework (SP 800-37) Guide and the FedRAMP Guide.

Identity and NHI requirements

Most ISCM programmes were designed around devices, vulnerabilities and configurations. Identity, and machine identity in particular, is often the weakest feed, yet it changes faster than any of them: every deployment, integration and AI agent can create credentials.

• Inventory machine identities as assets: service accounts, workload identities, API keys, OAuth applications, certificates and agent identities, each with owner, privilege level and last use. Link this to CM-8 System Component Inventory and IA-4 Identifier Management. See the Non-Human Identity (NHI) Guide.
• Monitor privilege changes as they happen: new role assignments to machine identities, new OAuth consents and new keys on privileged accounts are high-volatility items. AC-2(4) Automated Audit Actions covers account creation and modification auditing.
• Track credential age and rotation: keys and secrets past their rotation date are a standing metric, not an annual audit finding.
• Watch behaviour, not just configuration: machine identities used from new locations, at new volumes or against new resources are a signal under SI-4 System Monitoring. See the Service Account Behavioural Baselining Guide.
• Protect the monitoring identities: the scanners, collectors and SIEM connectors that feed ISCM hold broad read access and sometimes write access. Treat them as privileged NHIs.

The Snowflake customer breach shows what an identity feed would have caught: single-factor passwords valid for years after theft, no network allow lists and service users with no owner. Each is a measurable, monitorable condition.

Implementation steps

1. Write the risk tolerance and strategy. Agree at Tier 1 what risk the organisation accepts and what decisions ISCM must support. Keep the strategy short and specific about scope and frequencies.
2. Choose metrics that drive decisions. For each metric, name the decision it informs and who makes it. Drop metrics nobody acts on.
3. Build the data architecture. Connect asset, vulnerability, configuration, identity and event sources to a common store, with asset identifiers that join across feeds.
4. Start with high-volatility, high-impact items. Inventory, vulnerabilities, configuration drift and privileged and machine identities on high-impact systems first.
5. Pilot with two systems. Produce real status reports for their authorising officials for one quarter, check data quality, and adjust frequency and thresholds before scaling.
6. Define response paths. For each threshold breach, state who responds, within what time, and how the plan of action and milestones (CA-5) is updated.
7. Report by tier. System owners need item-level detail; authorising officials need trends and exceptions; the risk executive needs aggregated risk.
8. Assess the programme. Run an SP 800-137A assessment after the first year and use the results to revise the strategy (step 6).

Small versus large organisations

• Small organisations: one strategy, a handful of metrics (inventory coverage, critical vulnerability age, configuration compliance, privileged account count), monthly review by the senior security owner.
• Large or federal organisations: tiered reporting, automated feeds per system, and ongoing authorisation for systems whose data is mature enough to support it.

Evidence and assessment

SP 800-137A describes how to assess an ISCM programme rather than individual controls.

• Elements: the Element Catalog holds 128 assessment elements, 89 derived from SP 800-137 and 39 from other sources. Each belongs to one of the six ISCM steps, and its identifier starts with the step number (for example 1-032). The organisational level is an attribute of each element.
• Traceability chains: elements are linked by ISCM aspect, such as strategy management, metrics and control assessment rigour, so an assessor can follow one theme from strategy to operations.
• Assessment process: plan, conduct (gather and analyse evidence) and report, including follow-on actions.
• Judgements: by default "Satisfied" or "Other than Satisfied", with gaps annotated. Organisations may use a finer scale. "Not Applicable" is not a judgement: a subject the organisation does not use must be addressed in the strategy and then judged.
• Criticality and scoring: elements can be marked critical according to the organisation's risk (for example high-value assets or insider threat). Scoring is optional: 1 for Satisfied, 0 otherwise, optionally weighted by criticality and shown as a percentage of the best possible score.

Evidence assessors will ask for: the ISCM strategy and policy; the metrics catalogue with frequencies; data flow diagrams; sample status reports at each tier; POA&M changes driven by monitoring; and records of strategy reviews. For control-level assessment procedures, see the NIST SP 800-53A Guide.

Programme metrics

• Percentage of assets, including machine identities, covered by automated monitoring feeds.
• Median age of open critical vulnerabilities and of credentials past their rotation date.
• Percentage of monitoring items collected at their defined frequency.
• Time from a threshold breach to a recorded response decision.
• SP 800-137A score, weighted by criticality, year on year.
• Number of systems under ongoing authorisation versus fixed-cycle reauthorisation.

Mapping to other frameworks

Common pitfalls

• Buying a dashboard and calling it ISCM: tools without a strategy, risk tolerance and response paths produce data nobody acts on.
• Uniform frequencies: monitoring everything at the same cadence wastes effort on stable controls and under-monitors volatile ones, ignoring the 800-137 frequency factors.
• Identity left out of the feeds: devices and vulnerabilities are monitored, but service accounts, API keys and OAuth grants appear only in annual reviews.
• No join key: asset, vulnerability and identity data cannot be correlated, so reports cannot say which business process is at risk.
• Ongoing authorisation without mature data: moving to ongoing authorisation before the monitoring data is complete and trusted removes the periodic check without replacing it.
• Never assessing the programme: without an 800-137A style assessment, gaps in strategy, metrics or response persist unnoticed.

Practitioner checklist

• Write a short ISCM strategy tied to an agreed risk tolerance, covering all three tiers.
• Set monitoring frequencies per item using the SP 800-137 factors, and record the reasoning.
• Include machine identities, keys, certificates and agent identities in inventory and monitoring feeds.
• Define a response owner and time limit for every metric threshold.
• Report differently to system owners, authorising officials and the risk executive.
• Treat monitoring tools and their service accounts as privileged NHIs.
• Run an SP 800-137A assessment using the Element Catalog at least annually.
• Move systems to ongoing authorisation only when their monitoring data is complete and trusted.

Standards and references

• NIST: SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations
• NIST: SP 800-137A, Assessing Information Security Continuous Monitoring (ISCM) Programs
• NIST: IR 8212, ISCMA: An Information Security Continuous Monitoring Program Assessment
• NIST: SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Audit Evidence and Continuous Controls Monitoring Guide · NIST Risk Management Framework (SP 800-37) Guide · NIST SP 800-53 Guide · Service Account Behavioural Baselining Guide