Production Python, written by the engineer who designed the infrastructure.

The compliance findings live in the seam.

Regulated teams usually have an infrastructure vendor and an application team, and the gap between them is where audits go wrong. The architecture diagram says encrypted and scoped; the application logs a patient identifier at INFO, retries with a static credential, and writes a debug file to a bucket nobody classified.

Neither side is careless. The infrastructure engineer cannot see the code paths, and the application developer cannot see the control the code is supposed to satisfy. So the seam is inspected by nobody until an assessor inspects it.

We close that gap by writing both. The same engineer defines the boundary and writes the service that runs inside it, which means access patterns, logging, secret handling, and data flow are designed against the controls rather than discovered to conflict with them.

Six questions that tell you where you actually are.

Data problems are hard to name from the inside. These are the questions we ask on a first call, and the ones that predict how much work an engagement really is.

If more than two of these are uncomfortable, the data layer is your constraint:

• Q/01Could a new engineer ship a small change safely in their first week, or does it require someone who knows where the landmines are?
• Q/02Do your tests give you enough confidence to deploy on a Friday? If not, the suite is decoration rather than a safety net.
• Q/03When something breaks in production, do you find out from a dashboard or from a customer? Observability that only answers questions you anticipated is not observability.
• Q/04Are secrets injected at runtime, or are there long-lived credentials in environment files and CI variables nobody has rotated?
• Q/05Does any log line, error report, or debug artifact contain regulated data? This is the single most common finding we see in application code.
• Q/06Is there a service only one person understands? That is not a staffing problem, it is an architecture problem.

Write the application against the control.

Four decisions separate application code that survives an assessment from code that merely works. None of them slow delivery down; all of them are cheaper at design time than at remediation time.

Principle 1: Regulated data never reaches a log

Structured logging with explicit field allowlists rather than blocklists, and redaction enforced in the logging layer itself rather than left to developer discipline. Error reporters and crash handlers get the same treatment, because a stack trace with a request body attached is the most common way regulated data leaves a system unnoticed.

Principle 2: Identity flows through the call path

The caller's identity travels with the request rather than being replaced by a service account at the first hop. Without it, an audit log records that the API touched a record, not who asked it to, and access-control questions become unanswerable after the fact.

Principle 3: No long-lived credentials anywhere

Secrets are injected at runtime from a managed store, scoped to the workload, and rotated automatically. Static keys in environment files and CI variables are convenient for exactly as long as it takes for one to end up in a repository.

Principle 4: Tests are the evidence, not the ceremony

The test suite covers the control-relevant paths, not just the happy path: authorization boundaries, redaction, retention, and failure modes. When an assessor asks how you know access control works, a passing test that asserts it is a better answer than a paragraph describing it.

Six artifacts your team can own on day one.

A Software Build produces a defined set of deliverables, all shipped to your repositories with the tests and documentation your team needs to maintain it without us.

Five patterns that fail application audits.

These are the findings we see most often when application code is reviewed against a compliance boundary for the first time.

1. Logging the whole request object

   One logger.info(request) during debugging, shipped and forgotten, and now regulated data sits in a log aggregator with a different retention policy and a wider access list than your database. Allowlist fields at the logging layer so this cannot happen by accident.

2. Service accounts that erase the caller

   The API authenticates the user, then talks to everything downstream as one shared identity. Audit logs record that the service accessed a record but not who requested it, and the access-control story falls apart under questioning.

3. Production data in development

   Copying a production dump to a laptop to reproduce a bug expands your compliance boundary to every developer machine. Synthetic fixtures and a good seeding script cost a week once and remove the problem permanently.

4. Tests that assert the happy path only

   Full green coverage of the paths that work, and nothing asserting that an unauthorized caller is refused, that redaction fires, or that retention deletes. Those are the paths an assessor asks about.

5. Code that only one person can safely change

   Every team has the service nobody touches. It is treated as a staffing risk, but it is an architecture and documentation problem, and it becomes an availability problem on the day that person is unreachable.

Two ways to engage. Fixed scope, fixed price.

Teams with an existing codebase usually start with the assessment. Teams who know what they need built come straight to the build.

A representative engagement.

Client profile: healthcare platform on GCP with a compliance baseline it could not prove across a production fleet, and no tooling to check it. The work was application engineering in service of a compliance deadline.

What engineering leaders say after working with Stonebridge.

Frequently asked, directly answered.