Advanced Business Tech #TDD-report #RAG-rating #due-diligence #M&A

Due Diligence Report Language

5 exercises — complete the technical due diligence language module: TDD report structure and audience calibration (executive summary vs technical findings vs risk register), RAG status written communication patterns (condition precedent, material liability, manageable risk), risk register field vocabulary (risk ID, likelihood × impact, residual risk, owner), formal recommendation language and professional liability hedging, and verbal due diligence delivery (technical red flag communication, handling CTO pushback, professional neutrality).

0 / 5 completed

TDD report language quick reference

Report structure: Executive summary (VC/board, business language, $) → Technical findings (CTO, technical terms) → Risk register (integration team, tabular, actionable) → Remediation roadmap (phased plan).
RAG writing: Red = no hedging ("condition precedent / we recommend against"). Amber = risk + path ("manageable / recommend allocating $X"). Green = concise and affirmative ("no action required / within expected parameters").
Risk register fields: ID, domain, description, RAG, likelihood, impact, score, current mitigation, residual risk, recommended action, owner, target date. Owner + date = actionability.
Recommendation register: "We recommend" (advisory) → "We strongly recommend" (elevated) → "Conditional on remediation of" (near-blocking) → "Condition precedent" (Red/blocking).
Verbal pushback: Acknowledge + invite evidence + hold position. "Our current rating stands based on evidence available during the assessment window."

1 / 5

The TDD lead is structuring the final report. She explains to a junior assessor: "The biggest mistake in TDD reporting is writing everything in one voice for one audience. The VC partner reading the executive summary does not want to read the same document as the CTO reviewing the technical findings. And the deal team working with the risk register needs something different from both."

How is a TDD report structured, and how does audience calibration affect how findings are written?

The executive summary is the most important section because it's the only one most decision-makers will read fully. If the executive summary doesn't land — if it's too technical, too vague, or doesn't connect to financial stakes — the entire TDD engagement fails to influence the deal.

TDD report structure and audience mapping:

Section	Audience	Language register	Purpose
Executive summary	VC/PE, CEO, CFO, board	Business English; no technical jargon; dollar amounts	Decision: proceed / adjust / withdraw
Technical findings	CTO, tech leads, advisors	Technical; precise; evidence-based; architecture diagrams	Validate findings; plan remediation
Risk register	Deal team, integration managers	Structured; tabular; action-oriented	Track and execute post-acquisition
Remediation roadmap	CTO, integration team, board	Project plan; effort + cost + timeline per phase	Budget and execute debt remediation

Audience calibration examples:
• For the VC partner: "The company's authentication module has a bus factor of 1 and carries three unpatched CVEs rated Critical. Combined risk: $150,000 remediation and elevated security liability. This is our primary Red finding."
• For the CTO: "The authentication module (auth-service/src/jwt/) relies on a single senior engineer for maintenance. JWT library version 3.1.2 has three active CVEs: CVE-2023-xxxx (CVSS 9.1), CVE-2023-yyyy (CVSS 8.8), CVE-2023-zzzz (CVSS 7.6). Immediate recommended action: dependency upgrade to 4.x.x and knowledge transfer programme."

Key vocabulary:
• Executive summary — the 2–4 page opening section of a TDD report written for non-technical decision-makers; maps technical risk to financial outcomes; the deal committee's primary reading
• Audience calibration — the practice of writing different sections of the TDD report in the appropriate register for their intended reader; the same finding is described in business terms for investors and in technical terms for engineers
• Technical findings — the detailed domain-by-domain section written for technical stakeholders; uses precise technical vocabulary and cites evidence (code snippets, metrics, architecture diagrams)

2 / 5

The TDD lead explains the rating system at the start of a debrief meeting: "Every finding in this report has a RAG status — Red, Amber, or Green. And I want to be clear: the words I use to communicate each status in the written sections are precise and intentional. There's a material difference between how I write a Red finding and how I write an Amber finding — and that difference matters for the deal."

How is RAG status communicated in the written sections of a TDD report, and what formal language corresponds to each level?

The language discipline in RAG communication is important because TDD reports are legal documents that may be referenced in deal negotiations, disputes, or regulatory inquiries. Imprecise language ("we have some concerns about...") can be interpreted as either Amber or Red depending on the reader. Precise language removes ambiguity.

RAG communication language patterns:

RAG	Hedge level	Sentence openers	Deal signal
Red	None — clear and direct	"We recommend against...", "This is a condition precedent...", "We cannot recommend..."	Stop / price adjust / remediate before close
Amber	Moderate — risk acknowledged, path given	"This is a manageable risk...", "While material...", "We recommend allocating..."	Proceed with remediation plan and integration budget
Green	None — concise and affirmative	"No action required...", "Classified as Green...", "Within expected parameters..."	Proceed; standard monitoring only

RAG language in context:
• Red: "The authentication library carries three unpatched critical CVEs. This is a condition precedent: the transaction should not close with these vulnerabilities in production. We recommend this as a pre-close mandatory action with a defined completion date in the sale and purchase agreement."
• Amber: "The codebase carries a technical debt ratio of 22%. While material, this is a manageable risk with a clear remediation path. We recommend allocating $180,000 in the Year 1 budget for a dedicated debt reduction programme expected to complete within 9 months."
• Green: "CI/CD pipeline maturity is Green. Automated testing, SAST, and deployment pipelines are all in place and functioning above industry benchmark for a company of this stage."

Key vocabulary:
• Condition precedent — a contractual condition that must be satisfied before a transaction can close; in TDD, a Red finding triggers a condition precedent: the finding must be remediated before deal completion
• Material technical liability — a technical risk finding of sufficient magnitude to affect deal valuation, structure, or viability; the threshold above which a finding moves from Amber to Red
• Without prejudice to — formal qualifying language meaning the statement is made without admitting or conceding anything in any legal proceeding; used when making hedged financial estimates in reports

3 / 5

The integration manager asks for a briefing on the risk register format: "I need to understand every column in this table, because my team is going to live in this document post-close. Every finding needs to have an owner, a deadline, and a clear status. Let me know exactly what each field means."

What are the components of a TDD risk register and what does each field communicate?

The risk owner and target resolution date fields transform the risk register from a report document into a management document. Without an owner, every risk is everyone's responsibility (meaning no one's). Without a date, "we'll fix this" means nothing. These two fields are what make the risk register actionable post-acquisition.

Risk register field vocabulary:

Field	Purpose	Example entry
Risk ID	Unique reference for meetings and updates	CODE-003
Description	Specific, evidence-based risk statement	"Auth module: 11% test coverage, 3 critical CVEs in jwt@3.1.2"
RAG / Likelihood / Impact	Severity rating; prioritisation input	Red / High / High → Risk score: Critical
Current mitigation	What exists now; determines residual risk	"No current mitigation. CVEs unacknowledged in backlog."
Recommended action	Specific next step with cost/effort	"Upgrade jwt to 4.x.x immediately; add test coverage to 70% over 2 sprints: ~$18K"
Owner / Target date	Makes risk register actionable; creates accountability	CTO / 30 days post-close (CVE fix); 60 days (coverage)

Risk register language in a meeting:
• "CODE-003 is a Red finding. Likelihood is High — the CVEs are actively being exploited in the wild. Impact is High — the authentication module is the entry gate for all users. Residual risk with no mitigation is Critical. The recommended action is immediate: dependency upgrade before close is a condition precedent in our recommendation."

Key vocabulary:
• Risk score — a derived priority metric, typically Likelihood × Impact; used to sequence remediation when multiple items compete for engineering capacity
• Residual risk — the risk level that remains after applying existing and proposed mitigations; always stated after "given that we implement X and Y, the residual risk is Z"
• Risk owner — the named role responsible for implementing the recommended action; without an owner, risks are tracked but not actioned; critical for integration planning

4 / 5

The TDD lead drafts the recommendations section. She shows a junior assessor two versions of the same recommendation and asks: "Which version would you rather sign your name to if this became a legal document?"

Version A: "The team should probably think about fixing the authentication issues before the deal closes."
Version B: "We recommend that remediation of findings AUTH-001, AUTH-002, and AUTH-003 be completed prior to close and evidenced by an independent security review as a condition of the transaction."

What makes formal TDD recommendation language effective, and what hedging vocabulary is used to manage professional liability?

The difference between "should probably think about" and "is a condition of our recommendation" is not stylistic — it is the difference between a suggestion and a professional opinion that can drive deal renegotiation. TDD recommendations are advisory instruments that affect million-dollar transactions. The language must be precise enough to be actionable and hedged enough to be defensible.

Recommendation language register:

Strength	Language	When to use
Advisory	"We recommend / We suggest / We advise"	Amber findings; beneficial but not blocking
Strong	"We strongly recommend / This is a priority recommendation"	High-Amber findings; elevated urgency
Conditional	"We advise against proceeding unless / Conditional on remediation of"	Amber-Red findings; near-blocking
Blocking	"This is a condition precedent / We cannot recommend proceeding as currently structured"	Red findings; deal-breaker level

Vocabulary for professional liability management:
• "This report is based solely on artefacts, interviews, and access provided during the assessment period of [dates]. We have not independently verified all representations made by the target company."
• "Cost estimates are indicative only and subject to detailed scoping by an engineering team with full access to the codebase."
• "This report is prepared exclusively for [Acquirer] and may not be relied upon by any other party."

Key vocabulary:
• Condition precedent — a requirement that must be satisfied before a contractual obligation becomes binding; in TDD, Red findings are typically expressed as conditions precedent to close
• Evidence requirement — a specification of what constitutes proof that a recommendation has been actioned; e.g., "evidenced by an independent security scan" rather than "team confirms it was fixed"
• Professional liability hedge — qualifying language that bounds the scope of the report's reliability (e.g., "based on information made available," "as of assessment date"); standard in all professional advisory documents

5 / 5

At the final debrief, the TDD lead presents findings verbally to both technical and non-technical stakeholders in the same room. The target company's CTO is present and begins to push back on a Red finding: "I think you've overstated the criticality of that authentication module — our security team reviewed it internally and disagrees with your CVE severity rating."

How does a skilled TDD assessor deliver findings verbally, handle technical pushback from the target company, and maintain professional neutrality while standing behind a Red finding?

The phrase "our current rating stands based on evidence available during the assessment window" is one of the most important professional phrases in verbal TDD communication. It does three things simultaneously: it maintains the finding without being confrontational; it signals that new evidence would be considered; and it establishes that the assessor's obligation is to the evidence, not to the preferences of the target company.

Verbal TDD delivery patterns:

Situation	Phrase type	Example
Opening a Red finding	Context-first, then verdict	"Our most significant finding relates to [area]. This is rated Red, meaning we do not recommend proceeding without remediation."
Bridging technical and business audience	Layer: business first, then offer depth	"In business terms, this means X. For those who want the technical detail — [pause and check room]."
Handling pushback	Acknowledge, invite evidence, hold position	"I understand the disagreement. Our rating stands based on the evidence available. If there are compensating controls we weren't shown, I'd welcome those being shared."
Avoiding alarmism with Amber	Risk + path in same sentence	"This is Amber — a real risk, but one with a clear path to resolution within 6 months and a defined cost."

Professional neutrality phrases:
• "Our obligation is to the evidence, and the evidence supports a Red rating for this finding."
• "We're not here to block the deal — we're here to ensure both parties have a clear picture of what they're transacting."
• "I'd welcome any additional documentation that could change this assessment. What we have assessed, as of this engagement, supports the rating as written."

Key vocabulary:
• Technical red flag communication — translating a technical finding into language that conveys its business significance to non-technical decision-makers; the art of saying "the authentication module has three critical CVEs" in a way that a CFO understands as "anyone could potentially take over any user account"
• Professional neutrality — the assessor's obligation to report findings based on evidence rather than stakeholder preferences; maintained through evidence citation, conditional invitation to provide additional information, and clear statement that the rating stands until new evidence is provided
• Compensating control — a security or operational measure that mitigates an identified risk without directly remedying it; claiming a compensating control in response to a Red finding requires evidence; the assessor has an obligation to verify rather than accept at face value