FedRAMP infrastructure as code, built inside the boundary
Terraform for AWS GovCloud, Azure Government, and GCP Assured Workloads, written so the authorization boundary is a property of the code rather than a diagram someone redraws before each assessment. We build the boundary, the pipeline that deploys into it, and the evidence that proves both. Senior US-citizen engineers, founder-led, no offshore delivery.
Weekly demos · written status · continuity after the build
The boundary decides the cost. Everything else follows from it.
Teams treat the authorization boundary as a diagram produced for the package. It is the single decision that sets how long FedRAMP takes and what it costs, because everything inside it inherits continuous monitoring, vulnerability scanning on a fixed cadence, configuration baselines, incident response coverage, and evidence for every applicable control. Everything outside it inherits none of that.
Four questions decide most of the budget, and all four are answerable on day one:
- Does CI/CD run inside the boundary, or outside it with federated access in?
- Is the monitoring and logging stack inside? If it ingests system data from inside, usually yes.
- Where does support tooling sit, and what can it reach?
- Which third-party services touch the data, and do they carry their own authorization?
Get those four wrong and you have added a year. Get them right and Moderate becomes a hard project rather than an existential one. We draw the boundary before writing any Terraform, and we express it as code rather than as a drawing, because a diagram cannot be diffed, reviewed, or enforced.
Where you are in the process changes what we do first
You have picked an impact level, or you have not
Low, Moderate, and High carry materially different control counts and monitoring obligations. Most SaaS vendors selling to civilian agencies land at Moderate. Picking High because it sounds safer is one of the more expensive mistakes available, and it is usually reversible only by restarting.
You are on Rev5, and 20x is arriving
FedRAMP has published that 20x will replace Rev5, with phased mandatory adoption. That direction rewards architecture where controls are already enforced in code and evidence already emits continuously. For teams built that way, a shift toward machine-verifiable indicators is a reporting change. For teams whose controls live in a document and whose evidence is assembled by hand, it is a rebuild.
You have a sponsor, or you are still looking
Agency sponsorship runs on its own timeline and does not wait for your architecture. The boundary work is the part you control, and it is the part that determines whether you are ready when a sponsor appears.
What in-boundary costs you in practice
The phrase sounds administrative until you try to run a pipeline. Inside a FedRAMP boundary in AWS GovCloud, the conveniences of a commercial account quietly stop being available. Fewer services are authorized, some regions and features do not exist, identity federation crosses a partition, and the managed runners most teams deploy from are sitting in the wrong place entirely.
Most teams discover this after building the pipeline. The fix is not to move the pipeline inside, which pulls the whole delivery toolchain into scope. The fix is a narrow, federated, short-lived path into the boundary, with the runner outside and the credential scoped to the deployment role and nothing else.
That one architectural choice removes an entire category of finding, keeps your engineers on tools they already use, and keeps the delivery toolchain out of your control count.
What we build
The boundary, in Terraform
Network segmentation, explicit egress deny, KMS key policies with no wildcard principals, and IAM trust policies scoped to the exact role and ref that may assume into the data plane. Reproducible across environments, reviewable in a pull request, and diffable when an assessor asks what changed.
The deployment path into GovCloud
Federated, short-lived credentials from a runner that stays outside the boundary. No long-lived access keys in CI secrets, which is the single most common finding we are called in to close.
Evidence that emits rather than gets assembled
Signed artifacts, SBOM generation, verification at admission, and control evidence written continuously to an immutable store. Continuous monitoring becomes a query your assessor can run rather than a package your team reconstructs.
Policy as code at the admission point
Baseline configuration enforced by policy that rejects the non-compliant change and logs the rejection. The rejection is both the control and its own audit trail, which is what stops the same finding recurring next cycle.
How an engagement runs
1. Boundary and scope, before any code
We answer the four questions above against your live environment and produce a written boundary decision with the control-count consequence of each option. This is where the schedule is won or lost.
2. Terraform and the deployment path
The boundary in code, the federated path into it, and the pipeline changes that keep your delivery toolchain out of scope. Weekly demos and written status throughout.
3. Evidence and policy enforcement
Signing, SBOMs, admission control, and continuous evidence emission wired to the controls that need them.
4. Handover, and continuity if you want it
Your engineers can take over any part at any point. The work is documented so that is a real option rather than a courtesy. Teams that prefer standing capacity move to a retainer.
Why an engineering firm rather than an advisory firm
We are deliberately not a 3PAO
An assessor cannot remediate findings they identified without creating an independence conflict. We do not assess, so there is nothing to be independent from. Most engagements run alongside an assessor, and we will talk to yours directly if it closes a finding faster.
The person on the call writes the Terraform
The standard firm model puts senior people on the sales call and junior people on delivery. We run it inverted. Founder-led, with senior US-citizen engineers carrying implementation and no offshore delivery.
Fixed scope and fixed price
We absorb the schedule risk rather than passing it to you. Written deliverables with acceptance criteria.
We say no to work outside the specialization
We do not write SSP narrative, author policy, or run vendor management. If that is what you need, we will say so on the first call and point you to a firm that does it well.
Coverage
Frameworks: FedRAMP Moderate and High, FedRAMP 20x Key Security Indicators, NIST SP 800-53 and 800-171, DoD IL4 and IL5, CMMC 2.0. Also SOC 2 Type II, HIPAA, HITRUST, and PCI DSS for vendors selling into commercial and federal buyers at once.
Platforms: AWS including GovCloud, Microsoft Azure including Azure Government at IL5, Google Cloud including Assured Workloads, and Oracle Cloud including OCI Government.
Stack: Terraform, Kubernetes across EKS, GKE, AKS and OKE, GitLab CI/CD, GitHub Actions, Argo CD, Open Policy Agent, and production Python for the services and tooling around them.
A representative engagement
We architected the FedRAMP Moderate authorization boundary for an AI SaaS vendor pursuing federal authorization, with the boundary drawn before any Terraform was written. Read the case study →
Related work: a HIPAA CI/CD overhaul for an AI SaaS vendor, and HIPAA-compliant CI/CD pipelines for vendors selling into healthcare as well as federal buyers.
Field notes
Working notes from active engagements, written for engineers rather than for a compliance binder.
What federal and defense engineering leaders say after working with Stonebridge
"We've now hired Lucas three times, FedRAMP architecture, a Kubernetes migration, and a HIPAA CI/CD overhaul, and he's delivered on every one. What makes him stand out is the combination of deep technical skill across AWS, GCP, Terraform, and Kubernetes with genuine experience in regulated environments."
"Hired Stonebridge Tech Solutions for a FedRAMP project on GCP and he nailed it, the architecture aligned cleanly with Moderate controls and the documentation was audit-ready."
Questions
Do you write the SSP and the assessment narrative?
No. We cover the technical layer: architecture, Terraform, pipeline, identity, logging, and evidence. Policy authoring, SSP narrative, and administrative safeguards belong to a GRC discipline and a different kind of firm.
Are you a 3PAO?
Deliberately not, and never will be. An assessor who remediates their own findings has an independence problem. We engineer; your assessor assesses.
We are already mid-authorization. Is it too late?
Usually not, though boundary questions get more expensive the later they are answered. Tell us the assessment date on the first call and we will say plainly what is reachable before it.
Do you work in Azure Government and GCP Assured Workloads?
Yes, including Azure Government at IL5. The boundary reasoning is the same. Partition mechanics and authorized service lists differ, and those differences are where the schedule risk lives.
How quickly can you start?
Usually within two to three weeks of signature, sooner if there is a fixed assessment date.
Draw the boundary first
Thirty minutes, no deck. Describe the workload and the federal buyer you are chasing, and we will tell you which of the four boundary questions is going to cost you the most. A written proposal follows within 48 hours.
Book a 30-minute scoping call →Know exactly where you stand
Seven questions about your architecture. Before you talk to anyone, you get your control count, the first-cycle evidence cost in engineer-hours and dollars, and the scope-reduction moves that cut both. Covers HIPAA, HITRUST, SOC 2, FedRAMP Moderate and High, DoD IL4/IL5, and PCI DSS.
- Control count scoped to your environment, not a generic framework list
- First-cycle evidence cost, in engineer-hours and dollars
- The scope-reduction moves that cut it
- No call, no commitment, and no gate before the number
Lucas Jones, founder
Six years building cloud infrastructure and CI/CD pipelines in regulated environments. HIPAA, FedRAMP, and SOC 2 engagement work for healthcare and defense engineering teams across AWS, GCP, Azure, and OCI. The senior engineer who scopes your engagement leads it and stays accountable through handoff. Senior engineers only, all US citizens. No offshore delivery.
The same patterns documented in Field Notes are what get applied during real client engagements.
Pick a time. Skip the back-and-forth.
30-minute discovery call. We walk your current cloud posture, talk about the engagement that fits, and you get a written proposal within 48 hours.