Regulated engineering teams pay for the cloud twice. Once to build it. Once to prove it.
Most cloud infrastructure consulting was built for unregulated software. The patterns optimize for speed, simplicity, and developer experience. They work fine until the auditor arrives and asks for cryptographic evidence that every system component, every data flow, and every access decision can be traced, validated, and reconstructed.
At which point the engineering team spends three weeks reconstructing six months of operational history into PDFs. The compliance team interprets policy documents that describe what the infrastructure is supposed to do. The auditor finds gaps. The remediation work begins. Everybody loses time. The next audit cycle starts the same way.
We have watched this pattern repeat across hospital systems, pharmacy benefit managers, clinical SaaS startups, biotech platforms, defense technology companies, and federal contractors. The engineering team understands the application. The compliance team knows what the framework requires. The infrastructure in the middle has never been built to satisfy both, and the audit cost is paid in quarterly bursts of remediation panic.
The Evidence-Driven Infrastructure framework exists because the two-system problem is solvable. Architecture that emits compliance evidence as a property of how it operates does not slow engineering down. Auditors get queryable, signed proof. Engineers get a system that builds itself toward audit-readiness on every deployment. Security teams get continuous validation instead of quarterly reconstruction.
The framework is not a product. It is the methodology Stonebridge applies to every engagement. The principles are infrastructure-broad. The implementation differs across AWS, Google Cloud, Azure, and Oracle Cloud Infrastructure. The architecture is identical.
Evidence-Driven Infrastructure didn't appear in a vacuum. It synthesizes existing wisdom.
The contribution of the framework is not in inventing new patterns. It is in combining established federal standards, healthcare compliance frameworks, supply chain integrity work, and DevSecOps practice into a coherent infrastructure methodology that applies cleanly across regulatory regimes.
The framework synthesizes:
- NIST SP 800-53 Continuous monitoring (CA-7), configuration management (CM-3), and audit accountability (AU) families from the foundational federal security control catalog. The Continuous Evidence principle inherits its operational discipline from this baseline.
- FedRAMP 20x KSIs The Key Security Indicator model treats compliance as machine-readable, continuously-validated evidence. Structurally aligned with the framework. The Phase 3 rollout in Q3 2026 makes this the canonical federal expression of Evidence-Driven Infrastructure.
- HITRUST CSF Risk-based scoping and prescriptive technical controls. Demonstrates that compliance frameworks can be both prescriptive and automatable. The Boundary First principle inherits its data-flow rigor from HITRUST's scoping methodology.
- SLSA supply chain The Supply chain Levels for Software Artifacts framework's provenance attestation model is the basis for how the framework's pipelines generate signed, verifiable build evidence. SLSA Level 3 is the default for regulated builds.
- Open Policy Agent OPA's policy-as-code model, combined with Rego, is the executable layer of the Policy as Code principle. Sentinel, Conftest, Kyverno, and native cloud policy engines extend the same pattern across infrastructure layers.
- DevSecOps practice Shift-left security, infrastructure as code, and CI-driven compliance gates inform the operational layer. The framework is what happens when mature DevSecOps practice meets regulated industries that demand audit-grade evidence.
The framework's contribution is twofold. First, it names the architectural commitments these patterns share, so engineering teams can apply the same set of decisions across HIPAA, FedRAMP, and HITRUST without rebuilding their thinking for each regime. Second, it documents how the patterns apply through a documented engagement model so the work is reproducible across clients, not dependent on tacit expertise that walks out the door.
The patterns were validated across 8+ healthcare and defense engineering engagements before being codified into the framework's current form. The patterns that worked got named as principles. The patterns that failed got documented as the field notes from active engagements. The result is a methodology that has been tested in production, in regulated industries, with auditors in the loop, on real timelines, against real budgets.
engagements delivered
addressed by the methodology
by Google + Bing AI
Four principles, applied without exception.
Every Stonebridge engagement is structured around four principles. They are not optional. They are not menu items. They are the architectural commitments that distinguish Evidence-Driven Infrastructure from generic cloud consulting.
Boundary First
Architecture is derived from where sensitive data flows. Every account, network, identity, and service is positioned in relation to the data boundary.
Continuous Evidence
Every system component emits signed, queryable evidence as a property of how it operates. Continuously available. Auditor-ready by design.
Policy as Code
Compliance controls are expressed as executable code that runs on every change. Drift fails the build. Non-eligible services are rejected at plan time.
Founder-Delivered
Every engagement is delivered by the same engineer who scoped it. No junior staff handoffs. No offshore subcontractors. The person on the discovery call writes the Terraform.
Boundary First.
Before any Terraform is written, before any pipeline is configured, before any IAM role is created, the boundary is mapped. Where does protected health information enter the system? Where is it stored? Where does it leave? Where does controlled unclassified information cross trust zones? What identities can reach the boundary, and under what conditions?
Every account, network range, service, and identity inside the boundary is treated as in-scope for compliance. Everything outside the boundary is positioned to interact with the boundary explicitly, audited, and mutually authenticated. This is the architectural commitment from which every subsequent decision is derived.
The boundary is the line between "data the regulator cares about" and "everything else." We draw the line first, then build the infrastructure around it. Most consulting projects do the opposite: they build the infrastructure first, then try to figure out where the line is at audit time. That is the source of the panic.
This single architectural choice eliminates entire categories of audit findings. Cross-account IAM policies cannot accidentally bridge the boundary. Network paths cannot inadvertently route sensitive traffic through non-eligible services. Engineers cannot accidentally deploy workloads into the wrong environment, because the boundary is enforced as a property of the infrastructure, not a property of human discipline.
What this looks like in practice
- AWSDedicated accounts for PHI or CUI workloads, separated from corporate and non-regulated workloads. Transit Gateway for explicit, audited cross-account connectivity. Resource Access Manager for shared network resources scoped to the boundary.
- Google CloudDedicated projects for PHI workloads with VPC Service Controls perimeters. Private Service Connect for boundary-respecting database connectivity. Shared VPC architecture with isolated subnets per environment.
- AzureDedicated subscriptions for regulated workloads. Private Link for cross-subscription service access. Network segmentation enforced through Azure Firewall with Premium tier policy rules.
- All cloudsIdentity federates from a central identity provider with role-based, time-bounded access to boundary resources. Break-glass procedures are documented and audit-logged.
The Boundary First principle is the architectural foundation of every HIPAA Cloud Architecture engagement, every FedRAMP environment, and every regulated Kubernetes platform we ship.
Continuous Evidence.
Traditional compliance treats evidence as an artifact: collected at audit time, packaged in PDFs, reviewed by humans, stored in a SharePoint folder, and forgotten until the next assessment. The cost is paid in two ways. First, in the human time required to reconstruct historical operational state. Second, in the gap between what the evidence claims and what the infrastructure is actually doing right now.
Evidence-Driven Infrastructure inverts the model. Every account event, every pipeline run, every policy decision, every signature verification, every deployment authorization, and every drift detection produces signed, immutable evidence. Evidence is stored in retention-locked, write-once storage. Evidence is queryable in real time. Evidence is structured so that the question "show me the security review for last quarter's release" is answered with a query, not a project.
Think of it like a flight data recorder. Every action the infrastructure takes is recorded, signed, and stored where engineers cannot alter it. When the auditor asks "what happened on this date, with this system, by this person," the answer is a database query that returns in seconds, not a multi-week reconstruction project.
This principle is why the framework is called Evidence-Driven Infrastructure. The infrastructure is not built to host the application and then taught to produce evidence. The infrastructure is designed around the evidence requirements, and the application runs inside that envelope.
What this looks like in practice
- PipelinesEvery pipeline run emits SBOMs, vulnerability scan results, policy decision logs, signature chains, and deployment authorizations to an evidence bucket with retention locks and access controls that are themselves audit-logged.
- IdentityEvery authentication, authorization, and access decision is logged centrally with tamper-evident retention. Privileged access is time-bounded, justified, and post-reviewed.
- NetworkVPC flow logs, DNS query logs, and firewall decisions ship to centralized logging accounts with retention locks. Cross-account traffic carries cryptographic provenance.
- Data planeKMS key usage is logged. Database access patterns are audited. Encryption state is verifiable from cold storage backward through the entire data lifecycle.
- StandardsEvidence is structured to FedRAMP 20x machine-readable requirements (OSCAL where applicable), HITRUST CSF mappings, and HIPAA Security Rule audit log specifications. The same evidence stream satisfies multiple frameworks.
The Continuous Evidence principle is what differentiates the HIPAA-Compliant CI/CD pipelines we build from generic CI/CD modernization. It is also the architectural pattern that makes FedRAMP 20x KSI implementation tractable, because FedRAMP 20x is itself a continuous-evidence framework.
Policy as Code.
A policy document that describes what the infrastructure should do is not a control. It is a description of an intention. A control is an enforcement mechanism that runs against the infrastructure and fails when the intention is violated.
Every Stonebridge engagement encodes the relevant compliance controls as executable policy. The chosen tools depend on the layer: Open Policy Agent with Rego for cluster admission control and Terraform plan-time enforcement, Sentinel for HashiCorp tooling, Conftest for CI-level configuration validation, and native cloud policy engines (AWS Service Control Policies, GCP Organization Policies, Azure Policy) for foundational guardrails. The pattern is the same regardless of the tool: the policy is the test, the test runs on every change, and the change fails when the policy is violated.
If your compliance policy says "PHI must be encrypted with customer-managed keys," that sentence does nothing on its own. The Policy as Code principle turns that sentence into a check that runs every time a Terraform plan is generated. If anyone tries to deploy a database without customer-managed encryption, the change is rejected before it ever reaches production. The policy is enforced by the infrastructure, not by a human remembering to review the diff.
Policy as Code is what turns compliance from a discipline into an architecture. The engineering team is no longer responsible for remembering the controls. The infrastructure is responsible for enforcing them. Engineers are free to move quickly within the boundary because they cannot accidentally cross it.
What this looks like in practice
- Plan timeTerraform plans are evaluated against Rego or Sentinel policies before apply. Non-eligible cloud services are rejected. Untagged resources are blocked. Cross-boundary IAM grants fail the plan.
- CI timeContainer images are scanned, signed, and verified. SBOMs are required. Provenance attestations (SLSA Level 3) are enforced. Deployment requires signed evidence from upstream stages.
- Admission timeKubernetes admission controllers (Kyverno, OPA Gatekeeper) reject pods that violate security baselines. Image pull policies enforce signed registries only.
- RuntimeDrift detection runs continuously against declared state. Any divergence triggers alerts. Drift is treated as a build failure, not a notification.
- MappingEvery policy is annotated with the framework controls it satisfies (HIPAA Security Rule, NIST 800-53, HITRUST CSF). The same code provides multi-framework coverage.
Policy as Code is the principle that makes HIPAA CI/CD implementations tractable and what enables FedRAMP 20x KSI automation. It is also the layer where the framework compounds: every policy written for one client becomes a starting template for the next, refined across engagements into a library of reusable, framework-mapped controls.
Founder-Delivered.
The first three principles are technical. The fourth is structural, and it is the principle that most distinguishes Stonebridge from staffed consulting agencies. The standard agency model is broken in a specific, observable way. We do not work within that model.
At a typical consulting firm, a senior partner sells the engagement. The partner sets the expectations, signs the SOW, and runs the kickoff call. Then the partner moves to the next sale, and the work is handed to a delivery team that is two or three career levels junior. The delivery team has never seen the architectural problems before. The work product reflects the experience gap. The senior partner returns for the closing presentation to reassure the client that the work is good. The client pays partner rates for associate work, and the engineering decisions the partner would have made never get made.
For unregulated workloads, the staffed model is suboptimal but survivable. For regulated cloud infrastructure, the staffed model produces audit findings, remediation cycles, and quietly broken architecture. The senior person who would have caught the IAM boundary mistake was not in the room when the IAM boundary was designed.
The person you meet on the sales call is the person who actually does the work. There is no handoff to a junior team after you sign. There is no offshore subcontractor writing the code. There is no churn between staff. The total knowledge-transfer cost across the engagement is zero, because there is no team to transfer knowledge across.
Stonebridge will not staff out the work. Stonebridge will not white-label another agency's deliverables. Stonebridge will not subcontract architectural decisions. Every engagement is scoped, designed, written, deployed, and handed off by the same engineer. The discovery call is with the founder. The Terraform commits are by the founder. The runbooks are written by the founder. The on-call training for your team is delivered by the founder.
This is the principle that turns a six-week engagement into a real partnership. The questions you ask in week four are answered by the engineer who made the architectural decisions in week one. The pricing reflects the model, and the model is non-negotiable.
What Evidence-Driven Infrastructure rejects.
A framework that doesn't say what it's against says nothing. The four principles are claims about what works in regulated cloud engineering. The corresponding rejections are claims about what is broken in the consulting market we operate in.
Compliance as a policy document.
A SharePoint folder of PDFs describing what the infrastructure should do is not compliance. It is a description of an intention. If the infrastructure does not enforce the policy, the policy does not exist. We do not produce policies for someone else's infrastructure.
Quarterly evidence reconstruction.
Three weeks before each audit, the engineering team manually assembles screenshots, log exports, and approval emails into a binder. The binder describes operational state from months ago, with no proof it is still current. This is not evidence. It is archaeology.
Performative checkbox audits.
Annual point-in-time assessments that satisfy paperwork requirements without measuring whether the controls actually work. Pen tests run for compliance theater rather than to find real findings. Drift between what the policy claims and what the infrastructure does.
Bait-and-switch consulting delivery.
A senior partner sells the engagement, sets the expectations, and hands the work to a delivery team two career levels junior. The client pays partner rates for associate work. The senior partner returns at the closing presentation to reassure the client. We do not work this way, and we will not.
Frameworks-first, infrastructure-second.
Teams adopt a compliance platform, populate it with controls, and then try to retrofit infrastructure to match. The platform exits the audit happy. The infrastructure quietly drifts. The next audit finds the gap. The remediation cycle starts again.
GRC platforms as a substitute for engineering.
Vanta, Drata, and similar platforms are useful for evidence ingestion and presentation. They are not a substitute for the engineering work that produces the evidence in the first place. The platforms are downstream of architecture, not a replacement for it.
One framework, many compliance regimes.
The Evidence-Driven Infrastructure framework is framework-agnostic. The four principles do not change between a HIPAA engagement and a FedRAMP engagement. The control mappings differ. The evidence formats differ. The boundary characteristics differ. The underlying engineering is the same.
Every Stonebridge engagement produces a control mapping document that maps the infrastructure we build to the specific regulatory frameworks the client is subject to. The same Terraform module library that satisfies HIPAA Security Rule technical safeguards typically satisfies the equivalent SOC 2 Type II controls, the relevant HITRUST CSF technical controls, and most of the FedRAMP Moderate baseline simultaneously.
How Evidence-Driven Infrastructure maps to common regulatory frameworks
Where this framework does not fit.
A methodology that claims to apply universally claims too much. Evidence-Driven Infrastructure works in a specific market segment. Outside that segment, the principles are still sound, but the engagement model and the engineering investment are not the right fit.
- Not for unregulated SaaS. If your business does not face a compliance forcing function (HIPAA, FedRAMP, HITRUST, SOC 2 Type II, CMMC, or contractual customer requirements), the framework's investment in continuous evidence is overhead you do not need. Use simpler patterns until you do.
- Not for organizations under 50 employees with no procurement pressure. If your buyers do not yet ask for compliance attestations, the engineering work is premature. We do not believe in selling compliance theater to teams who do not need it.
- Not for greenfield builds with no audit deadline. The framework is most valuable under deadline pressure. If you have unlimited runway and no forcing function, you are likely better served by a phased internal build than a Stonebridge engagement.
- Not for procurement-only engagements. We do not write SOC 2 narratives without implementation. We do not produce policies for someone else's infrastructure. The framework requires architectural engagement, not documentation services. If you need a writer, hire a writer.
- Not for organizations seeking a single audit pass. The framework is structured for continuous compliance posture. If your goal is to pass one audit and then stop investing, the engineering work will outlive its utility. A simpler remediation engagement may fit better.
How to apply the framework to your infrastructure.
Three engagement models support the framework at different stages of your compliance journey. Most clients start with an audit, which produces a written roadmap and often gets approved as a follow-on build. Clients with a fixed audit deadline come straight to the build. Clients who want founder-led continuity after the build move to a Managed Compliance Retainer.
Compliance Cloud Audit
Fixed-fee assessment of your existing cloud infrastructure or CI/CD pipeline against the relevant framework (HIPAA, FedRAMP, HITRUST, SOC 2). Produces a control mapping document, prioritized remediation roadmap, and effort estimates per finding. Often converts to a build engagement.
See audit engagements →Compliance Cloud Build
Hands-on engineering engagement to architect and ship the infrastructure. Includes Terraform IaC, policy as code, evidence pipelines, control documentation, runbooks, and on-call training for your team. Pricing scales with framework scope, infrastructure complexity, and timeline. FedRAMP authorization builds, HITRUST CSF infrastructure programs, and large HIPAA cloud architectures routinely scope into the low six figures.
See build engagements →Managed Compliance Retainer
Ongoing engagement for teams that want Stonebridge to continue operating, evolving, or supporting the infrastructure after the build. Common during regulatory transitions (HIPAA Security Rule 2026 implementation, FedRAMP 20x migration, HITRUST CSF v11.7 updates) and for teams that prefer founder-delivered continuity over building an internal compliance engineering function from scratch. Same engineer who scoped the original build continues the work.
- Monthly recurring engagement
- On-call for compliance incidents
- Quarterly drift reviews and evidence audits
- Framework update support as regulations evolve
- Continued infrastructure evolution as your business scales
- Founder-delivered continuity (same engineer)
Reference implementations and open resources.
The framework is documented through a growing library of reference implementations, checklists, and tooling. These artifacts make the methodology actionable for teams who want to apply it themselves before considering an engagement.
What's published, and what's shipping.
Field Notes from active engagements are available now. Reference checklists, Terraform modules, and the HIPAA 2026 compliance gap calculator are shipping through 2026 as the framework's open-source surface area expands.
Field Notes from active engagements
Six in-depth posts covering HIPAA CI/CD architecture, parent/child pipeline patterns, audit checklist mapping, and common failure modes. Cited by Google AI Overview and Bing AI.
Read Field Notes →The HIPAA CI/CD Audit Checklist
47-control reference mapping every HIPAA Security Rule technical safeguard to a specific pipeline touchpoint, the auditor's question, and the architectural fix. PDF format.
FedRAMP 20x KSI Readiness Checklist
61 Key Security Indicators mapped to evidence types, automation tools, and validation patterns. The reference document for CSPs preparing for FedRAMP 20x Phase 3.
EDI Terraform module library
Open-source reference Terraform modules implementing the four principles. Plan-time policy gates, evidence pipelines, retention-locked logging, identity federation. Apache 2.0.
HIPAA 2026 Compliance Gap Calculator
Interactive web tool. Input current infrastructure state, output gap analysis against the prescriptive HIPAA Security Rule 2026 mandates. Free to use.
Reference pipelines on GitHub
Working GitLab CI/CD, GitHub Actions, and Argo CD reference implementations of HIPAA-aligned pipelines. Apache 2.0 licensed.
