Preview Environments Under FedRAMP: What Your Tool Needs to Provide

The first question federal contractors ask when evaluating a preview-environment tool is the one most vendors answer poorly: “Can I use this under my ATO?” The honest answer is rarely a clean yes or no. It depends on deployment model, where data lives at each stage, how the tool authenticates reviewers, and what the vendor will put in writing.

This guide is useful regardless of which tool you choose. The criteria apply to any vendor in the category — and to teams considering building the capability in-house.

Why “FedRAMP Authorized” Is the Wrong First Question

Vendors advertise “FedRAMP Authorized,” “Ready,” “In Process.” For preview tooling, those labels matter less than they look. Authorization covers the vendor’s SaaS in the vendor’s environment. Preview tooling operates on your code, your data, your environments. Vendor authorization is only useful if your ATO permits sending the relevant data to that SaaS — and for most CUI categories it doesn’t, regardless of authorization level.

The right first question is structural: where does the tool run, and what crosses your boundary? “Tool runs entirely inside our GovCloud account, vendor never touches it in production” makes authorization almost moot. “Code and reviewer activity flow into the vendor’s commercial-region SaaS” makes it central — and Moderate is rarely enough for High-baseline workloads.

Deployment Model

Preview tools fall into roughly four buckets:

1. SaaS-only. Vendor hosts everything; code, artifacts, and metadata flow into the vendor’s tenant. Dominant commercial model. Rarely viable for FedRAMP-bound workloads — the boundary crossing for source and review metadata is a posture most ISSOs reject for High baseline.

2. Customer-cloud orchestration, vendor control plane. Controller in vendor SaaS; builds and runtime in customer account via assumed-role or pull-based agents. Better than pure SaaS — code doesn’t leave — but the orchestration plane and metadata still sit outside the boundary. Partial fit at best.

3. Self-hosted (BYOC). Full tool — control plane, runtime, metadata, evidence log — deploys inside the customer’s account or on-prem. Vendor provides updates and consultative support; no production access. Fits FedRAMP cleanly. A handful of vendors are designed for this model; an in-house build can target the same shape.

4. Air-gapped. Self-hosted variant for environments that can’t reach vendor update servers. Update path is manual.

Push for specifics. “Self-hosted option available” can mean anything from fully on-prem to a thin agent that phones home. The clarifying question: with all outbound network access blocked, does the tool work for the lifetime of a single preview?

Data Flow

For each item below, ask the vendor where the data lives and what crosses the boundary:

• Source code. Should never leave your environment. Pull-based runners cloning from inside the boundary are acceptable; vendor-hosted runners cloning your repo are not.
• Container images and build artifacts. Built and stored inside the boundary. Pushing to a vendor registry is a boundary crossing.
• Environment variables and secrets. Managed through your existing infrastructure (Secrets Manager, Parameter Store, Vault). A vendor-managed secrets store is a hard no.
• Runtime telemetry. Lands in your existing observability stack. Forwarding to a vendor backend is a boundary crossing.
• Review activity and evidence. Most vendors get this wrong. The evidence log describing who reviewed what is sensitive metadata; it should live inside your boundary in a form you can audit and export. See /blog/audit-trail-preview-environment-evidence-portable/.
• Vendor support access. Properly architected self-hosted products run support on logs you share, not on access into your tenant. Production access is a boundary crossing and a U.S. persons problem.

Authentication and Access

Three constraints shape the auth path:

PIV/CAC. Federal stakeholders authenticate with PIV or CAC. Any tool whose reviewer auth assumes username/password or vendor-issued OAuth is a poor fit. Look for SAML or OIDC integration with your IdP, with certificate-based auth supported upstream. Login.gov and agency ICAM federations are the typical upstream IdPs.

U.S. persons enforcement. For ITAR, export-controlled, and many CUI rules, access must be restricted to U.S. persons. The tool needs attribute-based access control with the U.S.-person attribute flowing from your IdP. CUI specifics: /blog/pii-cui-preview-environments-federal-contractor-guide/.

External reviewers without accounts in your IdP. Government PMs, IV&V engineers, and COs usually don’t have accounts in your IdP. The tool needs a federation pattern — accept assertions from approved external IdPs, scoped to specific previews, recorded in the evidence log. This is what makes IV&V actually continuous: /blog/continuous-ivv-preview-environments-stage-gate/.

A tool whose reviewer auth assumes vendor-managed accounts is one you’ll have to wrap or replace.

Disclosure Standards

Even with self-hosted, you inherit the vendor’s supply chain, patching cadence, and architectural choices. The minimum disclosure set:

• A current architecture diagram showing every component, persistent store, and network boundary.
• An SBOM in SPDX or CycloneDX format.
• Documented incident response and vulnerability disclosure policy.
• Documented update cadence and signing practice. Image signatures verifiable against a published key.
• Clear statements about data the software collects (telemetry, license pings, crash reports) and how to disable or redirect each.
• If the vendor maintains FedRAMP, SOC 2, ISO 27001, or StateRAMP attestation, the actual report or boundary description, not the marketing badge.
• Written posture on the vendor’s authorization status, with explicit acknowledgment that self-hosted deployment doesn’t inherit it.

A vendor that can’t produce these on request isn’t ready to serve a federal contractor with an ATO obligation.

OSCAL

A nice-to-have moving toward a should-have: OSCAL component definitions describing how the tool implements or supports specific NIST SP 800-53 controls. Most preview tooling doesn’t yet ship OSCAL, but the federal market is moving that direction following OMB M-22-09. Vendors who can speak fluently to which controls they implement vs. inherit are easier to integrate into an SSP.

Checklist

For evaluating any preview tool against an ATO obligation:

1. Can the tool deploy fully inside our authorization boundary, with no required outbound calls during normal operation?
2. Where do source code, build output, runtime data, and review evidence live at each step?
3. Does reviewer auth integrate with our IdP, support PIV/CAC upstream, and enforce U.S.-persons access?
4. Is the evidence log exportable in a portable, tamper-evident format we can hand an auditor without giving them access to the tool?
5. Will the vendor provide an architecture diagram, SBOM, and written disclosure of data collection on request?
6. Does the vendor acknowledge in writing what their authorization does and doesn’t cover for our deployment model?

A Note on PreviewProof

Honest disclosure, since this is our blog: PreviewProof is not currently FedRAMP authorized. It’s designed for the BYOC model above — control plane, evidence log, and runtime deploy inside your authorized environment, with the vendor relationship covering the software, not operations. If you want a tool already shaped that way, it’s a candidate worth evaluating; the checklist above is the right way to evaluate us, the same as any other vendor or an in-house build. The questions matter more than the answer to which tool you pick.