AWS Public Sector Blog

Building machine-readable FedRAMP 20x evidence on AWS

Federal Risk and Authorization Management Program (FedRAMP) 20x requires every authorization package to include evidence in both human-readable and machine-readable formats that fully reconcile.

In this post, we walk through the evidence pipeline, from Amazon Web Services (AWS) Config evaluations and AWS Security Hub findings through transformation and storage, to producing the dual-format output that satisfies FedRAMP 20x Phase 2 completeness requirements.

The dual-format requirement

The Phase 2 completeness requirements state that “validation evidence must be embedded or linked directly from both human-readable and machine-readable submission formats,” and that “information within human-readable and machine-readable formats should fully reconcile.” This means you can’t maintain two separate documents that might drift apart. You need a single source of truth that generates both formats.

The Certification Data Sharing (CDS) rules further require that trust centers provide documented programmatic access to all FedRAMP Certification Data.

Evidence pipeline architecture

The evidence pipeline collects data from multiple AWS sources, transforms it into KSI-level compliance reports, and publishes both formats to the trust center. The following figure shows the end-to-end flow:

Evidence pipeline architecture showing data collection from AWS Config

Figure 1: Evidence pipeline architecture showing data collection from AWS Config, AWS Security Hub, Amazon Inspector, and AWS CloudTrail, transformation through AWS Step Functions and AWS Lambda, storage in the evidence lake, and dual-format output to the trust center

The pipeline runs on a recurring schedule using Amazon EventBridge rules. Under the Consolidated Rules for 2026, providers with Class C Certifications must verify and validate the status of machine-based information resources at least every 3 days, and providers with Class B Certifications at least every 7 days.

Data collection sources

The evidence pipeline draws from several AWS services, each providing a distinct category of compliance data that maps to one or more KSIs.

AWS Config compliance data

AWS Config evaluates resource configurations against rules and produces compliance results. The project includes two conformance packs (Low and Moderate) with 128 rules each. Each rule maps to one or more KSIs.

AWS Config provides:

  • Per-resource compliance status (COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE)
  • Configuration snapshots showing the actual state of each resource
  • Configuration history showing changes over time

A collection AWS Lambda function queries the AWS Config aggregator API to pull compliance data across all accounts in the organization.

AWS Security Hub findings

AWS Security Hub aggregates findings from AWS Config, Amazon GuardDuty, Amazon Inspector, AWS Identity and Access Management (IAM) Access Analyzer, and other services into a normalized format: AWS Security Finding Format (ASFF).

AWS Security Hub provides:

  • Aggregated compliance scores per standard
  • Individual findings with severity, resource details, and remediation guidance
  • Cross-account and cross-Region aggregation

Amazon Inspector vulnerability data

For Vulnerability Detection and Response (VDR) evidence, Amazon Inspector findings feed into the vulnerability tracking system with:

  • Common vulnerabilities and exposures (CVE) identifiers
  • Exploitability scores
  • Network reachability analysis
  • Remediation recommendations

AWS CloudTrail and identity data

AWS CloudTrail provides API activity logs that support KSI-Monitoring, Logging, and Auditing (MLA) evidence. AWS IAM Access Analyzer provides findings about unused permissions and external access, supporting KSI-IAM-Ensuring Least Privilege (ELP).

Additional evidence sources

Beyond these primary sources, several other AWS services contribute evidence for specific KSIs:

  • AWS Key Management Service (AWS KMS) key rotation status and usage metrics support KSI-Service Configuration (SVC)-Automating Secret Management (ASM) and KSI-SVC-Validating Resource Integrity (VRI)
  • Amazon Virtual Private Cloud (Amazon VPC) flow logs provide network traffic evidence for KSI-Cloud Native Architecture (CNA)-Restricting Network Traffic (RNT) and KSI-CNA-Using Logical Networking (ULN)
  • AWS Backup job status and recovery point data support KSI-Recovery Planning (RPL)-Aligning Backups with Objectives (ABO) and KSI-RPL-Testing Recovery Capabilities (TRC)
  • AWS Systems Manager inventory data supports KSI-Policy and Inventory (PIY)-Generating Inventories (GIV) with real-time asset and software inventory

Transformation: From raw data to KSI evidence

Raw compliance data from these sources must be transformed into KSI-level evidence. An AWS Step Functions workflow orchestrates this transformation:

  1. Collect – AWS Lambda functions query each data source and write raw results to the evidence lake in Amazon Simple Storage Service (Amazon S3)
  2. Map – A mapping function correlates each AWS Config rule, AWS Security Hub check, and Amazon Inspector finding to its corresponding KSI using the KSI mapping table
  3. Aggregate – For each KSI, the function calculates a compliance score based on the percentage of passing evaluations
  4. Format – The function generates both machine-readable (JSON) and human-readable (Markdown/PDF) outputs from the same aggregated data
  5. Publish – Results are written to the evidence lake and published to the trust center API

Machine-readable output structure

The following JSON example shows the structure of a KSI evidence report produced by the pipeline. This format enables automated validation by FedRAMP reviewers while maintaining traceability back to individual evidence sources.

{
  "report_id": "KSI-RPT-2026-04-15-001",
  "generated_at": "2026-04-15T00:00:00Z",
  "fedramp_id": "FR-XXXX-XXXX",
  "impact_level": "Moderate",
  "ksi_results": [
    {
      "ksi_id": "KSI-SVC-VRI",
      "ksi_name": "Validating Resource Integrity",
      "status": "COMPLIANT",
      "automated_validation": true,
      "evidence_sources": [
        "config:encrypted-volumes",
        "config:kms-key-rotation-enabled",
        "iac-scan:opa-svc-vri"
      ],
      "compliant_resources": 142,
      "total_resources": 142,
      "last_evaluated": "2026-04-15T00:00:00Z"
    }
  ]
}

This structure enables automated parsing by FedRAMP reviewers and assessors. Each KSI result includes the evidence sources that contributed to the evaluation, creating a traceable chain from raw data to compliance determination.

The evidence lake

All evidence is stored in Amazon S3 with versioning, AWS KMS encryption, and object lock for tamper resistance. AWS Glue catalogs the data, and Amazon Athena enables SQL queries across the evidence corpus.

The evidence lake serves multiple purposes:

  • Retention – Long-term retention supports the Certification Data Sharing (CDS) rules for historical FedRAMP Certification Data
  • Auditability – Object lock and versioning provide tamper-evident storage
  • Queryability – Amazon Athena enables ad-hoc analysis during assessments
  • Traceability – Every evidence artifact links back to its source evaluation

Directory structure

The evidence lake uses a date-partitioned directory layout in Amazon S3, organizing artifacts by source and format so that assessors and automated tools can locate any piece of evidence by date and type.

s3://fedramp-20x-evidence/
  ksi-reports/
    2026/04/15/
      machine-readable/
        ksi-report-2026-04-15.json
      human-readable/
        ksi-report-2026-04-15.md
  config-evaluations/
    2026/04/15/
      config-compliance-snapshot.json
  security-hub-findings/
    2026/04/15/
      findings-export.json
  inspector-findings/
    2026/04/15/
      vulnerability-report.json
  iac-scan-results/
    2026/04/15/
      opa-results.json
      cfn-guard-results.json
      checkov-results.json
  vdr-reports/
    2026/04/
      vdr-monthly-report.json
      vdr-monthly-report.md
  scn-records/
    2026/04/
      scn-history.json

Addressing complex FRR requirements

Several FedRAMP requirements involve future activities that can’t be validated through automated scanning alone. Earlier it was – “Several KSI-AFR requirements involve future activities that can’t be validated through automated scanning alone. “The Phase 2 requirements state that “where requirements include future activities like incident response, significant change notification, vulnerability detection, or other such regularly or persistently supplied reports, a sample report should be supplied.”

VDR: Vulnerability Detection and Response

The VDR pipeline produces monthly human-readable reports and machine-readable reports updated every 14 days. Each vulnerability is tracked with an N1–N5 impact rating, detection timestamp, evaluation timestamp, and remediation deadline based on severity-specific service level agreements (SLAs).

SCN: Significant Change Notifications

The significant change notification (SCN) automation classifies changes as routine, adaptive, or transformative. Sample SCN payloads demonstrate the notification format, including FedRAMP identifier, change type, customer impact analysis, and business/security impact analysis.

IEC: Incident Evaluation and Communication

Sample incident reports demonstrate the 1-hour notification format for FedRAMP, the Cybersecurity and Infrastructure Security Agency (CISA), and agency customers. Daily update templates and final incident report templates are included as evidence artifacts.

Reconciling human-readable and machine-readable formats

The key to reconciliation is generating both formats from the same source data in the same pipeline run. The transformation AWS Lambda function produces a JSON object, then a formatting function renders that same object as Markdown. Both outputs carry the same report identifier and timestamp, and both are stored in the same evidence lake partition.

During assessment, a reviewer can verify reconciliation by comparing any data point in the human-readable report against the corresponding field in the machine-readable output. Because both are generated from the same aggregation, they’re structurally identical.

Maintaining a single source of truth

The most common failure mode in dual-format evidence is drift between formats. Organizations that maintain separate human-readable and machine-readable documents inevitably find discrepancies during assessment. The solution is to treat the machine-readable format as the authoritative source and generate the human-readable format from it.

In practice, this means:

  • The AWS Step Functions workflow produces a JSON evidence object as its primary output
  • A rendering AWS Lambda function transforms that JSON into Markdown using templates
  • Both outputs are written to the evidence lake in the same pipeline execution
  • The report identifier, timestamp, and data hash are identical in both formats
  • Any update to evidence data triggers regeneration of both formats simultaneously

This approach satisfies the Phase 2 requirement that “information within human-readable and machine-readable formats should fully reconcile” by making reconciliation a structural guarantee rather than a manual verification step.

Connecting to the Open Security Controls Assessment Language

FedRAMP’s agency tooling rules call for Open Security Controls Assessment Language (OSCAL) as a required machine-readable format, and the evidence pipeline can output KSI results in an OSCAL-compatible structure. The pipeline maps each KSI to its corresponding NIST SP 800-53 controls in the System Security Plan (SSP), enabling assessors to trace from KSI evidence back to specific control implementations. An example file (oscal-ssp-fedramp-20x-example.json) demonstrates this mapping.

What comes next

With evidence collection and packaging in place, the next challenge is keeping it current. FedRAMP 20x replaces annual assessments with persistent validation. In Part 6 of this series, we operationalize continuous monitoring using AWS Security Hub aggregation, AWS Config conformance packs, Amazon GuardDuty, Amazon Inspector, and Sigma detection rules.

Next steps and resources

Dr. Tommy Kromer

Dr. Tommy Kromer

Dr. Tommy Kromer is a Practice Manager with AWS Security Assurance Services (SAS), focusing on public sector compliance and security operations. He has spent his career helping government contractors navigate complex regulatory landscapes, from the early days of DIACAP through some of the first RMF accreditations to today's CMMC requirements. Leveraging his experience across the Department of Defense and intelligence community, along with expertise in security operations center management and threat hunting, Tommy works closely with customers to align security and compliance as complementary forces that achieve mission-critical objectives.

Paul Keastead

Paul Keastead

Paul Keastead is a Senior Security Engineer with AWS Global Professional Services Security, where he builds the operational security mechanisms that govern how ProServe delivers to customers worldwide. His work spans engagement security automation, AI-powered provider risk assessments, and GenAI governance for a global delivery organization across 24 countries. He designs assessment frameworks and tooling that enable providers to demonstrate security posture across complex control environments including CMMC, FedRAMP, and critical infrastructure protection. He brings over a decade of security leadership across the Marine Corps, federal research, and private sector technology compliance.

Roger Fortuna

Roger Fortuna

Roger Fortuna is a Senior Assurance Consultant with AWS Security Assurance Services (SAS) specializing in Cybersecurity Maturity Model Certification (CMMC) and Department of Defense Security Requirements Guide (DoD SRG) compliance. He helps defense industrial base organizations and cloud service providers achieve and maintain their authorization objectives in the cloud. Drawing on deep expertise in CMMC assessment readiness, FedRAMP equivalency for DoD workloads, and Impact Level (IL) authorization requirements, Roger works closely with customers, assessors, and Amazon Web Services (AWS) teams to align defense compliance mandates with practical cloud architecture and business outcomes.

Satish Uppalapati

Satish Uppalapati

Satish Uppalapati is an Associate Assurance Consultant with AWS Security Assurance Services and has more than 8 years of experience in IT risk, governance, and regulatory assurance. He works with AWS customers to help align cloud environments with frameworks such as ISO 27001, SOC 2, and FFIEC. Satish also focuses on advancing governance for AI systems, including emerging standards such as ISO/IEC 42001.