RBAC & SoD enforcement
Role-modelled to your real org structure, with segregation-of-duties enforced at the policy layer, not at the application layer.
09 — Compliance & risk
Compliance and risk engineering — the controls your auditor will look at first.
Compliance is most expensive when it’s retrofitted. A platform built without RBAC, immutable logging or data residency has those layers added in the run-up to SOC 2 — usually at 3x the cost of building them in from the start. We do the second.
FCA · UK CFPB · US OSFI · Canada
01 — Problem
Where compliance & risk builds usually go wrong.
Compliance engineering is the part of platform-building that’s easiest to defer and most expensive to retrofit. RBAC bolted on six months in tends to be inconsistent. Immutable audit logging added before SOC 2 tends to be incomplete. Data residency added before a Canadian / Quebec deployment tends to be partial.
What works is treating compliance as platform capability, not as a project. RBAC is the access model from day one. Immutable logging is the system-of-record from day one. Data residency is configurable per-customer from day one. Evidence pipelines run continuously, so the next audit is a query, not a quarter of work.
We build this directly into the platform. And we re-engineer it into platforms that didn’t have it from day one — though that’s always the more expensive path.
02 — What we build
End-to-end, audit-ready, in production.
Immutable audit logs
Event-sourced, retention-policy-aware, queryable — built as the platform’s system-of-record, not a side channel.
Data residency controls
Region-pinned storage, customer-by-customer — with the operational tooling to verify residency continuously.
Incident & vulnerability management
Runbooks, on-call, regulator-notification workflow — with the audit trail to evidence response timeliness.
Pen test & remediation
Coordinated annual testing, remediation pipelines and finding-to-fix workflow with full SLA tracking.
Threat modelling
STRIDE-led threat modelling integrated with sprint planning — so high-risk changes are reviewed before they ship, not after.
Encryption & key management
KMS-backed encryption, customer-controlled keys where required (e.g. Canadian programmes), key-rotation automation.
SOC 2 / ISO 27001 prep
Controls mapping, evidence pipelines, auditor liaison — and the platform engineering that makes the audit a query not a project.
03 — Patterns
Build patterns we ship from.
Audit-aware platform foundation
RBAC, immutable logs and data residency as platform capability from day one — not retrofit before SOC 2.
AWS IAM / KMSPostgres event-sourcingTerraform
Controls-as-code repository
Every control documented as code, version-controlled, and mapped to the framework requirements it satisfies.
Terraform CloudGitHub ActionsInternal controls registry
Live evidence dashboard
Auditor- and regulator-facing dashboard showing current control state, with drill-down to underlying evidence.
Vanta / DrataInternal evidence aggregatorLooker / Metabase
Incident response playbook + tooling
Runbooks, paging, regulator-notification workflow and post-incident review — with audit trail throughout.
PagerDutySlack workflowsInternal incident ledger
04 — Regulations
What this work has to comply with.
GlobalSOC 2 Type IIGlobalISO 27001GlobalPCI DSS v4.0CAOSFI Guideline B-13USFFIEC IT Examination HandbookEUDORA-equivalent (UK incoming)GlobalGDPR Art. 32
05 — Stack
What we build with.
Controls & evidence
VantaDrataInternal controls registrySnyk
Observability & security
DatadogAWS CloudTrailOpenTelemetryAWS GuardDuty
Infrastructure & keys
HashiCorp VaultAWS KMSTerraform CloudGitHub Actions
06 — Recent build
From scattered controls to SOC 2 Type II audit-ready in 4 months.
A UK-and-Canada fintech had scattered controls across multiple teams, no continuous evidence pipeline and a SOC 2 Type II audit booked four months out. Their internal pre-audit assessment had flagged 67 controls without sufficient evidence.
We worked alongside their platform team for four months: built the controls-as-code repository, wired the evidence pipelines, retrofitted the parts of the platform that needed RBAC and audit-log work, set up the OSFI B-13 layer for the Canadian programme, and ran the auditor liaison.
The audit completed on the original schedule. The auditor’s report flagged 2 minor observations and 0 material findings — and crucially, the evidence pipelines are still running, so the Type II renewal next year is largely already done.
4 months
Pre-audit to audit-complete
67 → 0
Controls without evidence
2 / 0
Observations / material findings
07 — FAQs
Questions we get every time.
What does “audit-aware from day one” actually mean in code?
Three things present from the first deployment: (1) RBAC enforced at the policy layer (not built into application code), with segregation-of-duties as configuration not as exception-list; (2) an immutable audit log that’s the system-of-record for every regulated event, not a side-channel that engineering writes to inconsistently; (3) infrastructure-as-code so the “control” is the code, not the runbook. Get these three right at the start and SOC 2 becomes a query against existing evidence.
How do you map controls to evidence for SOC 2 efficiently?
A controls-as-code repository where every control declares the framework requirement it satisfies, the evidence type it produces, and where that evidence lives. The auditor’s request “show me evidence for control X” becomes a query against the evidence aggregator, not an email thread between engineering, compliance and the auditor. Vanta or Drata can be the front-end for this, but the underlying discipline is yours — they’re tools, not strategies.
What’s the right architecture for immutable audit logs at scale?
Event-sourced, append-only, retention-policy-aware. The platform writes audit events to an immutable ledger as the primary write path (not as a logging side-channel); reads happen against a derived projection optimised for the query patterns the audit team needs. Retention is policy-driven — the ledger knows which events fall under which retention rule and ages them out automatically. Plus a tamper-evidence layer so the ledger’s integrity is itself auditable.
How does OSFI Guideline B-13 change what we need to ship?
OSFI B-13 (Canada’s technology and cyber risk guidance) emphasises identity and access management, change management, vulnerability management, third-party risk, and operational resilience — all with continuous evidence rather than annual attestation. For Canadian programmes, this means the platform needs to evidence its control state continuously (not at audit time), have third-party risk integrated into change management (not a separate process), and have operational resilience capability (BC / DR / incident response) that’s tested and evidenced rather than documented.
Can you take a platform from no controls to SOC 2 Type II in under a year?
Yes, but only if the platform is in a state where controls can be retrofitted. The hardest cases are platforms built without clean separation of concerns, where adding RBAC and audit logging means changing application code everywhere. The easiest cases are platforms built with at least the platform / application separation right — control can be retrofitted at the platform layer without rewriting the application. Pre-engagement, we’ll do a 2-week assessment to identify which case you’re in and what the realistic timeline looks like.
— Adjacent practices
Most builds combine two or three.
Scoping a compliance & risk build?
Send us a few sentences. We’ll come back inside three business days with a credible delivery plan and a date.