FedRAMP, FISMA, and privacy: who decides what when your agency authorizes a system

When an agency puts a cloud service into one of its systems, three sets of rules apply at once. The Federal Risk and Authorization Management Program (FedRAMP) certifies the cloud service. The Federal Information Security Modernization Act of 2014 (FISMA) makes the agency responsible for the security of the whole system. Privacy law, mainly the Privacy Act of 1974 and the E-Government Act of 2002, protects the people whose information the system holds. Each answers a different question, and each has a different official who decides.

Most authorization problems come from treating one of these as if it covered the others. This post sets out what each one covers, how they fit into a single authorization to operate (ATO), and the pitfalls that cause trouble later.

Three regimes, three questions

The Office of Management and Budget (OMB) sets the policy for all three. The National Institute of Standards and Technology (NIST) Risk Management Framework, in SP 800-37, is where they meet.

A FedRAMP certification is not your ATO

FedRAMP's 2026 rules are direct: agencies must complete the ATO process for any federal information system that uses a FedRAMP certified cloud service (rule AGU-USE-ABU). M-24-15 says agencies "leverage the FedRAMP authorization package to issue their own" ATO, and that agency authorizing officials "determine acceptable risk for their agency."

The FedRAMP Authorization Act does give agencies a head start. They must presume the provider's security assessment is adequate for use at or below its level. But that presumption covers the provider's package, not your system. Your AO still decides whether the whole system, including your settings, your users, your data, and your connections, is acceptable.

Where privacy fits

FedRAMP does not certify privacy. When FedRAMP released its Rev5 baselines, it said it "did not include any of the privacy controls" beyond a few in the standard NIST baseline, and none of the Personally Identifiable Information Processing and Transparency (PT) control family. It asked agencies to apply those requirements based on their own data. M-24-15 says the same thing in a footnote: "agencies are responsible for implementing privacy requirements for cloud products and services."

NIST puts the reason plainly: "protecting individuals' privacy cannot be achieved solely by securing PII." A well-secured cloud service can still collect more personal information than the agency needs, use it for a purpose the agency never announced, or share it in a way no notice covers. Those are privacy failures, and no security assessment will find them.

OMB Circular A-130 gives the SAOP a defined place in authorization. Under Appendix I, the SAOP must:

• Review and approve the security categorization of systems that handle personally identifiable information (PII).
• Review and approve the privacy plan for each such system before it is authorized.
• Review the authorization package before the AO makes the risk decision.

How the three fit into one authorization

Ten pitfalls

Three of these deserve more detail.

The system of records. The Privacy Act defines a system of records as a group of records under an agency's control from which information is retrieved by a person's name or another identifier. Many cloud services are built around exactly that kind of lookup: a case management tool, a help desk, a learning platform. When an agency contracts for a system of records "to accomplish an agency function," the Act says the agency must "cause the requirements of this section to be applied to such system." Moving to the cloud does not move the Privacy Act duty to the provider. The agency keeps it.

Asking for more. FedRAMP's rules limit what an agency can demand beyond the FedRAMP package (rule AGU-AGC-NAR). M-24-15 allows more only for a "demonstrable need," and the agency must document it and tell FedRAMP. Privacy requirements are a common reason to need more, because FedRAMP's baselines leave privacy to agencies. Settle these needs before award, record the reason, and put them in the contract. Do not discover them during the assessment.

Breach response. OMB M-17-12 says contracts should require the contractor to report a suspected or confirmed breach, cooperate with agency officials, train its staff to spot and report breaches, and allow inspection and forensic analysis. A FedRAMP provider reports incidents under FedRAMP's rules, but your agency's breach response plan, and any notice to affected people, remain your agency's work.

Risks, and who should catch them

What to do

• Bring the SAOP in at categorization, not at signature. A-130 gives the SAOP approval of both the categorization and the privacy plan.
• Start the PIA during market research, and use it to shape the requirements and the contract.
• Check for a system of records before award. If a SORN is new or must change, OMB Circular A-108 sets review and publication steps that take time.
• Write privacy into the contract: the Privacy Act clauses, breach terms from M-17-12, data location and retention, and limits on use of your data.
• Map responsibilities. For each control, record what the provider's package covers, what your agency covers, and which privacy controls you added.
• Configure from the Secure Configuration Guide, and assess those settings as part of your system.
• Keep watching. Read every Ongoing Certification Report, and feed changes that affect personal information into privacy continuous monitoring.

This post explains federal requirements in general terms. It is not legal advice; your agency counsel and SAOP decide how these rules apply to a specific system.

FedXchange tracks these sources in its governance tracker, and writes agency policies and procedures, including privacy and assessment procedures, that name the services an agency uses.

Sources

• Federal Information Security Modernization Act of 2014, 44 U.S.C. 3554, agency responsibilities, including for systems "used or operated by an agency or by a contractor of an agency."
• Privacy Act of 1974, 5 U.S.C. 552a, including subsections (e)(4) on notices and (m)(1) on government contractors.
• U.S. Department of Justice, E-Government Act of 2002, section 208 on privacy impact assessments.
• OMB, M-03-22, Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002, section II.B on when to conduct a PIA.
• OMB, Circular A-130, Managing Information as a Strategic Resource (2016), Appendix I on the SAOP's role in categorization, privacy plans, and authorization packages.
• OMB, Circular A-108, Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act (2016).
• OMB, M-17-12, Preparing for and Responding to a Breach of Personally Identifiable Information, section V.B on contract terms.
• OMB, M-24-15, Modernizing the Federal Risk and Authorization Management Program, section IV.a and footnote 7.
• NIST, SP 800-37 Rev. 2, Risk Management Framework, on how security and privacy relate.
• FedRAMP, Rev. 5 Transition Overview, on privacy controls in the Rev5 baselines.
• FedRAMP, Agency rules in the Consolidated Rules for 2026: AGU-USE-ABU, AGU-USE-RSG, AGU-AGC-NAA, AGU-AGC-NAR, AGU-USE-CLA, and AGU-USE-RIR; and Collaborative Continuous Monitoring rules for agencies: CCM-AGM-ROR.

Icons by Font Awesome Free, licensed CC BY 4.0.