Governance Audit
The system behind the deliverable.
Audited, in writing.
Independent audit of how technology decisions get made, escalated, and recorded, so the board sees the system, not just the output.
What this is
One layer up from the artefact.
Most tech audits look at the artefact: the code, the platform, the data. A governance audit looks one layer up: how the decisions that produced the artefact get made, who owns them, and how they hold up under change or pressure.
- Process-focused. We observe the decision rhythm: steering meetings, design reviews, ADRs, escalations. Not just the deliverables they produce.
- Independent. Same 12-month rule as our TDD: we do not bid for the remediation work we recommend.
- Evidence-based. Decision logs, RACI documents, meeting minutes, change records. Each finding cites the artefact and the person who confirmed it.
- Actionable. The remediation roadmap names a decision-owner per item, not just an action. Findings turn into commitments, not aspirations.
Some dimensions sound like TDD chapters. The question changes.
TDD asks: does the artefact meet the standard? (Is this codebase secure? Is this architecture sound? Is this test coverage acceptable?)
Governance Audit asks: does the process around the artefact hold up under change? (How are security decisions reviewed? Who signs off on architecture changes? What is the test policy and is it enforced?)
One snapshots the asset. The other audits the system that produces it.
What we look at
Ten dimensions. Tuned to company stage.
The framework is informed by CMMI maturity models and refined over a hundred-plus engagements, with AI & Data Governance added as a tenth dimension in 2024 to cover model risk, prompt governance, and EU AI Act readiness. The same ten dimensions cover a bootstrapped €2m SaaS and a €50m PE deal; the maturity bar and question depth change, not the surface area.
What the ten dimensions cover
Architecture, Engineering Practices, Infrastructure & DevOps, Security, Testing - the IT delivery backbone.
Governance (meta) - decision rights, escalation paths, board reporting cadence.
People Pulse, Skills, Turnover - the human side a board needs visibility into.
AI & Data Governance - model risk, prompt and evaluation, RAG lineage, EU AI Act readiness.
Maturity scoring runs L1 Ad-hoc to L4 Optimized, calibrated by stage. A scale-up is not graded against an enterprise CMMI Level 4 bar.
Sample coverage: anonymized scale-up engagement. Inner ring = L1, outer = L4. AI & Data Governance at L1 is typical: AI in production, no policy.
Architecture
ADR usage and lifecycle, design review cadence, architecture forum participation, deviation handling, technical debt visibility at architecture level.
Engineering Practices
Definition of Ready / Done adoption, code review policy and enforcement, branching strategy, refactoring policy, pairing and mob practices.
Governance (meta)
Steering committee composition and cadence, decision rights documented (RACI), escalation paths, board-level technology reporting, governance retros.
Infrastructure & DevOps
Change Advisory Board or equivalent, deployment approval flow, production access policy, monitoring and alerting policy, incident-to-postmortem cadence.
People Pulse
Engagement survey cadence, 1:1 rhythm and visibility, retrospective participation, morale signals tracked, action loop from feedback to change.
Security
Threat modeling cadence, vulnerability review process, incident drill frequency, secure-by-default policy, security training program, third-party risk review.
Skills
Skill matrix maintenance, learning path definition, performance review process, knowledge transfer policy, internal mobility framework.
Testing
Test policy (unit, integration, E2E split), quality gates in CI, regression strategy, environment management, exploratory testing cadence.
Turnover
Attrition tracking and benchmarking, exit interview practice, knowledge handover policy, succession planning, key-person risk register.
AI & Data Governance
AI usage policy, model risk management, prompt and evaluation governance, data lifecycle for AI (lineage, RAG corpus, PII in prompts), AI in the dev loop, EU AI Act readiness.
How it runs.
Four phases. Three to four weeks end to end, depending on stakeholder availability and how mature the steering rhythm already is when we start.
Kickoff & doc review
- NDA and access
- Stakeholder map
- Doc request: RACI, decision logs, steering minutes, risk register, change records
Interviews & observation
- 8-15 stakeholder interviews
- Observe one steering meeting
- Observe one architecture or design review
Synthesis & scoring
- Per-dimension maturity (L1-L4)
- Evidence map: each finding cited to artefact + person
- Draft report & remediation roadmap
Readout & Q&A
- 60-min executive readout
- Final report delivered
- 30-min Q&A within 2 weeks
How dimensions get scored
Four maturity levels.
Each of the ten dimensions sits on a four-level maturity scale, calibrated to expectations at your stage. Individual findings under each dimension support the level assigned, with evidence cited (artefact, date, person).
Ad-hoc
Decisions happen, but are not consistently traced. No defined process. Outcome depends on individual heroics.
Defined
Process is documented. Practice is inconsistent. People know what should happen; what actually happens varies.
Managed
Process is consistent, measured, reviewed. KPIs visible. Deviations get flagged. Most scale-ups at maturity sit here.
Optimized
Measured and adapted. Continuous improvement loop active. Process evolves with feedback. Rare outside large engineering orgs.
Deliverables
What you walk away with.
Governance report
Around 30 pages. Per-dimension maturity (L1-L4) with evidence cited per finding, executive summary that stands alone for non-technical readers.
90-day remediation roadmap
Prioritized items with a named decision-owner per item, dependency map, must-have / should-have / nice-to-have tiers. Built so the next steering meeting can pick it up.
Executive readout + Q&A
60-minute live walkthrough with the executive team or board. 30-minute Q&A follow-up within two weeks for items the team needs to take back.
Who calls us for this
Three trigger moments.
Post-incident
An outage, a breach, a missed release. The artefact got fixed. The board wants assurance the system that produced the failure is sound, not just the patch.
Pre-fundraise or pre-acquisition
Series B+ raise or M&A. The lead investor will ask governance questions. The seller wants the answer in writing before the buyer's TDD lands.
Scale-up at the inflection
30 to 100 FTE. Ad-hoc decisions are hardening into "the way we do things." The CTO knows the process is fraying but is too inside it to see the fix.
Pricing
Scoped to organization size.
Fixed-fee engagements. Scoping call and proposal are not billable. Final scope confirmed in writing before kickoff.
10-30 FTE, single-product platform, one steering rhythm. 3 weeks.
30-100 FTE, multi-product or multi-region, several steering rhythms to observe. 3-4 weeks.
PE portcos (per-company or rolled-up), regulated industries, group-level governance. 4 weeks, onsite component if needed.
Travel billed at cost where applicable. Governance Retainer available post-engagement for ongoing oversight.
Common questions
Six things buyers ask first.
How is this different from your Technical Due Diligence?
TDD audits the artefact: code, platform, data. Governance Audit audits the system that produces the artefact: how decisions get made, who owns them, how they get reviewed. Some dimensions overlap by name (Architecture, Security), but the question changes. TDD asks "does the artefact meet the standard?". Governance Audit asks "does the process around the artefact hold up under change?".
We already have a process. Will you just tell us it's wrong?
No. The audit benchmarks your process against industry maturity models (CMMI-derived), then identifies the gaps that matter for your stage. A scale-up does not need a regulated-enterprise governance stack. The report is calibrated to size, sector, and risk appetite.
What if our existing CTO feels threatened?
The audit is framed as a tool for the CTO, not against. We interview the CTO first, scope the audit with them, and present findings collaboratively. The output is a remediation roadmap the CTO co-owns. If the CTO is the bottleneck, that is a finding the board needs, but the audit is not designed as a performance review.
Remote or onsite?
Default remote, document-first. We travel for kickoff, observation of a steering meeting, or readout when the engagement warrants it.* Stakeholder interviews are video calls, recorded with consent.
* Travel and accommodation are billed at cost to the client.
How does the report get used downstream?
Three common uses: (1) board briefing, where the executive summary stands alone for non-technical readers; (2) remediation backlog, where the roadmap with decision-owners per item feeds directly into engineering planning; (3) pre-deal disclosure, where selling-side teams use it to show the buyer a governance position before TDD.
What if we want you to also implement the remediation?
Same independence rule as TDD: we do not bid for implementation of the governance we recommend within 12 months. The remediation roadmap is owned by your team or by a separate implementation partner. The Governance Retainer is the one exception: ongoing oversight, not implementation.
Ready to scope
One scoping call.
Fixed proposal in 48h.
Email us a few lines about the trigger. We reply within 24h, Monday to Friday.
- Org size, sector, and stage
- What prompted the call (incident, raise, scale)
- Anything you already know is amber or red