Skip to content

GovCloud and FedRAMP High readiness

Status: Planned | Last reviewed: 2026-08-30

TrueServe has no live AWS GovCloud environment and no FedRAMP authorization. The repository intentionally prevents the federal profile from being assigned. This page defines the path from planning code to a deployed, assessed, and authorized Class D boundary.

Current guardrails

  • fedramp-high-us-govcloud has status: planned. Database and admin API checks reject it.
  • govcloud.tfvars.example fixes partition-sensitive inputs, FIPS mode, private networking, exact Bedrock model IDs, and disables speech permissions.
  • values-compliance-govcloud-planned.yaml keeps verified: false, uses aws-us-gov, selects us-gov-west-1, enables FIPS SDK endpoints, and disables payment, external voice, and media workloads.
  • The validator rejects a verified planning file, commercial partition, non-FIPS federal manifest, stale profile hash, External Secrets region mismatch, transcription permission, or a non-planned profile.
  • No automation in this repository deploys the example.

Provisioning sequence

  1. Secure an agency sponsor or other accepted authorization path and engage the recognized assessment organization early.
  2. Approve the legal entity, cloud service offering, impact level, authorization boundary, data types, users, administrators, support personnel, interconnections, external services, build system, and customer responsibilities.
  3. Re-review the current AWS GovCloud service authorization scope and every exact Bedrock model immediately before creating a new profile revision. Remove any service, feature, or model that lacks evidence for the selected boundary.
  4. Create dedicated GovCloud accounts, organization controls, identity federation, logging and security accounts, private networking, private EKS, protected state, registries, keys, backups, and recovery destinations. Do not import commercial credentials or snapshots.
  5. Use only approved endpoints. Require FIPS where the cryptographic boundary calls for it. Validate DNS and network paths from running pods, including KMS, STS, ECR, S3, Secrets Manager, CloudWatch, Bedrock, and other admitted services.
  6. Apply the regulated Terraform stack with the GovCloud example as a starting point. Keep deployment_verified false and every application control false.
  7. Build and transfer release artifacts through the approved federal supply chain. Verify SBOM, provenance, signatures, vulnerability policy, admission checks, administrator access, and separation from commercial CI.
  8. Deploy the planned Helm overlay with synthetic public data. Test default-deny networking, strict mTLS, identity, logging, WORM export, backup and restoration, incident handling, provider denial, data residency, and failure behavior.
  9. Build the SSP, control implementation statements, policies, procedures, inventory, diagrams, data flows, configuration baseline, contingency plan, incident plan, interconnection agreements, privacy artifacts, supply-chain plan, SAP/SAR inputs, POA&M, and continuous-monitoring procedures.
  10. Complete independent assessment and remediation. Obtain the authorization decision. Only the authorization owner may approve changing the profile from planned to active.
  11. Create a new reviewed profile revision and hashes. Record the authorization and assessment evidence outside Git, set the verified controls and ticket, and generate a new manifest. Never edit the existing planned revision in place.
  12. Begin required continuous monitoring, vulnerability remediation, inventory reconciliation, POA&M governance, incident reporting, annual assessment activity, and significant-change review.

Initial product boundary

The committed profile permits regional Bedrock text inference only. The overlay disables payment and all external voice, SIP, CCaaS, media, and commercial integration workloads. Treat any proposal to add speech, telephony, external tools, observability SaaS, support access, or cross-boundary updates as a significant boundary change that needs service-scope evidence and authorization review.

Activation evidence checklist

The final verification ticket must link to evidence for:

  • GovCloud account and partition ownership;
  • private EKS endpoint, control-plane logging, customer-managed encryption, node hardening, and admission controls;
  • exact profile hash, image digests, SBOMs, provenance, signatures, and vulnerability results;
  • exact regional model IDs and invocation permissions;
  • FIPS endpoint configuration and the applicable validated cryptographic modules;
  • workload IRSA trust and denied-path IAM tests;
  • CloudTrail, Config, Security Hub, GuardDuty, VPC flow logs, alert delivery, time synchronization, and evidence retention;
  • database and cache resilience, backups, restoration, recovery objectives, and contingency exercise;
  • application audit-chain verification and WORM reconciliation;
  • privacy, AI governance, incident, configuration, access, and change records;
  • completed assessment artifacts, accepted POA&M, and authorization decision.

Until all items pass, leave the profile planned and the manifest unverified.