How to Read a Defence-Tech Pitch Deck Like a Target Pack

Executive Summary

Investors, founders, and procurement leaders who evaluate defence-tech pitch decks are reading an artefact that was built to sell — not an artefact that was built to be stress-tested. A structured intelligence-analyst framework, borrowed directly from how operational J2 shops read a target pack, produces sharper judgements faster. This piece walks through the eight-layer read Iron Command Advisory applies inside investor due diligence engagements, adapted for a non-classified commercial context.

---

Why a target-pack framework, not a commercial-DD framework

Commercial due diligence is built for software-as-a-service categories where the buyer is a reasonable corporate mid-market actor, the product is purchased via credit card, and the risk is margin compression. None of that applies to defence-tech.

Defence-tech has a slow, procurement-committee buyer with political constraints. The product must survive adversarial testing. The risk is not margin — it's regulatory, reputational, and contractual. A commercial DD process built for SaaS will not catch the structural issues that kill defence-tech deals.

A target-pack framework, by contrast, is built to produce an actionable judgement about a complex object under conditions of incomplete information. That is exactly what a defence-tech pitch deck is.

The eight-layer read

Layer 1 — Capability claim: what does the product actually do?

The first question is always capability, and the first trap is vendor language that sounds like capability without being capability. "AI-enabled decision support." "Autonomous targeting." "Multi-domain integration." Translate every one of these claims into a specific operational task a user could complete. If you cannot state the task in operator language in one sentence, the capability claim has not cleared the first bar.

Red flags: category labels ("AI-enabled", "autonomous", "software-defined") without a specific user task. Demo videos that show the interface, not the decision. Spec sheets that describe the product, not the outcome.

Layer 2 — Adversarial behaviour: how does it fail?

Every serious defence system has a known failure mode in a degraded environment — jammed GPS, denied comms, sensor spoofing, contested EW, partial data. Ask the vendor how the product behaves in each. If the answer is "it performs normally" or "we haven't tested that yet," you are looking at a laboratory prototype with a commercial veneer.

Red flags: no adversarial test data, no degraded-environment testing, no Red Team engagement on record, no mention of failure modes in the deck.

Layer 3 — Procurement path: who buys it, via which framework, at what price?

"The MOD wants this" is not a procurement path. Ask: which specific framework (RM6200, CSS3, G-Cloud, DOS, direct award, DASA, DEFRA-adjacent schemes), which specific buyer inside MOD / DoD / NATO, which specific programme line, which timeline. A credible vendor can answer all four questions without hedging. An incredible vendor hedges on all four.

Red flags: vague buyer references ("the MOD", "the Pentagon", "NATO"), no specific framework named, no programme line, timelines that slide when pressed.

Layer 4 — Sovereignty & supply chain: where is the stack from?

For any AI-adjacent product, ask: where did the training data come from, which foundation model is the system dependent on, what's the fallback if that model is unavailable, where are the key contractors based, and what's the sanctions exposure. For any defence product at all, ask: how is classified handling managed, what's the cleared-staff footprint, and what's the IP jurisdiction.

A vendor selling "sovereign AI" who can't describe their upstream model dependency has no meaningful claim to sovereignty. A vendor selling "defence AI" whose primary engineering team is in a geography that MOD would flag hasn't thought about the procurement pass.

Red flags: training data provenance that can't be described, foundation-model dependency treated as not relevant, sanctions posture not mentioned, "sovereign" used as branding not substance.

Layer 5 — Competitive position: who else won the bid?

For any UK defence-AI claim, the Asgard programme reference matters. 26 companies won four-year contracts in January 2026 for digital decision-support — a mix of AI specialists (Anduril, Helsing), defence primes (QinetiQ, Leonardo), and platform integrators (Tekever). Any new AI-in-defence capability claim needs to survive direct comparison with at least one Asgard awardee. If the pitch doesn't reference them, the vendor hasn't done the competitive read.

Red flags: no competitor named, competitive comparison based on SaaS peers rather than defence peers, dismissal of established primes as "slow" without substantive differentiation.

Layer 6 — Cyber posture: what would a state actor find?

Every defence-tech vendor is a cyber target. State-sponsored interest in the funded cohort has demonstrably scaled in the last 18 months. Ask: what's your cyber posture, who ran your last penetration test, what's your supply-chain software security picture, what would a Russian GRU or PRC MSS-adjacent actor find in your public-facing infrastructure today.

A vendor who doesn't have a clear answer is going to fail a procurement security audit — if the procurement process reaches that stage at all.

Red flags: "we'll think about cyber once we're bigger", no SBOM, no recent pen test, no cleared staff even in senior engineering, public-facing attack surface that looks like a late-stage startup's rather than a defence vendor's.

Layer 7 — Founder & team: real defence pedigree or imported?

The Bessemer Defense Tech Advisory Board template is the market signal: ex-Lockheed CTO, ex-US Space Force CIO, ex-Air Force leadership. The bar for defence-tech advisors and founding teams is operational pedigree in classified or defence-adjacent environments. A CEO with ten years in consumer SaaS and no defence advisor pulled in is a vendor whose first procurement cycle will be painful.

A clean structural read is: does the team include someone who has operationally used a capability in this category, and does the advisory board include someone whose CV would satisfy a procurement security review.

Red flags: all-software-engineering leadership, no defence or intelligence advisor on cap table, no ex-military senior hire, advisory board that's mostly VC partners.

Layer 8 — Exit narrative: who buys this, and at what multiple?

The final layer is almost always under-thought in defence-tech decks. Who is the plausible acquirer — a UK prime, a US prime, a defence-tech scale-up, a diversified corporate — at what revenue level, at what multiple. "We'll IPO" is not a defence-tech exit narrative. "We'll be bought by [prime] once we're at £X of procurement revenue" is. If the founder can't state the exit thesis cleanly, the vendor is optimising for fundraise, not for eventual sale.

Red flags: no specific acquirer mentioned, IPO-only exit narrative, revenue multiples quoted from SaaS comparables rather than defence acquirers.

Using this framework inside a real decision

The eight layers are not a checklist — they are a sequence. A vendor that fails Layer 1 (capability claim) is not worth Layer 8 (exit narrative). A vendor that passes Layers 1-4 cleanly is a serious candidate; the remaining four layers determine investment terms and governance, not fit.

Inside Iron Command Advisory, we apply this framework in a written DD read — typically 10-15 pages, delivered 7-10 working days from kickoff — with confidence ratings per layer and a red-flag list surfaced against each. The output is not "is the company fundable" (an investor's question) but "does the capability claim survive an operator-grade read" (a prior question the investor needs answered before capital deployment).

Where the framework gets applied publicly, it's the same shape you see on any Iron Command comparison — sourced evidence, structured judgement, confidence-rated call.

---

What founders should take away

The single most valuable posture shift for a defence-tech founder reading this is: audit your own deck against Layers 1, 3, 4, and 5 before you walk into a serious investor meeting. Those four are where fundraise pitches fail most often. Layers 2, 6, 7, 8 matter but tend to surface later; Layers 1, 3, 4, 5 are the ones that end a first meeting badly.

Specifically:

• Translate every category-label claim into an operator task. Rewrite the deck until every "AI-enabled" appears alongside what the user actually does.
• State the procurement path specifically. Framework name, buyer, programme line, timeline. Vagueness reads as strategic weakness.
• Answer the sovereignty and supply-chain question before it's asked. Training data provenance, foundation-model dependency, sanctions posture. These are now first-meeting questions, not due-diligence-phase questions.
• Run your product against at least one Asgard awardee. Name them. Describe where you're better, where you're peer, where you're worse. Investors respect precision over bravado.

What investors should take away

The eight-layer framework is the shape of a sharp first-pass DD read. Use it as a fast filter before commissioning deep technical DD. Three practical recommendations:

1. Kill the deck in 30-45 minutes if Layers 1-4 don't clear. Further investment of time doesn't improve the read; it just anchors you to a story. A capability-claim failure at Layer 1 is a structural issue, not a polish issue.
2. Commission operator-grade reads separately from commercial DD. Commercial DD is built for SaaS. Defence-tech needs adversarial-environment and procurement-path reads that commercial DD won't catch. The cost of an operator-grade read is small relative to the cost of a failed procurement phase.
3. Prioritise Layer 4 in 2026-28. Sovereignty and supply-chain questions are shifting fastest — especially around upstream AI model dependency, US defence-classified status of foundation providers, and training-data provenance. A pitch that passed Layer 4 a year ago may not pass Layer 4 today.