🔒 Closed beta: four products · 📉 Corrections record: AI mistakes, counted by class and fed back into the next run · 📢 New post: FedRAMP Release 2026.10.13.01 Added 279 Control Mappings and Has No Changelog Entry · 📝 Also fresh: Atlassian CVE-2026-21589 Added to KEV; CVE Record Rejected the Next Day · 🚦 Beacon — the FedRAMP 20x KSI emitter — see what it emits ✨ · 🆕 20x Hub: program reference, kept current · 🧪 KSI Quick Check: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPComplianceGRC

FedRAMP Scoping for Trust Centers

On September 3 a provider posted a question to FedRAMP's community discussions that a lot of people have quietly been carrying: is a Trust Center part of the CSO?

The reasoning behind it was sound, and it is the reasoning most of us would have reached for. A Trust Center holds compliance documents. It does not process the agency's data. So, as the asker put it, "Since a Trust Center does not process Federal Customer Data, I assume/suspect that it should not be considered part of the CSO (i.e., not inside the boundary). If so, this would exempt the Trust Center from adhering to SCN requirements. Are both of these correct assumptions?"

Under two hours later a FedRAMP maintainer answered, and the thread now stands closed as resolved. The answer is worth reading closely, and so is the part of the question it leaves open.

The rule the answer rests on

The reply goes straight to the Minimum Assessment Scope and quotes the rule that decides it:

MAS-CSO-IIR (Identify Information Resources): Providers MUST identify a set of information resources to assess for FedRAMP Certification that includes all information resources that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering; this set of information resources is the cloud service offering.

That or is the whole thing. The maintainer's read: "Your statement addresses the first part of this requirement (it does not process federal customer data), but you also need to consider the second part: is it likely to impact the CIA of federal customer data in the cloud service offering?"

And then the example that makes it concrete, which I will quote because it is better than any paraphrase I'd write: "Maybe you have a bad habit of being like 'our recovery codes are stored in a treasure chest buried at these GPS coordinates' or something in your SDR. In that case, the Trust Center is an information resource that is processing information that is likely to impact CIA of the federal customer data in the cloud service offering because if someone pops it they get a nice 'X marks the spot' map!"

The conclusion is deliberately unresolved: "I guarantee there are some cloud services where the Trust Center is in scope, and there are some where it's not."

That is not a dodge. It falls out of how the rule's load-bearing words are defined, and it is worth looking at where those definitions actually land, because each of them is wider than instinct suggests.

"Information resource" (FRD-IRS) takes its meaning from 44 USC § 3502(6) and then goes further than most readers expect: it covers "any aspect of the cloud service offering, both technical and managerial, including everything that makes up the business of the offering from non-machine-based information resources like organizational policies, procedures, employees, etc. to machine-based information resources like hardware, software, cloud services, code, etc." A documentation portal clears that bar without argument. Is it an information resource was never the live question.

"Handle" (FRD-HAN) is explicitly plain-language and explicitly maximal — "inclusive of any possible action taken with information, such as access, collect, control, create, display, disclose, disseminate, dispose, maintain, manipulate, process, receive, review, store, transmit, use... etc." Note display and disclose in that list. A Trust Center's entire function is disclosure. What saves the first half of the test for most providers is not that a Trust Center doesn't handle, it's that what it handles is not federal customer data.

"Likely" (FRD-LKY) is one sentence: "A reasonable degree of probability based on context." FedRAMP defined the word and then declined to put a number on it, which tells you who is expected to make the call. The determination is yours, and it is yours in writing.

There is also a wrinkle in the first half of the test worth knowing before you lean on it. Federal customer data (FRD-FCD) explicitly excludes "account information, service metadata, analytics, telemetry, or other similar metadata generated by the cloud service provider" — so a portal full of metadata is genuinely not handling federal customer data. But MAS-CSO-MDI says providers "MUST include metadata (including metadata about federal customer data) in the Minimum Assessment Scope ONLY IF MAS-CSO-IIR (Identify Information Resources) APPLIES." Metadata is outside the definition of the protected data and inside the scope of the assessment. Those are different questions and it is easy to answer one while thinking you answered the other.

"Out of scope" is a different pile of paperwork, not a smaller one

Here is the part the thread didn't need to cover and most readers will want.

Suppose you do the analysis honestly, your Trust Center content is well-designed, and you determine it is not likely to impact the CIA of federal customer data. You have scoped it out. What happens next?

It becomes a third-party information resource. That term is defined (FRD-TPR) as "Any information resource that is not entirely included in the Minimum Assessment Scope for the cloud service offering obtaining FedRAMP Certification." It is a residual category — everything you didn't scope in lands there by construction, and for most providers the Trust Center is a hosted product from a vendor, which makes the fit exact.

And third-party information resources have their own rule. MAS-CSO-TPR requires providers to address the potential impact to federal customer data from each applicable one by documenting:

  • General usage and configuration
  • Explanation or justification for use
  • Mitigation measures in place to reduce the potential impact to federal customer data
  • Compensating controls in place to reduce the potential impact to federal customer data

So the choice in front of you is not assess it versus forget it. It is assess it versus write up why you didn't, with your mitigations and compensating controls named. The second is lighter, but it is not nothing, and the thing it produces is a document an assessor will read against your Trust Center's actual configuration.

FedRAMP regulates your Trust Center either way

The scoping question is the one that got asked, so it is the one that got answered. But it is not the question that settles how much work your Trust Center is going to be, because "trust center" is a defined FedRAMP term with its own ruleset, and that ruleset binds whether or not MAS-CSO-IIR pulls the thing into the Minimum Assessment Scope.

FRD-TRC: "A secure repository or service used by cloud service providers to store and share FedRAMP Certification Data. Trust centers are the complete and definitive source for FedRAMP Certification Data and must follow the FedRAMP Certification Data Sharing rules to be FedRAMP-compatible." The definition carries a note that in FedRAMP documentation, every reference to a trust center means a FedRAMP-compatible trust center unless stated otherwise.

The Certification Data Sharing ruleset starts by assuming you have one. CDS-CSO-PUB lists what providers must publicly share in both human-readable and JSON form, and one of the required items is a "Link to Trust Center landing page that includes instructions on accessing information in the trust center." The alternative path named elsewhere in the ruleset is USDA Connect; a Trust Center is not an optional extra you might bolt on.

From there it sets requirements on the Trust Center itself. The FedRAMP-Compatible Trust Centers subset carries, among others:

  • CDS-TRC-USH — trust centers MUST share Certification Data with all necessary parties "without interruption," which the note defines as parties not having to "request manual approval each time they need to access FedRAMP Certification Data or go through a complicated process." On-demand just-in-time provisioning is named as the preferred approach.
  • CDS-TRC-PAC — trust centers MUST provide documented programmatic access to all Certification Data, "including programmatic access to human-readable materials."
  • CDS-TRC-AAI — trust centers MUST maintain an inventory and history of federal agency users or systems with access, available to FedRAMP on request.
  • CDS-TRC-ACL — trust centers MUST log access to Certification Data and store summaries of access for at least six months.

Read the applicability line above those rules and the reason they matter to you sharpens considerably. The grammatical subject is "Trust centers," but the subset's Audience is Providers. A trust center product that gates every download behind a sales-led approval, or that has no documented API, or that keeps thirty days of access logs, does not produce a finding against your vendor. It produces one against you.

It also attaches a clock. CDS-UTC-AAD is a notification requirement: providers MUST notify FedRAMP within 5 business days of denying an agency access request for Certification Data. That is a reportable event living on the system the original question hoped was outside the boundary.

What about the SCN half of the question?

The asker's second assumption — that being outside the CSO would exempt the Trust Center from Significant Change Notification — follows from the first, so the thread's "it depends" lands on it too. Two details are worth having in hand before you treat it as settled.

A significant change (FRD-SGC) takes its meaning from NIST SP 800-37 Rev. 2: "a change that is likely to substantively affect the security or privacy posture of a system." Same likely, same defined-but-unquantified word, same person making the call.

More to the point, SCN-CSO-EVA requires providers to "evaluate all potential significant changes to determine the type of significant change and follow the appropriate Significant Change Notification rules," and SCN-CSO-MAR requires "auditable records of the significant change evaluation activities required by SCN-CSO-EVA." The obligation to evaluate does not wait on the conclusion. Deciding a change to your Trust Center was not significant is itself an evaluation that has to exist as a record — one that does not need to go in the Certification Package by default, but must be available to FedRAMP on request.

Two dates, and one class where the question doesn't arise

For 20x, both rulesets run on the same calendar: optional adoption and initial certification from 2026-07-04, maintaining ongoing certification from 2027-01-01, with the grace period ending on the first FedRAMP independent assessment started after 2027-01-01.

For Rev5 they diverge, and the gap runs the direction you'd want. Minimum Assessment Scope hits Rev5 providers for ongoing certification on 2027-01-01, with the grace period ending on the first independent assessment started after that date. Certification Data Sharing lands later — ongoing certification on 2027-08-01, grace period ending 2028-02-01. A Rev5 provider is answerable for the boundary determination roughly seven months before the Trust Center sharing requirements bind, which is a sensible order to do the work in anyway.

One more piece of shape: this question is class-dependent. The Class A ruleset reference lists exactly three rulesets — Certification Package Overview, FedRAMP Certification, and Marketplace Listing. Minimum Assessment Scope is not among them. The boundary question in this form belongs to Class B and above, which lines up with what we found reading Class B and Class C side by side: the real step change is A to B, not B to C.

Worth noting on currency, too. MAS-CSO-IIR's only changelog entry since the June 24 launch of the Consolidated Rules is dated 2026-10-13, and it added control mappings — CM-08(04), RA-03, SI-04(19). The rule text the maintainer quoted in September has not moved. The answer is still the answer.

Where this touches what we build

The recurring lesson in this series is that the hard part of a compliance question is rarely the determination. It is holding the evidence that the determination was made, and made the way you say.

Look at what the Trust Center rules actually ask for and almost all of it is operational record. An inventory and history of which agency systems have access. Access summaries retained for at least six months. Auditable records of every change evaluation, including the ones that concluded not significant. None of that can be assembled the week an assessor asks, because the requirement is specifically for the past.

Citadel is the piece of our work that lives closest to this. It runs query packs against a fleet continuously and keeps what they return, which means the posture history exists as a byproduct of having run the thing rather than as an artifact produced on request. The same property is what makes a six-month access-log requirement survivable: you either have six months, or you have a plan to have it in six months.

The question worth carrying

The original question was about a boundary. The honest version is narrower and more useful.

If an assessor asked you today why your Trust Center is outside your Minimum Assessment Scope, you would have a reasonable answer. Would you have the writeup — the usage and configuration, the justification, the mitigations, the compensating controls — or would you be writing it that afternoon?

That is a different question from where the line is drawn, and it is the one the rules are built to ask.

Reference