NIST SP 800-137: How to Build a Right-Sized ISCM Program

Short answer: NIST SP 800-137 is NIST's guide to Information Security Continuous Monitoring (ISCM). It tells you how to define a monitoring strategy, pick metrics, set how often each control is checked, analyze and report results, respond to findings, and review the program. A small SaaS or HealthTech team can run a right-sized version with a short strategy document and a handful of automated metrics.

Related guides:

• What is continuous monitoring?
• Continuous monitoring expectations after FedRAMP authorization
• The ultimate guide to NIST 800-53

Key takeaways

• NIST SP 800-137 (September 2011) is a process guide, not a control catalog. It explains how to design and run an ISCM program, while SP 800-53 control CA-7 is the control that requires one.
• The core of the publication is a six-step process: define an ISCM strategy, establish the program, implement it, analyze and report, respond, and review and update.
• Monitoring frequency is a risk decision. Base it on how volatile a control is, how critical the system is and what threats you face, then write the rationale down.
• One well-run ISCM program produces the evidence a SOC 2 Type 2 auditor and an ISO 27001 auditor both look for, so you build it once.
• Start with a few high-value metrics and expand. Our illustrative 90-day plan shows one way a small team can sequence a first version.

---

What does NIST SP 800-137 actually require?

SP 800-137 asks organizations to maintain ongoing awareness of information security, vulnerabilities and threats so that risk decisions are based on current data rather than a point-in-time assessment. Its full title is "Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations," so vendors usually meet it indirectly, through FedRAMP, agency contracts or NIST-based security questionnaires.

Three tiers of monitoring

SP 800-137 organizes ISCM across three tiers:

Tier	Scope	What it looks like at a 50-person SaaS company
Tier 1: Organization	Risk tolerance, governance, overall strategy	Leadership approves the ISCM strategy and risk appetite, reviewed at least yearly
Tier 2: Mission/business processes	Processes and the systems that support them	Product lines or customer data flows (for example, the ePHI pipeline) with their own priorities
Tier 3: Information systems	Individual systems and their controls	Cloud accounts, production clusters, identity provider, endpoints

At a small company, Tiers 1 and 2 are often the same people. What matters is that decisions about acceptable risk drive which checks you run.

Where it fits in the NIST family

SP 800-137 supports the Monitor step of the Risk Management Framework in SP 800-37. The control that makes monitoring mandatory is CA-7 Continuous Monitoring in SP 800-53. A companion publication, SP 800-137A (2020), explains how to assess whether an ISCM program is working. SP 800-137 itself dates from 2011, before SP 800-53 Rev. 5, so pair its process guidance with current control baselines and check csrc.nist.gov for any newer revision. Teams that also manage supply chain risk can feed supplier monitoring into the same program, as described in our NIST SP 800-161 guide.

How do the six ISCM steps work for a small team?

The six steps form a continuous loop, and each produces evidence an assessor would expect to see.

1. Define an ISCM strategy. Write a short document stating risk tolerance, scope, monitoring owners and how results reach decision makers. Evidence: an approved, dated strategy document.
2. Establish an ISCM program. Choose your metrics, set monitoring and assessment frequencies for each control, and define the architecture: which tools collect data, where it is stored and how it is aggregated. Evidence: a metrics catalog with owners and frequencies.
3. Implement the program. Connect cloud configuration checks, vulnerability scanners, identity logs and ticketing so data flows automatically where possible. Evidence: tool configurations, dashboards and collected data.
4. Analyze data and report findings. Compare results against thresholds. Engineers need daily signals; leadership needs a monthly or quarterly view. Evidence: reports, dashboards and meeting notes.
5. Respond to findings. Each finding gets a risk response: mitigate it, accept it with a documented rationale, avoid it, or share or transfer it, consistent with the risk response options in NIST SP 800-39. Evidence: tickets, risk register entries and, for federal work, plan of action and milestones (POA&M) items.
6. Review and update the strategy and program. Revisit metrics and frequencies after major changes, incidents or new threats, and at least yearly. Evidence: review records and a change history for the strategy.

Which ISCM metrics should you track, and how often?

Start with a few metrics tied to your highest risks, each with an owner, a threshold and a frequency. The table shows illustrative examples for a cloud-hosted SaaS or HealthTech product, not NIST requirements. Adjust them to your own risk assessment.

Example metric	Related 800-53 family	Example frequency	Example threshold
Cloud configuration drift against your baseline	CM	Continuous (automated)	Critical misconfigurations triaged same day
Critical and high vulnerabilities past remediation target	RA, SI	Daily scan results, weekly review	Zero critical items past target
Accounts without MFA in the identity provider	IA	Daily (automated)	Zero
Privileged access review completion	AC	Quarterly	100% of privileged accounts reviewed
Terminated users with active access	AC, PS	Daily or per offboarding event	Zero after 24 hours
Audit logging enabled on production systems	AU	Continuous (automated)	No gaps in log sources
Backup restore test success	CP	Quarterly	Successful restore within target time
Critical vendor reassessments completed	SR, SA	Annually per vendor, tracked monthly	No overdue critical vendors

Notice the split between monitoring frequency (how often data is collected) and assessment or review frequency (how often a person evaluates it). SP 800-137 treats both as decisions you make and document.

How do you set monitoring frequencies?

Set frequency by weighing three factors: how volatile the control is, how critical the affected system is, and how active the relevant threats are. A control that changes often, protects sensitive data, and faces active exploitation needs near real-time monitoring. A stable, low-impact control can be checked quarterly or annually.

• Volatility. Configurations, accounts and software versions change daily, so check them automatically. Policies and physical security change rarely, so annual review is usually reasonable.
• Criticality. Systems that store ePHI, payment data or customer credentials, or that support availability commitments, earn higher frequencies than internal tools.
• Threat. When a widely exploited vulnerability affects your stack, temporarily raise the frequency for that area. SP 800-137 expects frequencies to change as threat information changes.

Also weigh automation (automated collection makes higher frequency cheap) and response capacity (monitoring faster than you can respond only builds a backlog). Record the rationale for each frequency in your metrics catalog. Assessors look for that reasoning, not just the number.

How does ISCM map to SOC 2 Type 2 and ISO 27001?

An SP 800-137 program directly supports the monitoring expectations in SOC 2 and ISO 27001, so you can run one program and map its outputs to each framework. The table below is our own mapping, not an official crosswalk from NIST, the AICPA or ISO.

ISCM element	SOC 2 (2017 Trust Services Criteria)	ISO/IEC 27001:2022
Strategy and risk tolerance	CC3 risk assessment criteria	Clause 6 planning and risk assessment
Metrics, frequencies, data collection	CC4.1 ongoing and separate evaluations; CC7.1 and CC7.2 detection and monitoring	Clause 9.1 monitoring, measurement, analysis and evaluation
Analysis and reporting to leadership	CC2 communication; CC4.2 communicating deficiencies	Clause 9.3 management review
Response to findings	CC4.2 deficiencies routed for corrective action; CC7.3 to CC7.5 incident handling	Clause 10 nonconformity and corrective action
Program review	CC4.1 evaluations of control effectiveness	Clause 9.2 internal audit; Clause 10 continual improvement

The biggest payoff is with SOC 2 Type 2, where the auditor samples evidence across the observation period. A working ISCM program means that evidence already exists: daily configuration checks, quarterly access reviews and dated tickets showing remediation. For ISO 27001, clause 9.1 asks you to decide what to monitor, the methods, when to monitor and analyze, and who does it. Your metrics catalog answers each of those questions.

If you also use the NIST Cybersecurity Framework, ISCM metrics fit naturally under its Detect and Govern functions. See our NIST CSF 2.0 overview for how those functions are organized.

What does a 90-day ISCM starter plan look like?

The plan below is our own illustrative sequence, not NIST guidance. Adjust the timing to your team and scope: strategy first, then automation of a few high-value metrics, then reporting and response.

Days 1 to 30: Strategy and scope

• Confirm the systems in scope, starting with production and anything that holds customer data or ePHI.
• Write the ISCM strategy: risk tolerance, roles, reporting lines and review cadence. Get leadership sign-off.
• Pick 8 to 12 metrics from your risk assessment and draft frequencies with a short rationale for each.

Days 31 to 60: Instrumentation

• Connect automated sources: cloud configuration checks, vulnerability scanning, identity provider, endpoint management and logging.
• Set thresholds and route alerts to a ticketing queue with named owners.
• Schedule the manual controls such as access reviews, backup restore tests and vendor reassessments.

Days 61 to 90: Reporting, response and review

• Publish a monthly ISCM report for leadership and a weekly engineering view.
• Track every finding to closure or documented risk acceptance in your risk register.
• Hold the first program review. Adjust any metric that produced noise, and add any risk that was missed.

By day 90 you should have a signed strategy, a metrics catalog, live data and one full cycle of reporting and response.

How SecureSlate helps

SecureSlate gives small SaaS and HealthTech teams the building blocks of an ISCM program without a large security operations staff. You can maintain your ISCM strategy and policies, map the related controls for SOC 2 and ISO 27001, keep monitoring evidence attached to each control, and track findings in a shared risk register.

Together with vendor risk tracking, that helps you show assessors that monitoring runs on schedule and findings get a documented response.

Start your free SecureSlate trial

FAQ

Is NIST SP 800-137 mandatory for private companies?

Not directly. It was written for federal agencies and their systems. Private companies usually encounter it through FedRAMP, agency contracts or customers who reference NIST controls, and in those cases the CA-7 control in SP 800-53 effectively requires an ISCM program.

What is the difference between an ISCM strategy and an ISCM program?

The strategy is the decision layer: risk tolerance, scope, roles and how results inform decisions. The program is how you carry it out: the metrics, frequencies, tools, reports and response processes. SP 800-137 treats defining the strategy and establishing the program as separate steps.

How is SP 800-137A different from SP 800-137?

SP 800-137 explains how to build and run an ISCM program. SP 800-137A, published in 2020, provides guidance for assessing whether an existing ISCM program is designed and operating effectively. Use 800-137 to build and 800-137A to evaluate.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.