Skip to content
FedRAMP Rules Hub
JSON — GET /api — every slice

Keyboard shortcuts

Go

  • Scope — the control cataloggm
  • Plan — your last certification classgp
  • Collect — the recipe indexgc
  • The control you are workinggw
  • Startgh

Move

  • Next rowj
  • Previous rowk
  • Previous in this run[
  • Next in this run]
  • Filter this page's list/
  • Search everything⌘K

Act

  • Copy this page's permalinky
  • Toggle dark moded
  • This sheet?

Rows are whatever the current page lists — controls on Scope, recipes on Plan and Collect.

Three senses of “machine-automatable”

“Machine-automatable” means three different things — a property of the control, a fact about the KSI graph, or a rule that mandates automation — and most confusing FedRAMP conversations are two people using two of them.

Rendered from FedRAMP Consolidated Rules for 2026 version 2026.07.14.01

Ask “how many controls are machine-automatable?” and you can mean three different things, with wildly different answers. Most confusing FedRAMP conversations — and most over-claiming products — are two people using two different senses of the same word without noticing. Hold them apart and you can resolve the argument by restating the question.

The three senses

  1. Sense 1 — Collectable. Can a machine collect probative evidence for this control? A property of the control's subject matter. No authority publishes the list — any number here is somebody's triage.

  2. Sense 2 — Indicator-reached. Has FedRAMP defined a Key Security Indicator over it? A hard, checkable fact of the KSI graph. A baselined control no indicator reaches is an indicator orphan.

  3. Sense 3 — Automation-mandated. Does a rule require automation as such, independent of which controls are in scope? These rules are per class and they are where the real automation obligation lives.

Sense 2 is the only one that is a checkable fact — the edges are in the dataset and /coverage counts them live. Sense 1 is always somebody’s triage, and an honest one says so. Sense 3 is where the real obligation lives, and it gets its own step. Now sort nine statements — the drill is the step:

  1. Statement 1 of 9

    PE-18 asks where system components physically sit — which rooms, which racks. No API returns that.

  2. Statement 2 of 9

    Providers seeking Class C certification must implement at least 2 automated methods for each Key Security Indicator.

  3. Statement 3 of 9

    Your baseline contains controls that no Key Security Indicator names. They are in scope, but 20x's continuous machinery has no opinion about them.

  4. Statement 4 of 9

    A GuardDuty finding is probative evidence for a monitoring claim: a machine detected the event and a machine can fetch the record.

  5. Statement 5 of 9

    Static code analysis is in the class C baseline and the annual assessment subset, yet no indicator reaches SA-11 (01).

  6. Statement 6 of 9

    At Class C you must supply historical metrics from persistent validation over at least the past 6 months — whatever you automated.

  7. Statement 7 of 9

    “The effectiveness of cybersecurity training is persistently reviewed” — a review with a human in it, whatever tooling surrounds it.

  8. Statement 8 of 9

    AC-2 appears in the crosswalk under several indicators; its enhancements each appear under fewer.

  9. Statement 9 of 9

    Moving from Class C to Class D doubles the automated methods owed per indicator, from at least 2 to at least 4.