KSI-AFR-ADS—Authorization Data Sharing
Formerly KSI-AFR-03
>Control Description
>NIST 800-53 Controls
>FRMR Requirements19
Normative requirements from the FedRAMP Requirements and Recommendations document — 13 mandatory, 5 recommended, 1 optional.
Use Trust Centers
Providers MUST use a FedRAMP-compatible trust center to store and share authorization data with all necessary parties.
Requirements and recommendations for FedRAMP-compatible trust centers are explained in ADS-TRC.
This requirement only applies to FedRAMP 20x.
Public Information
Providers MUST publicly share up-to-date information about the cloud service offering in both human-readable and machine-readable formats, including at least:
- Direct link to the FedRAMP Marketplace for the offering
- Service Model
- Deployment Model
- Business Category
- UEI Number
- Contact Information
- Overall Service Description
- Detailed list of specific services and their security objectives (see ADS-CSO-SVC)
- Summary of customer responsibilities and secure configuration guidance (if applicable, see the FedRAMP Secure Configuration Guide process)
- Process for accessing information in the trust center (if applicable)
- Availability status and recent disruptions for the trust center (if applicable)
- Customer support information for the trust center (if applicable)
- Next Ongoing Authorization Report date (see CCM-OAR-NRD)
Service List
Providers MUST publicly share a detailed list of specific services and their security objectives that are included in the cloud service offering using clear feature or service names that align with standard public marketing materials; this list MUST be complete enough for a potential customer to determine which services are and are not included in the FedRAMP Minimum Assessment Scope without requesting access to underlying authorization data.
Consistency Between Formats
Providers MUST use automation to ensure information remains consistent between human-readable and machine-readable formats when authorization data is provided in both formats.
Responsible Information Sharing
Providers MUST provide sufficient information in authorization data to support authorization decisions but SHOULD NOT include sensitive information that would likely enable a threat actor to gain unauthorized access, cause harm, disrupt operations, or otherwise have a negative adverse impact on the cloud service offering.
Historical Authorization Data
Providers MUST make historical versions of authorization data available for three years to all necessary parties UNLESS otherwise specified by applicable FedRAMP requirements; deltas between versions MAY be consolidated quarterly.
Public Guidance
Providers MUST publicly provide plain-language policies and guidance for all necessary parties that explains how they can obtain and manage access to authorization data stored in the trust center.
Agency Access Denial
Providers MUST notify FedRAMP by email to info@fedramp.gov within 5 business days of denying an agency access request for authorization data.
Uninterrupted Sharing
Trust centers MUST share authorization data with all necessary parties without interruption.
Programmatic Access
Trust centers MUST provide documented programmatic access to all authorization data, including programmatic access to human-readable materials.
Agency Access Inventory
Trust centers MUST maintain an inventory and history of federal agency users or systems with access to authorization data and MUST make this information available to FedRAMP without interruption.
Access Logging
Trust centers MUST log access to authorization data and store summaries of access for at least six months; such information, as it pertains to specific parties, SHOULD be made available upon request by those parties.
Implementation Summaries
Providers MUST maintain simple high-level summaries of at least the following for each Key Security Indicator:
- Goals for how it will be implemented and validated, including clear pass/fail criteria and traceability
- The consolidated _information resources_ that will be validated (this should include consolidated summaries such as "all employees with privileged access that are members of the Admin group")
- The machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
- The non-machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
- Current implementation status
- Any clarifications or responses to the assessment summary
Agency Access
Providers SHOULD share the authorization package with agencies upon request.
Human and Machine-Readable
Trust centers SHOULD make authorization data available to view and download in both human-readable and machine-readable formats.
Self-Service Access Management
Trust centers SHOULD include features that encourage all necessary parties to provision and manage access to authorization data for their users and services directly.
Responsive Performance
Trust centers SHOULD deliver responsive performance during normal operating conditions and minimize service disruptions.
Application within MAS
Providers SHOULD apply ALL Key Security Indicators to ALL aspects of their cloud service offering that are within the FedRAMP Minimum Assessment Scope.
1 optional guidance (MAY)
AFR Order of Criticality
Providers MAY use the following order of criticality for approaching Authorization by FedRAMP Key Security Indicators for an initial authorization package:
- Minimum Assessment Scope (MAS)
- Authorization Data Sharing (ADS)
- Using Cryptographic Modules (UCM)
- Vulnerability Detection and Response (VDR)
- Significant Change Notifications (SCN)
- Persistent Validation and Assessment (PVA)
- Secure Configuration Guide (RSC)
- Collaborative Continuous Monitoring (CCM)
- FedRAMP Security Inbox (FSI)
- Incident Communications Procedures (ICP)
>Trust Center Components5
Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.
From the field: Mature implementations express authorization data through automated pipelines — OSCAL packages generated from live system state, compliance dashboards pulling from GRC APIs, and GitOps-tracked configuration changes that create an immutable audit trail. Per ADS-TRC-PAC, trust centers must provide documented programmatic access including human-readable formats.
Package Access Portal
Programmatic and self-service access to authorization data — agencies retrieve packages on demand rather than waiting for periodic drops. Aligns with ADS-TRC-PAC requirement for documented programmatic access
Authorization Data Sharing Dashboard
Dashboard expressing authorization package status, agency access activity, and document freshness — making data sharing observable rather than assumed
Data Sharing Architecture Diagram
How authorization data flows between CSP, agencies, and FedRAMP PMO — including automated pipeline stages
Shared Responsibility Matrix
Delineation of CSP vs. agency responsibilities for maintaining and sharing authorization data
Authorization Data Sharing Policy
Human-readable documentation of how authorization packages and ConMon data are shared — the "why" behind programmatic access implementation
>Programmatic Queries
CLI Commands
gh api repos/{owner}/{repo}/releases --jq '.[].{tag: .tag_name, name: .name, published: .published_at}' | head -10gh api repos/{owner}/{repo}/releases/latest --jq '.assets[] | {name,size,download_count}'>20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Are all necessary parties (FedRAMP PMO, leveraging agencies, 3PAOs, CISA) identified and receiving authorization data, and how do you confirm no party is missing?
- •What types of authorization data are excluded from sharing, and how are those exclusions documented and justified?
- •How do you ensure authorization data shared covers all in-scope system components, including inherited services and external integrations?
- •When a new agency begins leveraging your authorization, what process ensures they are onboarded into data sharing without gaps?
Automation & Validation:
- •What happens if the automated data sharing pipeline fails to deliver authorization data on schedule — how is the failure detected and who is alerted?
- •How do you validate that shared authorization data is complete and uncorrupted after transmission?
- •What automated checks confirm that role-based access controls on shared data are enforced correctly, and what test evidence exists?
- •If an API endpoint used for ADS data delivery returns errors, what fallback or retry mechanism is in place?
Inventory & Integration:
- •How do you maintain a current registry of all parties consuming authorization data, and is that registry programmatically updated when agencies join or leave?
- •What tools integrate to produce the authorization data package (vulnerability scanners, SIEM, CMDB), and how do you verify each tool contributes its data?
- •Are there any authorization data elements tracked manually rather than pulled from automated sources, and how do you ensure those stay current?
- •How does your data sharing mechanism integrate with the FedRAMP ADS portal or API?
Continuous Evidence & Schedules:
- •What is your delivery cadence for authorization data, and how do you prove adherence to that schedule over time?
- •Is authorization data available to FedRAMP and agencies via API or machine-readable format, or only as static documents?
- •How do you detect when shared authorization data becomes stale or out of sync with your actual security posture?
- •What evidence demonstrates that data sharing has occurred consistently between assessment cycles?
Update History
Ask AI
Configure your API key to use AI features.