What we built
The engagement delivered the full set of artifacts a 3PAO expects during readiness review, plus the engineering primitives the client team needed to keep operating inside the boundary after we left.
Terraform module library. Account scaffolding, IAM federation, KMS topology, EKS cluster baseline, RDS with regulated defaults, Bedrock endpoint configuration, and the centralized logging account. Every module ships a control narrative file. Policy gates (OPA + Sentinel) reject non-regulated services, non-FIPS endpoints, and unsigned container images at plan time.
Identity and access. IAM Identity Center as the only path into the boundary. Role catalog with time-bounded assumption windows. Break-glass procedure documented and rehearsed. Access reviews automated quarterly, output flowing to the logging account.
Logging architecture. Logging account isolated to write-only from production and staging. S3 Object Lock retention configured for 7 years. SIEM (Splunk) integration via PrivateLink, read-only. CloudTrail organization trail, VPC Flow Logs, EKS audit logs, and KMS key usage all flowing in.
Pipeline. GitHub Actions self-hosted runners inside the boundary on isolated EKS node groups. Container images built and signed inside the boundary. Bedrock-backed inference deployed via GitOps (Argo CD) with admission control rejecting unsigned images and non-baseline configurations.
Control documentation. SSP-ready control narratives generated from the Terraform module library. Continuous monitoring plan documented. Incident response runbooks rehearsed with the client team. A 3PAO readiness pack delivered with the boundary diagram, data flow diagrams, and inherited-service mapping.
"Lucas handled a FedRAMP compliance project for us and it was a huge win. He architected the infrastructure to align with FedRAMP Moderate requirements, documented everything thoroughly for auditors, and didn't cut corners. Communication was excellent throughout and he proactively flagged issues before they became problems."
Ryan S., CTO @ AI SaaS
Results
| Outcome |
| Passed |
3PAO readiness review on first-party assessment |
| On track |
authorization timeline matched the customer deadline |
| 0 |
significant changes required after boundary lock |
The client passed first-party 3PAO readiness review on schedule. The authorization boundary in the SSP matches the architecture diagrams; the architecture diagrams match the Terraform; the Terraform produces the resources the auditor will examine. There is no gap between document and reality, which is the single most common cause of 3PAO findings.
What made it work
Drawing the boundary before writing Terraform. Every subsequent decision derived from the boundary diagram. When a question arose ("should this service be inside?") the answer was already documented. There was no negotiation mid-engagement about whether a service was in scope.
Control narratives shipped alongside modules. Writing the control narrative when the Terraform module is written is the highest-leverage discipline in FedRAMP engineering. The narrative becomes a property of the module; the SSP is generated; the auditor's questions are answered by the same source of truth that produced the resources.
Policy gates rejecting non-regulated patterns. OPA and Sentinel gates at plan time prevented the most common drift pattern: an engineer reaching for a familiar commercial-region service that is not FedRAMP-authorized. The gate is boundary discipline at the speed of terraform plan.
Originally published at stonebridgetechsolutions.com.
Stonebridge Tech Solutions builds compliance-grade cloud infrastructure for healthcare and defense teams. If you want a rough read on your own control count and first-cycle audit cost, the scope estimator takes about two minutes.