Certification Data Sharing & Trust Center¶

This document establishes the organization's policy for sharing FedRAMP certification data with FedRAMP, agency customers, and the public, and the procedures by which GRC-ITSM operates the trust center that serves it.

It covers the trust center and its five surfaces, the access model and the User Access Request workflow that grants and removes access, the access inventory and access logging, programmatic access over the REST API, the point-in-time certification package artifacts and the historical snapshots, and the public information the organization publishes. It implements the FedRAMP Certification Data Sharing (CDS) rule family from the FedRAMP Consolidated Rules for 2026: the general provider responsibilities (CDS-CSO), the FedRAMP-compatible trust center rules (CDS-TRC), the rules for providers using a trust center rather than USDA Connect (CDS-UTC), and the Rev5-specific migration rule (CDS-CSF).

This document owns the sharing surfaces. It does not own the content of the reports and artifacts those surfaces serve; each operational process documents its own content. See "Related documents" below.

Download the KB article (Markdown)

Framework applicability¶

The CDS rules apply at Classes B, C, and D on both the 20x and Rev5 types and on both the Program and Agency certification paths. Two rules vary by class: availability reporting is a MUST at Classes B, C, and D and a SHOULD at Class A (CDS-CSO-AVR), and per-service certification materials are a MUST at Class D and a MAY at Classes A, B, and C (CDS-CSO-PSM). The Organization-Defined Values table carries the Class C values.

Policy¶

• P-1. All FedRAMP certification data is shared through a FedRAMP-compatible trust center (CDS-CSO-UTC, MUST). The Stratus Cyber-branded GRC-ITSM self-service portal is that trust center. It is the sharing surface for FedRAMP and for every agency customer using the offering.
• P-2. Each surface has one job, and live data is never presented as a snapshot. The trust center carries five surfaces: Request Services, My Requests & Tickets, Policies & Procedures, ConMon Reports, and Certification Documents. ConMon Reports are live views of current system state. Certification Documents are point-in-time artifacts. The distinction is stated on the surfaces themselves, so a reader always knows whether the number in front of them is current or fixed.
• P-3. Policies and procedures are published, not summarized (CDS-CSO-IRP, MUST). The Policies & Procedures surface publishes the living library of policies, procedures, and operational standards that the system's controls and requirements are measured against. It is the serving surface for the relevant-policies obligation. The rule also requires a human- and machine-readable reference for each published document (name, file, brief summary, word count, current version, date of last update, related FedRAMP Practices) with an explanation of how to access it; the organization commits to publishing that index on the Policies & Procedures surface.
• P-4. Every access decision is a User Access Request. Agency and customer access is granted and removed through the User Access Request workflow: an auditable ticket with an approval, the same path as all other access to the system. Self-registration creates an account, not access.
• P-5. Views are scoped to the requesting party's own system. Accounts are role-based, and each party sees its own system's records and nothing else. Site-scoped report variants carry the scoping.
• P-6. Shared data withholds specifics, not risk (CDS-CSO-RIS, MUST). Sensitive fields are excluded from shared reports. Exclusion applies to detail that would likely enable a threat actor; it never applies to the accurate risk information an agency needs to make an authorization decision.
• P-7. Once access is granted it is not re-approved per use (CDS-TRC-USH, MUST). Authorized parties reach certification data on demand, through the portal or the API, without a manual approval for each retrieval.
• P-8. Access to certification data is inventoried and logged (CDS-TRC-AAI and CDS-TRC-ACL, both MUST). The inventory and history of agency users and systems with access is available to FedRAMP on request. Access is logged and summaries are retained for at least six months. A party's own access summary is supplied on that party's request (CDS-TRC-ACL, SHOULD).
• P-9. A denied agency access request is reported to FedRAMP within 5 business days (CDS-UTC-AAD, MUST). The notification is made manually on the FedRAMP form and is tracked in the User Access Request ticket that carried the denial.
• P-10. Agency access to the FedRAMP Certification Package is supplied on request (CDS-UTC-AGA, SHOULD). Requests arrive through Request Services and are handled as tracked tickets.
• P-11. Programmatic access is documented, not merely available (CDS-TRC-PAC, MUST). Certification data is retrievable over the GRC-ITSM REST API, including programmatic access to human-readable materials. The customer-facing Trust Center Access Guide is that documentation; the organization publishes it to its public documentation website and links it from the trust center landing page (see the Programmatic access section for current status).
• P-12. Both formats render from the same records (CDS-CSO-CBF, MUST). Human-readable and machine-readable certification data are generated by the same automation from the same live platform records, so consistency between formats is a property of the architecture rather than a reconciliation step. Certification data is available to view and to download in both forms (CDS-TRC-HMR, SHOULD).
• P-13. Every piece of certification data carries the FedRAMP ID (CDS-CSO-FID, MUST). The system's FedRAMP identifier appears in all reports, notifications, and other communication produced under FedRAMP rules. A placeholder is carried until FedRAMP assigns the identifier.
• P-14. Historical certification data is retained for the duration of the certification (CDS-CSO-HAD, MUST). Snapshots of certification data aligned to each Ongoing Certification Report are saved in Certification Documents and stay available for as long as the certification is held.
• P-15. FedRAMP Certification Reports are posted within 2 weeks of receipt (CDS-CSO-FRC, MUST), without inappropriate modification, as an upload to Certification Documents.
• P-16. Public information and the service list are published publicly (CDS-CSO-PUB and CDS-CSO-SVC, both MUST), in human-readable and JSON form, without a login. See the Public information section for the current surface and the commitment.
• P-17. Availability reporting is the client's obligation (CDS-CSO-AVR, MUST at Class C). The availability web service for the cloud service offering, covering current and at least 30 days of historical availability including availability incidents, in human-readable and machine-readable form and reachable when the offering itself is not, is maintained by the client as the operator of the offering. It is not a GRC-ITSM platform capability.
• P-18. Self-service access management is the direction of travel (CDS-TRC-SSM, SHOULD). Self-registration and the requester-visible My Requests & Tickets surface are the features in place today; delegated provisioning by agency administrators is a commitment, not a claim.
• P-19. Migration to the trust center is announced, and the old location points to the new one (CDS-CSF-TCM, MUST on Rev5). When a Rev5 system migrates, all necessary parties are notified and the existing USDA Connect Community Portal secure folders carry instructions for using the trust center.
• P-20. Discretionary sharing is a decision, and the decision is recorded. Public or third-party sharing of certification package content happens only where the organization determines it is not likely to have an adverse effect on the offering (CDS-CSO-RPS, MAY). Per-service certification materials are supplied where they help agencies adopting only part of the offering (CDS-CSO-PSM, MAY at Class C).
• P-21. Account lifecycle is request-driven, and stale accounts are caught by review. No automated inactivity handling exists for portal users. Accounts are created, changed, and removed through User Access Requests, and the recurring annual account recertification and the account compliance reviews are what catch an account nobody remembered to remove.
• P-22. The procedure reviews itself persistently. The ISSO reviews this document for effectiveness on the cadence in the ODV table, together with the access inventory and the access logs.

Organization-defined values¶

Roles and responsibilities¶

• Requesters (agency and customer users). Submit access requests, questions, and feedback through Request Services, and track their own submissions under My Requests & Tickets.
• User Access Request approvers. The Approver - User Access Requests role grants membership to the User Access Request Approvers CAB, which approves and denies access to certification data.
• Access request owners. Each User Access Request is assigned a tracking owner automatically through the Agent Assignment - User Access Requests role. The owner carries the ticket to a decision and records the denial notification when a request is denied.
• Trust center administrators. Provision and deprovision portal accounts and API credentials against approved requests, maintain the report scoping and the excluded-field configuration, and upload certification package artifacts and historical snapshots.
• ISSO and System Owner. Accountability and escalation. The ISSO owns the denial notification to FedRAMP, the responsible-sharing determinations under CDS-CSO-RPS, and the review of this document; the System Owner gives final approval and authorizes exceptions.
• Client (operator of the cloud service offering). Maintains the availability web service required by CDS-CSO-AVR.

The trust center¶

The Stratus Cyber-branded GRC-ITSM self-service portal is the trust center. Five surfaces carry certification data and party interaction.

flowchart TD
    P["Trust center<br/>self-service portal"] --> A["Request Services<br/>asynchronous channel"]
    P --> B["My Requests &amp; Tickets<br/>requester's own tickets"]
    P --> C["Policies &amp; Procedures<br/>published P&amp;P library"]
    P --> D["ConMon Reports<br/>live views of current state"]
    P --> E["Certification Documents<br/>point-in-time artifacts"]

Live views versus point-in-time artifacts¶

The split between ConMon Reports and Certification Documents is the load-bearing distinction on the trust center, and the surfaces say so in their own language: ConMon Reports are live views of the current system state, distinct from the point-in-time Certification Documents.

The ten ConMon reports: Public Information, System Information, System POCs, Inventory (IIW), Open POA&M, Closed POA&M, Vulnerability Details, Accepted Vulnerabilities, Reportable Incidents, and Significant Changes. Each report's content is owned by the process that produces it, not by this document.

Certification Documents¶

Certification Documents carries the FedRAMP-schema JSON artifacts and the uploaded package documents, organized by system with folder selection.

Access model¶

Access to certification data is role-based, scoped to the requesting party's own system, and granted only through the User Access Request workflow.

flowchart TD
    A["Party needs access"] --> B{"Has a portal account?"}
    B -->|No| C["Self-register on the login page"]
    C --> D{"Email domain matches a client?"}
    D -->|Yes| E["Account associated with that client"]
    D -->|No| F["Account held on the Unknown site"]
    B -->|Yes| G["User Access Request submitted"]
    E --> G
    F --> G
    G --> H["User Access Request Approvers CAB reviews"]
    H -->|Approved| I["Access provisioned,<br/>scoped to the party's own system"]
    H -->|Denied| J["FedRAMP notified within 5 business days;<br/>notification tracked in the ticket"]

Self-registration creates an account, not access. The portal login page offers Create New User Account. A self-registered account is associated with a client when the email domain matches; otherwise it is held on the Unknown site, unassociated. Either way, an approved User Access Request is required before the account can reach any certification data.

Scoping and exclusion are configuration, not discretion. Approved parties receive site-scoped report variants, so a party's views return its own system's records. Sensitive fields are excluded from shared reports as a property of the shared variant. What gets excluded follows CDS-CSO-RIS: specifics that would likely enable a threat actor come out, and the risk information an agency needs to authorize stays in.

Removal runs the same path. Access is removed through a User Access Request, so the removal carries the same approval and the same audit trail as the grant.

Denial has a clock. Denying an agency access request starts a 5-business-day obligation to notify FedRAMP (CDS-UTC-AAD, MUST). The notification is submitted manually on the FedRAMP agency-access-denial form and recorded in the User Access Request ticket that carried the denial, so the ticket is the evidence that the notification happened and when.

Access inventory and logging¶

The pairing matters. User administration answers who has access now; the User Access Request history answers who approved it, when, and why. The rule asks for an inventory and a history, and neither source alone is both.

Programmatic access¶

Programmatic access is a MUST for a FedRAMP-compatible trust center, and the rule has two halves: the access itself, and the documentation of it (CDS-TRC-PAC).

The mechanism. Agency and customer callers retrieve certification data over the GRC-ITSM REST API. The API returns the same site-scoped reports and the same Certification Documents the portal renders, which is how the rule's requirement for programmatic access to human-readable materials is met.

Credentials are provider-provisioned. There is no self-service token flow. Credentials are issued per organization and scoped to that organization's system, on an approved request submitted through Request Services on the same User Access Request path as portal access.

The documentation. The customer-facing Trust Center Access Guide covers credential issuance, authentication, report retrieval, document retrieval, and rate limits. It is published on this documentation website and linked from the trust center landing page, because the artifact CDS-TRC-PAC calls for is a URL to that documentation.

Consistency, formats, and identity¶

• One source, two renderings (CDS-CSO-CBF, MUST). Human-readable and machine-readable certification data are produced by the same automation from the same live records. There is no separately maintained machine-readable copy to reconcile, which is what the rule's automation requirement asks for.
• View and download in both forms (CDS-TRC-HMR, SHOULD). Reports render in the portal and are retrievable over the API; package artifacts are downloadable from Certification Documents, and the FedRAMP-schema JSONs are the machine-readable form of the package.
• The FedRAMP ID travels with the data (CDS-CSO-FID, MUST). Every report, notification, and communication produced under FedRAMP rules carries the system's FedRAMP identifier, so a recipient can align it to the right cloud service offering. A placeholder is carried until FedRAMP assigns the identifier.

Uninterrupted and self-service access¶

The rule's preferred pattern for uninterrupted sharing is on-demand just-in-time provisioning. The approval gate here sits at the front of the relationship rather than in front of each retrieval, which is what keeps the sharing itself uninterrupted.

Public information¶

Two rules require a genuinely public surface, reachable without a login, in both human-readable and JSON form: the public information profile (CDS-CSO-PUB, MUST) and the public service list (CDS-CSO-SVC, MUST).

Current state. The Public Information report implements the required shape and is served on the trust center behind login. The organization's current public surface is its FedRAMP Marketplace listing.

Commitment. The organization publishes a public no-login page carrying the public information profile and the service list, in human-readable and JSON form, generated from the same live records that feed the Public Information report so that the two formats stay consistent by construction (CDS-CSO-CBF). The page carries at least the information CDS-CSO-PUB enumerates, including the link to the trust center landing page with instructions for accessing information in the trust center, the next Ongoing Certification Report date, and the current FedRAMP Recognized independent assessment service. The service list is complete enough for a potential customer to determine which services are and are not in the FedRAMP Minimum Assessment Scope without requesting access to certification data (CDS-CSO-SVC).

Availability reporting is the client's. CDS-CSO-AVR is a MUST at Class C, and it is a client obligation rather than a platform capability. The client maintains the availability web service for the offering: current and at least 30 days of historical availability of core services including availability incidents, in human-readable and machine-readable formats, reachable even when the primary offering is not. The rule permits that service to be separate from the trust center, and here it is separate: it is the client's status service. This document records the obligation and its owner; the client's own operations documentation records how the service is run.

Discretionary sharing¶

• Responsible public package sharing (CDS-CSO-RPS, MAY). The organization may share some or all of the FedRAMP Certification Package publicly or with other parties where it determines that doing so is not likely to have an adverse effect on the offering. The determination is the ISSO's, and it is recorded before the sharing happens.
• Per-service certification materials (CDS-CSO-PSM, MAY at Class C; MUST at Class D). Where agencies adopt only part of the offering, the organization supplies one set of materials covering the shared aspects of the offering and separate materials only for the aspects unique to a service.

Trust center migration (Rev5)¶

When a Rev5 system migrates to the trust center, the organization notifies all necessary parties, including FedRAMP and each agency customer's security contact, and leaves information in its existing USDA Connect Community Portal secure folders explaining how to use the trust center to obtain certification data (CDS-CSF-TCM, MUST). This is a documented procedure carried out at migration, and it applies only while a USDA Connect presence exists.

Records, retention, and metrics¶

Per party with access, the record retains the User Access Request ticket and its approval, the account and its roles, the scoping applied, and, where access was denied, the denial and the FedRAMP notification recorded on the ticket. Per certification data artifact, the record retains the artifact itself in Certification Documents, its folder and system, and, for FedRAMP Certification Reports, the receipt and posting dates that evidence the 2-week obligation. Access log summaries are retained for at least six months (CDS-TRC-ACL). Historical snapshots are retained for the duration of the certification (CDS-CSO-HAD).

Metrics reviewed with these procedures: open and aged User Access Requests, access grants and removals per period, denials and notification timeliness against the 5-business-day obligation, accounts on the Unknown site awaiting association, recertification and account-review task completion, snapshot completeness against the Ongoing Certification Report series, and Certification Report posting time against the 2-week obligation.

Authority, review, and revision¶

Issued under the authority of the System Owner and binding on all personnel with access to the system. Exceptions require written System Owner approval and are documented.

The ISSO reviews this document for effectiveness persistently on the cadence in the ODV table, and when frameworks, the system, or lessons learned warrant; the System Owner gives final approval. The annual plan and policy review task under the Annual cadence parent is where that review is tracked.

Related documents¶

This article owns the sharing surfaces. The content served on them is owned elsewhere.

FedRAMP coverage¶

CDS general provider responsibilities: Public Information (MUST), Public Service List (MUST), Always Include FedRAMP ID (MUST), FedRAMP Certification Reports (MUST), Availability Reporting (MUST at Class C, varies by class; client-owned), Use Trust Centers (MUST), Consistency Between Formats (MUST), Responsible Information Sharing (MUST), Include Relevant Policies (MUST), Historical FedRAMP Certification Data (MUST), Per-Service Certification Materials (MAY at Class C, varies by class), Responsible Public Package Sharing (MAY) (CDS-CSO). FedRAMP-compatible trust centers: Uninterrupted Sharing (MUST), Programmatic Access (MUST), Agency Access Inventory (MUST), Access Logging (MUST), Human and Machine-Readable Certification Data (SHOULD), Self-Service Access Management (SHOULD) (CDS-TRC). Using a trust center: Agency Access Denial (MUST), Agency Access (SHOULD) (CDS-UTC). Rev5-specific: Trust Center Migration (MUST) (CDS-CSF-TCM).