Draft Due Diligence Request List S01

Skill: Draft Due Diligence Request List (Scenario 01)

1. Subject-matter triage

• Treat this as a target-specific diligence request list for a healthcare IT / SaaS acquisition, not a generic corporate records request.
• Read the provided materials first and use them to tailor requests to the target’s product, regulatory footprint, customer mix, data practices, and geographic operations.
• Surface the issues that are most likely to affect valuation, closing risk, integration burden, and post-closing remediation effort.
• If the materials reveal more than one operating geography, regulatory regime, product line, customer cohort, or contract renewal deadline, separate them in the request list rather than blending them into one general request.
• Before drafting, identify the principal diligence buckets that are actually implicated by the materials; if a bucket is not supported by the facts, omit or narrow it.

2. Failure modes the skill is correcting

• Producing a generic DDRL that could be used for any software company, instead of tailoring requests to the target’s healthcare workflows, data handling, customer concentration, and jurisdictional footprint.
• Failing to highlight the highest-priority diligence themes up front, leaving the client without an organized view of the principal risks.
• Collapsing distinct issues into one request category, which obscures what documents are needed and why they matter.
• Omitting specific requests for open-source usage, privacy/security controls, regulatory filings, tax nexus, or covenant enforceability where the materials suggest those issues are live.
• Missing time-sensitive contract expirations, renewal notices, change-of-control triggers, or other dated items that require immediate attention.
• Using vague requests that do not tell the target exactly what to produce.
• Drafting requests that are too broad to be actionable or too narrow to capture the likely diligence record.
• Failing to organize requests in a way that lets the diligence team follow the corporate, financial, technology, regulatory, tax, employment, and contracts workstreams efficiently.

3. Legal frameworks / domain conventions that apply

• Healthcare IT diligence should be structured around the product’s regulatory exposure, data privacy and security posture, contractual commitments, and operational dependencies.
• If the target handles protected or sensitive health-related data, request materials bearing on privacy, security, access controls, incident response, and vendor oversight under the applicable healthcare privacy and security regime, including HIPAA and the HITECH Act where relevant.
• Open-source diligence should ask for the inventory of components, license terms, and integration method so counsel can assess whether any copyleft or disclosure obligations may attach under common open-source licensing practices.
• Tax diligence should test for filing positions, nexus, and registration consistency across jurisdictions where the target sells, deploys, or otherwise operates; if the materials suggest operations in more jurisdictions than return filings, request the analysis and history.
• Restrictive covenant diligence should be organized by governing law and ask for the company’s basis for enforceability, because enforceability varies by jurisdiction and may be affected by statutory or common-law limits.
• Contract diligence should focus on customer, vendor, and channel agreements that are material to revenue, service delivery, integration, or transition risk, with special attention to renewal windows, termination rights, change-of-control provisions, and assignment restrictions.
• Corporate records should support authority, capitalization, governance, and ownership verification through charter documents, equity records, consents, and board materials.
• Employment diligence should capture offer letters, invention assignment, confidentiality obligations, non-competes where used, contractor status, and classification risk.
• Regulatory diligence should request product approvals, notices, correspondence, complaints, audits, and investigations if the target operates in a regulated healthcare or software-adjacent environment.
• Legal propositions in the request framing should be anchored to the applicable rule or authority when the request is tied to a specific compliance regime or enforceability question, rather than stated as bare conclusions.

4. Analytical scaffolds

• Lead with a short executive summary that states the main diligence themes and why each theme matters for this target.
• Organize the request list by conventionally recognized diligence categories, with numbered requests under each category.
• Use category names that reflect the substantive workstreams: corporate, financial, tax, IP, technology, contracts, employment, regulatory, litigation, insurance, and facilities.
• Tailor the sub-requests to the facts in the materials: request the particular documents and explanations needed to confirm the concern, not a boilerplate catalog.
• Where a document set may exist in multiple versions, request the current version plus amendments, waivers, side letters, and related correspondence.
• Where the issue turns on how something is implemented, request both the paper record and the operational explanation.
• For open-source, request the specific component list, license notices, and the technical integration description needed to evaluate obligations.
• For tax, request the return history together with nexus and registration analyses that explain where the target believes it has obligations and why.
• For restrictive covenants, request the agreements grouped by governing law and the company’s assessment of enforceability for each group.
• For time-sensitive items, flag the request as urgent and tie it to the transaction timeline or a stated notice deadline.
• If the materials suggest a compliance gap, ask for both the current state and the remediation plan, including any internal assessment or external advice the company relied upon.
• When multiple jurisdictions or counterparties are implicated, separate them so the request list can be completed document-by-document.

5. Vertical / structural / temporal relationships

• Track how the product, the customer base, the hosting or deployment model, and the data flow relate to one another; requests should expose the path from product design to regulatory exposure.
• Tie intellectual property requests to technology and employment requests, because source provenance, contractor status, and assignment chain often interact.
• Tie tax requests to operating geography and revenue recognition patterns, because nexus and filing history often depend on where the business actually operates and sells.
• Tie contract requests to the transaction timeline, because renewals, expirations, notice periods, and assignment restrictions can affect closing and integration.
• Tie restrictive covenant requests to governing law and employee footprint, because enforceability varies by jurisdiction and by the role of the individual.
• Tie regulatory requests to the specific product modules or workflows in scope, not merely to the company as a whole.
• Where a risk depends on a sequence of events, preserve that sequence in the request wording so the response can be evaluated chronologically.
• If the target has subsidiaries, business lines, or operating locations, request records by entity and by location so the diligence team can map obligations and exposures accurately.

6. Output structure conventions

• Draft the output as a due diligence request list suitable for Word export.
• Begin with a concise executive summary of key diligence themes tailored to the target.
• Follow with numbered categories and numbered sub-requests under each category.
• Use clear, document-oriented request language: “Please provide…,” “Please identify…,” “Please describe…,” or “Please furnish…”
• Include urgent or time-sensitive requests as clearly flagged items within the relevant category.
• Keep requests specific enough that a target-side responder can locate the document or answer without guessing.
• For open-source and technology items, request both legal and technical materials where needed to assess licensing and integration.
• For restrictive covenants, request the agreements and the company’s enforceability analysis organized by governing law.
• For tax, request state- or jurisdiction-level filings, nexus analysis, and the basis for any filing position gaps.
• End with any practical follow-up requests needed to reconcile gaps, clarify missing records, or confirm whether additional schedules exist.