The Fractional CTO Playbook
Templates and checklists I actually use in Fractional CTO engagements, technical due diligence, and infrastructure hardening. Free to use — attribution appreciated.
Most engineering problems are not new. They've been solved a thousand times — the failure is that nobody wrote the solution down where the team could find it at 3am.
These are the working documents from my practice: the due diligence report structure I hand to investment committees, the NIS2 readiness assessment I run for SMEs, the runbook for the day everything goes wrong, and the templates I use to make architecture decisions out loud.
No theory. No frameworks invented for a deck. What I use, week in, week out.
| # | Document | Use it when | Action |
|---|---|---|---|
| 01 | Technical Due Diligence Report Template | You're investing, acquiring, or joining — and need the truth about a system | View document → |
| 02 | NIS2 Readiness Checklist | A regulator, insurer, or enterprise client asks about your security posture | View checklist → |
| 03 | The Bad-Tuesday Runbook | Production is down and the first hour decides the month | View runbook → |
| 04 | ADR Template + Engineering Health Scorecard | You need decisions documented and team health measured, not felt | View templates → |
Technical Due Diligence Report Template
Structure of a one-week, fixed-scope technical DD. Written so a non-technical investment committee can act on it. Verdict first, evidence second, jargon nowhere.
1. Executive Summary — read this page only if you read one
Verdict: PROCEED / PROCEED WITH CONDITIONS / DO NOT PROCEED
| Question | Answer | Confidence |
|---|---|---|
| Can this system hold real users at 10× current load? | [Yes / With work / No] | High / Med / Low |
| Can the current team maintain it without the founder? | [Yes / With hires / No] | High / Med / Low |
| Is the security posture acceptable for the sector? | [Yes / Gaps listed / No] | High / Med / Low |
| Does the infrastructure cost match the financial model? | [Yes / 2× / 3×+] | High / Med / Low |
Three findings that matter most:
- [The finding that changes the deal]
- [The finding that changes the price]
- [The finding that changes the roadmap]
2. Repository Health
| Signal | Observed | Good looks like |
|---|---|---|
| Commit activity last 90 days | [Data] | Sustained, small commits |
| Test coverage (or evidence of testing culture) | [Data] | >60% on core, e2e on critical paths |
| CI/CD exists and gates deploys | [Data] | Failing build = no merge |
| Bus factor on core modules | [Data] | ≥2 people per critical path |
| Dependency hygiene | [Data] | Pinned, scanned, no known-critical CVEs |
| Secrets in history | [Data] | None; scanning in place |
3. Architecture
- What it is: [2 sentences, no diagrams needed]
- What breaks first at 10×: [specific bottleneck]
- Tech debt that is actually risk: [vs tech debt that is just ugly]
- Cloud exit cost / vendor lock-in: [assessment]
4. Team & Capability
- Who actually wrote the code (may differ from the deck).
- Who can operate it at 3am.
- The two hires the roadmap assumes — do they exist, and can they be hired in this market in this timeline?
5. Security Posture
Secrets management · dependency scanning · access control (MFA, least privilege) · logging & detection · backup/restore tested · incident process. Scored 1–5 each, evidence cited.
6. Infrastructure & Cost
Measured vs modelled run cost. The delta is never zero — the question is whether it's 10% or 300%.
7. The Three Uncomfortable Questions
- Infrastructure costing [x]× the model's estimate — why?
- The lead architect didn't write the code — who did, and where are they?
- The roadmap assumes hires that don't exist — what slips if they never arrive?
8. Red Flag Register
| # | Flag | Severity | Cost to fix | Found in |
|---|---|---|---|---|
| 1 | [Description of potential critical finding] | Deal-breaker / Condition / Watch | [Estimate] | Code / Team / Infra |
9. Recommended Conditions & First 90 Days
If proceeding: the 3 conditions to write into the term sheet, and the 5 actions for the first 90 days, in order.
Method note: I read code, architecture, team, and posture independently — and I ask the questions nobody asked in the pitch meeting. One week, fixed scope, written for your committee.
I perform this exact technical due diligence for investors, acquirers, and boards — in one week with a fixed scope.
NIS2 Readiness Checklist
Assessment run for essential & important entities under the EU NIS2 Directive. Score each item: ✅ done · 🟡 partial · ❌ gap. Any ❌ on items 1, 2 or 4 is a reportable gap.
- Written, board-approved security policies
- Annual review + after every significant incident
- Testing & effectiveness assessment in place
- Named owner (a person, not a department)
- 24h early warning capability to CSIRT
- 72h incident notification process
- 1-month final report workflow
- Incident log kept 3+ years (evidence for auditors)
- Due diligence on ICT vendors & suppliers
- Security requirements in procurement contracts
- List of critical suppliers maintained
- Data encrypted in transit and at rest
- MFA on all remote access and privileged accounts
- Key management documented (who holds what, where)
- Hardware-rooted protection for crown-jewel keys where feasible
- 3-2-1 backup rule implemented
- Restore tested and timed, at least quarterly
- At least one copy offline or immutable
- Complete inventory: servers, endpoints, SaaS, shadow IT
- Crown-jewel data identified and mapped
- Inventory owner and refresh cadence assigned
- Onboarding security training for all staff
- Phishing simulations at least annually
- Role-specific training for privileged users
- Management body formally briefed on risk (minutes exist)
- Responsibility for non-compliance assigned at board level
- Budget line for security exists and is spent
Scoring Matrix
| Score Range | Status | Required Action |
|---|---|---|
| 32–40 | Defensible posture | Keep evidence, review annually |
| 24–31 | Regulator risk | Gaps a regulator will find — fix within 90 days |
| <24 | Severe fine exposure | Fine exposure is real (up to €10M / 2% turnover for essential entities) — treat as a project, not a task |
Evidence Pack
Auditors believe documents, not meetings. Maintain: policies (current, dated, signed), incident log, training records, supplier due-diligence files, restore-test results, board minutes.
I run this assessment as a fixed-scope engagement — outcome: scored checklist, gap register, and a 90-day remediation plan your team can execute.
Get a full assessment, scored gap register, and a 90-day remediation roadmap.
The Bad-Tuesday Runbook
One page. Printed. Where the on-call person can find it at 3am without reading anything else. The first hour decides the month.
- Declare in [#incident channel] — template:
🚨 INCIDENT — [system] — [declarer] — investigating - Appoint Incident Commander (one person, decides; not necessarily the most senior)
- Assign Comms (customers/stakeholders — only voice out)
- What broke: users, data, or money? (pick the worst)
- When did it start (monitoring, not guesswork)
- Last change deployed? → candidate #1, consider rollback
- Recent config/credential changes?
Decision tree:
- Rollback available & safe? → do it. Fastest path to known-good.
- No rollback, fix identified? → fix forward with a second reviewer.
- No fix, data at risk? → graceful degradation: shut the doors, save the data.
- Security incident? → isolate first (pull network), investigate after.
- RPO/RTO for this system: [from inventory] — decision made against these numbers, not panic.
- Mitigation applied? Verify with monitoring, not hope.
- Status update #1 sent (every 30 min while red): what broke / what we know / next update at [time]
- Log timeline as it happens (who did what, when — future-you will need it)
- Post-mortem within 48h: timeline, root cause, the 5 whys, action items with owners
- Blameless: the goal is a better system, not a better scapegoat
- Update this runbook with what you learned
The numbers that must exist BEFORE Tuesday
| System | RPO (max data loss) | RTO (max downtime) | Rollback? | Backup restore last tested |
|---|---|---|---|---|
[Core API / DB] |
[e.g. 15 mins] | [e.g. 1 hour] | [Yes/No] | [Date] |
[Payment Gateway] |
[e.g. 0 mins] | [e.g. 15 mins] | [Yes/No] | [Date] |
*If this table is empty, that is the finding.*
Included in every infrastructure hardening engagement. Want it built for your systems? The first call is twenty minutes.
I audit systems, establish RPO/RTO metrics, and train teams before emergency hits.
ADR Template + Engineering Health Scorecard
Two tools that make engineering measurable instead of vibes: decisions written down, and team health scored on evidence.
Part A — Architecture Decision Record (ADR) Template
ADR-[number]: [short imperative title, e.g. "Use event-driven jobs for billing"] Status: proposed | accepted | deprecated | superseded by ADR-[n] Date: [YYYY-MM-DD] · Deciders: [names] Context [What forces are at play? Technology, cost, team, regulation, deadline. 3-6 bullets.] Decision [One sentence. If you can't write it in one sentence, you haven't decided yet.] Alternatives considered 1. [Option] — rejected because [concrete reason] 2. [Option] — rejected because [concrete reason] Consequences Positive: [what gets easier] Negative: [what gets harder — honest, or this document is marketing] Review Revisit when: [trigger, e.g. "volume >10×" or "team grows past 12 engineers"]
Worked example (anonymized):
ADR-007: Run billing as asynchronous jobs, not in the request path Status: accepted · 2024-03-11 · Deciders: CTO, lead backend Context - Payment webhook latency spikes block checkout threads - Stripe retries duplicate charges if response >30s - Team of 4; nobody to own a queue cluster at this stage Decision: Billing runs as idempotent async jobs behind a queue; request path only enqueues. Alternatives 1. Bigger instances — rejected: cost scales linearly with traffic, fixes nothing 2. Third-party orchestration SaaS — rejected: $4k/mo, new vendor dependency Consequences + Checkout p99 drops under 400ms; retries become safe - Exactly-once semantics now a code concern; monitoring required Review: revisit at 1M events/day or if queue lag >2min sustained.
Part B — Engineering Health Scorecard
Run quarterly. Score 1–5 with evidence, not impressions. Trend matters more than level.
| Dimension | 1 looks like | 5 looks like | Score | Evidence |
|---|---|---|---|---|
| Deploy confidence | Coin flip, manual, feared | Automated, boring, reversible | [ ] | [Evidence logged] |
| Observability | Users report outages | We detect before users | [ ] | [Evidence logged] |
| Bus factor | One person = system | Every critical path has 2+ | [ ] | [Evidence logged] |
| Tech debt handling | Invisible until it bites | Register exists, budgeted, burning | [ ] | [Evidence logged] |
| Incident culture | Blame & silence | Blameless post-mortems, actions done | [ ] | [Evidence logged] |
| Security basics | Passwords in chat | MFA, least privilege, patching cadence | [ ] | [Evidence logged] |
| Delivery predictability | Estimates fiction | Velocity measured, scope traded | [ ] | [Evidence logged] |
| Onboarding | Weeks of guessing | New hire ships in week 1 | [ ] | [Evidence logged] |
Reading: any dimension at 1–2 with a "no evidence" column = this quarter's project. Two consecutive quarters flat at 3 = the system is quietly rotting.
Templates I use in Fractional CTO engagements. Want them applied to your team?
I work inside your team to bring order, velocity, and measurable technical maturity.