RMF & NIST Glossary — SSP, POA&M, ATO, Baselines

Plain-language definitions of RMF, NIST SP 800-53, and FedRAMP terms — SSP, POA&M, ATO, control baselines, and more. An educational reference.

Key terms

Continuous ATO (cATO) (cATO): A Continuous Authorization to Operate moves authorization away from a point-in-time, document-based assessment toward continuous risk determination. The DoD CIO cATO memo (Feb 2022) requires three things: continuous monitoring of all controls with real-time telemetry, active cyber defense, and an approved DevSecOps reference design. It builds on NIST SP 800-37 Rev. 2's ongoing authorization — the system keeps a live authorization status as long as its monitoring data keeps flowing to the AO.
Ongoing authorization: Ongoing (or continuous) authorization is the RMF mechanism, inside Step 6 (Monitor), that lets an Authorizing Official maintain an authorization based on a steady stream of monitoring evidence rather than a periodic, point-in-time reassessment. NIST's 2014 supplemental guidance frames it as the transition to near real-time risk management; it is the foundation a Continuous ATO is built on.
Core controls (continuous-monitoring telemetry): "Core controls" is shorthand for the controls that produce the live telemetry an ongoing authorization depends on: vulnerability scanning (RA-5), audit logging (AU family), system monitoring (SI-4), identity and access thresholds (AC-2, IA family), and the continuous-monitoring strategy itself (CA-7). When these feed the AO real-time signals, the AO can sustain a live authorization rather than re-assess from scratch. In FedRAMP 20x this evolves into machine-readable Key Security Indicators (KSIs).
FIPS 199: The standard for categorizing a system's impact (Low / Moderate / High) based on confidentiality, integrity, and availability.
OSCAL: The Open Security Controls Assessment Language — a machine-readable format for SSPs, assessment results, and POA&Ms.
NIST SP 800-53A: The companion guide for assessing controls — the assessment methods and objects an assessor uses to test implementation.
FedRAMP: The Federal Risk and Authorization Management Program — a standardized U.S. government approach to authorizing cloud services.
FedRAMP 20x: FedRAMP 20x is one of two FedRAMP Certification types (the other is Rev5). It targets commercial cloud-native services built on FedRAMP-Certified infrastructure, and centers on Key Security Indicators with persistent automated validation rather than point-in-time narrative documentation.
Consolidated Rules for 2026 (CR26): The 2026 edition of FedRAMP's consolidated, machine-readable rules. CR26 introduces the FedRAMP 20x certification type, Certification Classes A–D, and Key Security Indicators, and modernizes Rev5. It is in Public Preview, finalizes June 30, 2026, and takes mandatory effect January 1, 2027.
FedRAMP Certification Class: FedRAMP replaces the FIPS 199 Low/Moderate/High program labels with four Certification Classes. Class A is a new on-ramp for mature providers entering the federal market (no FIPS 199 equivalent); B, C, and D roughly track Low, Moderate, and High by the kind of system and use. Importantly, the rules state classes are unrelated to the overall security of the offering — each class sets the amount of information shared and the ongoing maintenance/reporting commitments, which determine whether the package is adequate for a given agency system.
Key Security Indicator (KSI): Under FedRAMP 20x, cloud service providers report Key Security Indicators instead of writing a narrative for every control. KSIs require deploying automation to continuously monitor and enforce the desired security state and to report on KSI performance, typically expressed through OSCAL.
Significant Change Notification (SCN): Under the Consolidated Rules, significant changes are notified as machine-readable records (SCN-CSO-INF). The changeType field allows exactly two values — Adaptive or Transformative (per SCN-CSO-EVA) — and routine recurring changes don't require an SCN at all. The record carries the categorization explanation, reason, customer impact, a plan-and-timeline with milestones, the impacted KSIs or Rev5 controls, and the business/security impact analysis — the Security Impact Analysis thinking captured as data. Draft schema; details may change before finalization.
PAIN N-rating (Potential Agency Impact): Providers must estimate the likely potential agency impact of exploiting each vulnerability and assign a rating on an integer scale N0–N5 (rule VER-EVA-EPA). N0, added in October 2026, means exploitation is extremely unlikely to have any adverse effects on agencies, so a vulnerability can be mitigated all the way down to N0. Incidents are still rated N1–N5 (IEC-CSO-EFI). The rating is current, not fixed: each mitigation is recorded as a PAIN reduction event (date + new rating), so a Vulnerability Detail Report shows impact declining over time. Together with the LEV/IRV classifications, the rating drives how quickly remediation is due under the rules' timeframe tables. Draft schema; details may change before finalization.
LEV / IRV classification: Every vulnerability in a CR26 Vulnerability Detail Report is classified two ways: likely exploitable (LEV) or not, and internet-reachable (IRV) or not. The rules' remediation timeframe tables key on these combinations — an internet-reachable, likely-exploitable vulnerability is due fastest. The record also carries the evaluation-completed date that starts the remediation clock, and an overdue flag that requires an explanation when true. Draft schema; details may change before finalization.
Accepted Vulnerability: CR26 makes risk acceptance explicit data: Accepted Vulnerability Info pairs the complete vulnerability detail (rating, classifications, detection) with a required acceptanceRationale explaining why the provider is living with it. That required field is the schema-level answer to stale risk acceptances — an acceptance without a current reason simply doesn't validate. Draft schema; details may change before finalization.
FedRAMP Authorization Act: Enacted December 23, 2022, the FedRAMP Authorization Act codified FedRAMP into federal law and directed OMB to issue implementing guidance (delivered as M-24-15). It defines the roles of GSA, OMB, the FedRAMP Board, and agencies — including the requirement that agencies reuse existing FedRAMP assessments and presume them adequate.
OMB Memorandum M-24-15 (M-24-15): M-24-15 is the OMB memorandum that implements the FedRAMP Authorization Act across government. Issued July 25, 2024, it formally rescinded and replaced the 2011 FedRAMP policy — effectively a new program with the same name — and set the direction the Consolidated Rules for 2026 now detail.
Presumption of adequacy: The presumption of adequacy is what makes FedRAMP reuse work: by law, the assessment of security controls in a FedRAMP authorization package is presumed adequate for an agency's own ATO decision, so agencies reuse it rather than reassess from scratch. The presumption is rebuttable — the agency still owns FISMA compliance and may require additional controls where it documents a demonstrable need.
NIST SP 800-37: The publication defining the Risk Management Framework — the 7-step process from preparation through continuous monitoring.
NIST SP 800-53: The catalog of security and privacy controls (control families like AC, AU, IA, SC, SI) used to protect federal systems.
Risk Management Framework (RMF): NIST's structured process for managing system security risk: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor.
Authorization to Operate (ATO): The authorizing official's formal decision to accept the risk of operating a system. A full ATO means controls are satisfied with no unresolved findings.
Authorizing Official (AO): The senior official who reviews the authorization package and accepts (or denies) responsibility for operating the system at an acceptable level of risk.
Authorization Boundary: Everything included in the system being authorized — the components, services, and data for which the organization is responsible.
Common Control: A control implemented once by a provider and inherited by many systems (for example, physical security provided by the cloud platform).
Continuous Monitoring (ConMon): Ongoing assessment of control effectiveness and risk after authorization, so the AO's decision stays informed over time.
Customer Responsibility Matrix (CRM): The breakdown of which controls the customer implements, which are shared (hybrid), and which are fully inherited from the CSP.
Control Baseline: The starting set of controls selected for a system's impact level (e.g., the FedRAMP Moderate baseline), before tailoring.
FedRAMP baseline vs. NIST SP 800-53B baseline: NIST SP 800-53B defines the three control baselines — Low, Moderate, and High — that each FIPS 199 impact level draws from. FedRAMP does not invent its own catalog: each FedRAMP baseline starts from the matching NIST SP 800-53B baseline and tailors it, adding a set of FedRAMP-specific controls and enhancements and setting FedRAMP-specific parameter values. As a result the FedRAMP High baseline is effectively a superset of the NIST 800-53B High baseline (and likewise at Moderate and Low), and the baselines are monotonic by impact — High contains Moderate, which contains Low. The practical takeaway: when you read "the High baseline," the control selection comes from NIST 800-53B and the program-specific parameters and additions come from FedRAMP.
Hybrid Control: A control where responsibility is shared — the CSP implements part (the platform) and the customer implements the rest (their configuration and policy).
Inheritance: Relying on a control implemented by another party. Inherited controls need no customer narrative — the protection is provided upstream.
Information System Security Officer (ISSO): The person responsible for the day-to-day security of a system, including authoring much of the SSP.
System Owner (SO): The official accountable for the system overall — its mission and business context, its scope and resources, and the decision to operate it under the AO's authorization. The System Owner directs the ISSO's day-to-day security work and accepts operational responsibility once an ATO is granted.
Plan of Action & Milestones (POA&M): The running list of known weaknesses with planned remediations and target dates, reviewed by the AO before authorization.
Provisional ATO (P-ATO): An authorization granted with conditions and accepted residual risk, documented with POA&M milestones and a re-authorization date.
Security Assessment Plan (SAP): The plan describing how each control will be assessed — the methods, objects, and scope of the assessment.
Security Assessment Report (SAR): The Security Assessment Report is the independent assessor's deliverable at the end of RMF Step 4 (Assess): for every control tested it records a determination — satisfied or other-than-satisfied — with the findings, observations, and evidence behind each result. It is the output the rest of the authorization depends on: POA&M items are written from its findings, and the Authorizing Official weighs it to make the risk decision, which is why nothing downstream can start until the SAR exists and is accepted. SP 800-53A defines the assessment procedures the report summarizes; SP 800-37 Step 4 defines the report itself.
Security Control Assessor (SCA): The independent party who evaluates whether controls are implemented correctly and operating effectively. In FedRAMP this is a Recognized independent assessor — the program retired the legacy term '3PAO' to match the FedRAMP Authorization Act.
System Security Plan (SSP): The core authorization document describing the system and how each control is implemented through narrative statements.
Tailoring: Adjusting the control baseline for a specific system — adding, removing, or refining controls based on risk and context.
Third Party Assessment Organization (3PAO): The historical FedRAMP term for an accredited independent assessor that performs the security assessment. Under the 2026 Consolidated Rules, FedRAMP transitioned to 'FedRAMP Recognized independent assessor' — aligning with the FedRAMP Authorization Act and avoiding confusion when the same firms also provide advisory services. You'll still see '3PAO' widely in practice.
Privacy Impact Assessment (PIA): An analysis of how a system collects, uses, shares, and retains personally identifiable information — and what could go wrong for the individuals behind the data. Federal systems handling PII generally require one before operating, and it is revisited when a change alters PII handling (which is exactly what the PTA screen checks). In RMF terms the PIA informs categorization, PT-family control selection, and the privacy posture the authorizing official accepts.
Privacy Threshold Analysis (PTA): The lightweight screening that comes first: does this system or change create, collect, or alter PII handling at all? If yes, deeper privacy work — usually a PIA — is triggered; if no, the analysis documents why not. The classic failure mode is treating the screen as paperwork instead of a decision, which is how privacy-impacting changes ship unreviewed.
Security Impact Analysis (SIA): Before a change ships, CM-4 requires analyzing its security impact: does it touch a control, widen the boundary, or move the risk picture? A significant impact routes the change into re-assessment and an authorizing-official re-decision. The SIA is the security counterpart of the privacy PTA — the same change-board beat runs both: SIA for security impact, PTA for privacy.
System of Records Notice (SORN): When records about individuals are retrieved by a personal identifier, the Privacy Act requires a public notice describing the system of records: what is collected, why, the routine uses, and how individuals can access their records. SP 800-53's PT family ties system behavior back to what the SORN promised — SORN drift after a feature ships is a classic privacy finding.
Senior Agency Official for Privacy (SAOP): The senior official accountable for the agency's privacy program. In the RMF, the SAOP oversees how privacy risk is managed across the lifecycle — categorization of PII, PT-family control selection, and the privacy package the authorizing official relies on. Day-to-day privacy work is usually done by privacy officers working under the SAOP, the way ISSOs work under the system owner.
Interconnection Security Agreement (ISA): When one system connects to another, the connection is a shared risk that neither system's authorization covers on its own. An ISA documents the technical and security terms of that link — what data crosses, how it's protected end to end, and what each side commits to. It is the security-focused member of the information-exchange agreement family (alongside the MOU/MOA). NIST SP 800-47 Rev. 1 frames these as agreements for managing information exchanges, and SP 800-53 control CA-3 ("Information Exchange," formerly "System Interconnections") requires authorizing the exchange before it operates.
Memorandum of Understanding / Agreement (MOU/MOA): Where an ISA pins down the technical security terms of a connection, a Memorandum of Understanding (or Agreement) records the management terms: who is responsible for what, points of contact, expectations, and how the parties handle incidents and changes. For a system interconnection the two travel together — the MOU/MOA sets the relationship, the ISA sets the security controls — and both inform the CA-3 authorization. NIST SP 800-47 Rev. 1 treats them as forms of information-exchange agreement.
CA-3 Information Exchange (CA-3): SP 800-53 control CA-3 — titled "Information Exchange" in Rev. 5 (formerly "System Interconnections" in Rev. 4) — requires that connections used to exchange information between systems be approved and governed by an agreement documenting the interface characteristics, security requirements, and the nature of the information communicated. In practice that agreement is the ISA, with an MOU/MOA, authorized before the exchange goes live. It is the control the change-board interconnection screen is really exercising.
PT family (PII Processing and Transparency): The SP 800-53 Rev. 5 control family for PII processing and transparency: authority to process, privacy notices, consent, and System of Records Notice alignment. These are the controls a privacy officer reasons about the way an ISSO reasons about AC or AU.
Privacy Act of 1974: The statute governing how federal agencies handle records about individuals retrieved by a personal identifier: it requires published SORNs, limits disclosures to defined routine uses, and gives individuals access and amendment rights. The PT control family operationalizes much of it inside the system boundary.
Agency-overlay controls: Controls an agency adds on top of the FedRAMP Moderate baseline when authorizing a cloud system. The FedRAMP baseline covers security controls the CSP implements for all customers — but it deliberately excludes controls whose applicability is system- or agency-specific, such as the Privacy (PT) family. For a PII-bearing system, the agency ISSO selects PT controls driven by the agency SAOP, OMB Circular A-130, and the Privacy Act — the CSP's CIS and CRM will not cover them. Both layers (FedRAMP-inherited + agency overlay) appear in the agency ATO package; only the FedRAMP-inherited controls are covered by the existing FedRAMP Certification.
Cloud Service Provider (CSP): The provider of the underlying cloud platform. In a SaaS authorization, the CSP implements substrate controls the customer inherits.

Quick definitions

800-53A: NIST SP 800-53A — Assessment procedures (Test / Examine / Interview) mapped to SP 800‑53 controls.
AC-2(1): Account Management enhancement (1) — automate/account management lifecycle signals (often join/mover/leave alignment).
AC-3: Access Enforcement — enforced approved authorization for logical access to resources.
accepted vulnerability: A vulnerability the provider retains rather than fixes — the CR26 record (VER-RPT-AVI) requires the full vulnerability detail PLUS an acceptance rationale. No rationale, no valid record.
Accepted Vulnerability Info: A vulnerability the provider retains rather than fixes — the CR26 record (VER-RPT-AVI) requires the full vulnerability detail PLUS an acceptance rationale. No rationale, no valid record.
AO: Authorizing Official — the senior official who accepts (or denies) the risk of operating the system.
API: Application Programming Interface — machine-access surface (REST/Graph/OpenAPI gateways).
ATO: Authorization to Operate — the AO's formal decision to accept the risk of running the system (full ATO = controls satisfied, no unresolved findings).
AU-2: Audit Events — organizational auditable events and evidence you document for assessor review.
Authorizing Official: Authorizing Official — the senior official who accepts (or denies) the risk of operating the system.
CA-3: CA-3 (Information Exchange) — the SP 800-53 control requiring an authorized agreement before a system exchanges information with another system.
CAB: Change Advisory Board — CAB approves/schedules risky changes versus emergency expedite processes.
Certification Class: FedRAMP 20x/CR26 tiers A–D. Practically B≈Low, C≈Moderate, D≈High, with A a new market on-ramp — but officially a class is a threshold for how much information a provider shares plus ongoing reporting commitments, not a security rating.
Certification Classes: FedRAMP 20x/CR26 tiers A–D. Practically B≈Low, C≈Moderate, D≈High, with A a new market on-ramp — but officially a class is a threshold for how much information a provider shares plus ongoing reporting commitments, not a security rating.
CIA: FIPS 199 triad: Confidentiality · Integrity · Availability per information type.
CM-6: Configuration Settings — establish / review / retain settings for configurable system elements.
CM-7: Least Functionality — restrict software/services/functions (often paired with configuration management expectations).
CMDB: Configuration Management Database — authoritative CI records for change/traceability conversations.
CMEK: Customer-Managed Encryption Keys — customer-held keys encrypting workloads/buckets/objects.
ConMon: Continuous Monitoring — ongoing checks after authorization (scans, significant changes, POA&M) that keep the AO's risk decision current.
Consolidated Rules for 2026: FedRAMP's 2026 rules package (Public Preview; final June 30, 2026) that introduces FedRAMP 20x, Certification Classes A–D, and KSIs — retiring the old Low/Moderate/High program labels.
CR26: FedRAMP's 2026 rules package (Public Preview; final June 30, 2026) that introduces FedRAMP 20x, Certification Classes A–D, and KSIs — retiring the old Low/Moderate/High program labels.
CRM: Customer Relationship Management — pipelines, accounts, opportunities, cases—tenant data you configure.
CSP: Cloud Service Provider — vendor-operated hyperscale/PaaS layer (FedRAMP system boundary).
CUI: Controlled Unclassified Information — markings for sensitive unclassified categories per agency CUI programs.
DDoS: Distributed Denial of Service — volumetric/protocol attacks mitigated at edge/POP with provider controls.
DLP: Data Loss Prevention — policy/labels/inspect to prevent unintended data exfiltration.
eDiscovery: Electronically Stored Information discovery/legal hold processes for searchable export.
FedRAMP: Federal Risk & Authorization Management Program — standardized Fed cloud authorization path.
FedRAMP 20x: FedRAMP's new cloud-native certification type (Consolidated Rules 2026): providers share Key Security Indicators backed by automation that continuously monitors and enforces security, instead of narrative SSPs. Not for self-run infrastructure; Class D (High) arrives early 2027.
FedRAMP Authorization Act: The 2022 law (Sec. 5921 of Pub. L. 117-263, the FY2023 NDAA; 44 U.S.C. ch. 36) that put FedRAMP in statute — establishing the program, the FedRAMP Board, independent assessment, and the agency presumption of adequacy. OMB M-24-15 implements it.
FedRAMP Certified: The CR26 term replacing 'FedRAMP authorized'. FedRAMP certifies that a product completed a standardized assessment; FedRAMP does NOT grant an ATO or accept risk — the agency makes the Authorization to Operate decision under the RMF using FedRAMP's materials.
FedRAMP Rev5: The modernized traditional FedRAMP certification type (vs. 20x): best for non-cloud-native services and Class D (High). New Rev5 certifications end June 11, 2027; ongoing support continues for existing providers.
FedRAMP-authorized: Service on the FedRAMP marketplace with agency-sponsored reuse (SSP inheritance rules apply).
FIPS: Federal Information Processing Standards (e.g. FIPS 199 impact; FIPS 140 crypto modules).
FIPS Publication 199: FIPS 199 — categorize potential impact (Low/Moderate/High) for Confidentiality, Integrity, and Availability per information type before aggregation to the system.
GRC: Governance, Risk & Compliance — central policy/controls/attest/evidence tooling.
HRIS: Human Resources Information System — authoritative hire/term/transfer records for joiner‑mover‑leaver.
IA-2(1): Identification & Authentication enhancement (1) — multi-factor authentication for privileged and non-privileged users per SSP scope.
IaaS: Infrastructure as a Service — compute/storage/network primitives (VMs, VPCs, object stores) you compose.
IdP: Identity Provider — federation/MFA/sign-in flows (often SAML OIDC SSO into SaaS).
Interconnection Security Agreement: Interconnection Security Agreement — a documented agreement defining the security terms of a connection between two systems: the data exchanged, how it's protected, and each party's responsibilities.
ISA: Interconnection Security Agreement — a documented agreement defining the security terms of a connection between two systems: the data exchanged, how it's protected, and each party's responsibilities.
ISSO: Information System Security Officer — owns a system's day-to-day security and authors much of the SSP.
ITSM: IT Service Management — tickets/CMDB/workflows (ServiceNow‑class ITSM).
Key Security Indicator: A FedRAMP 20x metric a provider shares that summarizes a security capability, backed by automation that persistently monitors and enforces the desired state and reports performance — replacing point-in-time narrative control descriptions with continuous machine-validated evidence.
Key Security Indicators: A FedRAMP 20x metric a provider shares that summarizes a security capability, backed by automation that persistently monitors and enforces the desired state and reports performance — replacing point-in-time narrative control descriptions with continuous machine-validated evidence.
KSI: A FedRAMP 20x metric a provider shares that summarizes a security capability, backed by automation that persistently monitors and enforces the desired state and reports performance — replacing point-in-time narrative control descriptions with continuous machine-validated evidence.
KSIs: A FedRAMP 20x metric a provider shares that summarizes a security capability, backed by automation that persistently monitors and enforces the desired state and reports performance — replacing point-in-time narrative control descriptions with continuous machine-validated evidence.
LEV/IRV: CR26 vulnerability classifications: LEV — is it likely exploitable (per VER-EVA-ELX)? IRV — is it internet-reachable (per VER-EVA-EIR)? With the PAIN N-rating, these determine how fast a fix is due.
M-24-15: OMB Memorandum M-24-15 (July 25, 2024), 'Modernizing FedRAMP' — the government-wide guidance required by the FedRAMP Authorization Act that rescinded and replaced the original 2011 FedRAMP policy.
MFA: Multi-factor authentication — two or more factors (know/have/are).
MOA: MOU/MOA — a management-level agreement recording the roles, responsibilities, and expectations between two parties that operate a shared interconnection.
MOU: MOU/MOA — a management-level agreement recording the roles, responsibilities, and expectations between two parties that operate a shared interconnection.
MOU/MOA: MOU/MOA — a management-level agreement recording the roles, responsibilities, and expectations between two parties that operate a shared interconnection.
mTLS: Mutual TLS — both client and server present certificates during TLS handshake.
N-rating: The CR26 vulnerability impact scale: an N0–N5 'Potential Agency Impact N-Rating' estimating the likely impact on agency customers if a vulnerability is exploited. N0 means exploitation is extremely unlikely to have any adverse effect. Recorded PAIN reduction events show the rating dropping as mitigations land.
NIST: National Institute of Standards and Technology — publishes SP 800‑53 catalogs and RM guidance.
NOC: Network Operations Center — staffed monitoring/handling of platform outages/incidents.
NTP: Network Time Protocol — clock sync underpinning authoritative audit timestamps correlation.
OAuth: OAuth 2.x — delegated authorization: client obtains scoped bearer tokens with user/consent framing.
OIDC: OpenID Connect — identity layer atop OAuth (ID Tokens, discovery; bearer access tokens where applicable).
OSCAL: Open Security Controls Assessment Language — structured exchange of SSP/SAP/SAR/POA&M artifacts aligned with NIST models.
P-ATO: Provisional ATO — an authorization granted with conditions and accepted residual risk, tracked by POA&M and a re-authorization date.
PaaS: Platform as a Service — managed runtime/container/data-plane the vendor stewards underneath apps.
PAIN N-rating: The CR26 vulnerability impact scale: an N0–N5 'Potential Agency Impact N-Rating' estimating the likely impact on agency customers if a vulnerability is exploited. N0 means exploitation is extremely unlikely to have any adverse effect. Recorded PAIN reduction events show the rating dropping as mitigations land.
PAIN rating: The CR26 vulnerability impact scale: an N0–N5 'Potential Agency Impact N-Rating' estimating the likely impact on agency customers if a vulnerability is exploited. N0 means exploitation is extremely unlikely to have any adverse effect. Recorded PAIN reduction events show the rating dropping as mitigations land.
PIA: Privacy Impact Assessment — analysis of how a system collects, uses, shares, and retains PII, and how the risks to individuals are mitigated.
PII: Personally Identifiable Information — data that identifies individuals (tiered handling).
POA&M: Plan of Action & Milestones — the running list of known weaknesses with fixes, owners, and target dates the AO reviews.
presumed adequate: FedRAMP Authorization Act §3613(e): an agency shall presume a FedRAMP package's assessment and materials are adequate for its own Authorization to Operate — the legal basis for 'do once, use many.' It does NOT remove the agency's FISMA responsibility or its right to add controls for a demonstrable need.
presumption of adequacy: FedRAMP Authorization Act §3613(e): an agency shall presume a FedRAMP package's assessment and materials are adequate for its own Authorization to Operate — the legal basis for 'do once, use many.' It does NOT remove the agency's FISMA responsibility or its right to add controls for a demonstrable need.
PTA: Privacy Threshold Analysis — short screening that determines whether a system or change involves PII and whether a full PIA is required.
RBAC: Role-Based Access Control — bundles of permissions modeled as business or technical roles.
SaaS: Software as a Service — vendor-operated multi-tenant application your org consumes as a tenant.
SAML: Security Assertion Markup Language — federation protocol for SSO assertions via an IdP.
SAML/OIDC: Enterprise SSO using SAML assertions or OIDC ID tokens issued by your Identity Provider (IdP).
SAOP: Senior Agency Official for Privacy — the senior official accountable for the agency-wide privacy program, including privacy posture in authorization decisions.
SAP: Security Assessment Plan — how each control will be assessed: the methods, objects, and scope.
SAR: Security Assessment Report — the assessor's findings after testing: what passed, what failed, and the evidence.
SC-7(3): Boundary enhancement (3) — manage externally exposed access points/network connections (deny by default posture).
SCA: Security Control Assessor — the independent party (a FedRAMP Recognized independent assessor) who tests whether controls work.
SCIM: System for Cross‑domain Identity Management — automated user/group provisioning APIs.
SIA: Security Impact Analysis — the change-time check (NIST SP 800-53 CM-4) of how a proposed change affects security posture and which controls must be re-assessed.
SIEM: Security Information and Event Management — central log/analysis for detection and assessor queries.
Significant Change Notification: The CR26 record a provider files for a significant change: typed as Adaptive or Transformative, with the reason, customer impact, plan/timeline, and the impacted KSIs or Rev5 controls to re-verify. Routine recurring changes are excluded — no SCN required.
Significant Change Notifications: The CR26 record a provider files for a significant change: typed as Adaptive or Transformative, with the reason, customer impact, plan/timeline, and the impacted KSIs or Rev5 controls to re-verify. Routine recurring changes are excluded — no SCN required.
SOC: Security Operations Center — staffed detection/response consuming enterprise telemetry.
SORN: System of Records Notice — Privacy Act notice published in the Federal Register describing a system of records, its purpose, and routine uses.
SP 800-60: NIST SP 800-60 Rev. 2 (esp. Vol. 2–3) — workbook guidance for selecting/mapping organizational information types prior to FIPS 199 decisions.
SRE: Site Reliability Engineering — SRE/DevOps reliability/SLO/on-call stewards for services.
SSO: Single sign-on — one IdP session unlocks SSO into trusting apps via federation protocols.
SSP: System Security Plan — system-level security implementation description assessors authorize against.
System Owner: System Owner — the official accountable for a system's mission, scope, resourcing, and operation across the RMF.
TGW: AWS Transit Gateway — hub interconnect for VPC/on-prem attachment (routing for private connectivity architectures).
UAR: User Access Review — periodic certification that accounts/roles remain appropriate (assessor-friendly artifact chain).
WAF: Web Application Firewall — Layer 7 policy at edge/proxy inspecting HTTP/API traffic.
WORM: Write Once Read Many — immutable/object-lock style retention resisting overwrite/deletion.
ZTA: Zero Trust Architecture — never trust implicitly; continual verification per request/context.
ZTNA: Zero Trust Network Access — identity/policy brokered remote access replacing flat VPN perimeter assumptions.

RMF Coach is an educational simulation and training product — not an authorization, and not affiliated with or endorsed by NIST or FedRAMP.