Why IT Diligence in Biotech Is Different

Generic technology due diligence looks at code quality, cloud costs, cybersecurity posture, and integration risk. All of that matters in biotech too. But biotech IT diligence carries a set of exposures that traditional SaaS or industrial diligence teams routinely miss, and those exposures can materially move valuation.

The first difference is regulatory. In biotech, a subset of IT systems support Good Practice (GxP) processes in laboratories, manufacturing, and clinical trials. Those systems are subject to FDA 21 CFR Part 11, EU Annex 11, ICH guidelines, and equivalent regimes worldwide. When your target’s LIMS was implemented in 2011 and never revalidated after three major upgrades, that is not a technical debt item. It is a compliance risk that could trigger warning letters, halt product release, and delay approvals.

The second difference is data integrity. Biotech companies generate the evidence that supports regulatory filings, patent claims, and safety monitoring. FDA and EMA have converged on the ALCOA+ principles — data must be Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, and Available — and enforcement is intensifying.4 CDER warning letters jumped 50 percent in fiscal year 2025, with 469 of 470 letters citing documentation or records management issues and 14 explicitly calling out data integrity violations including altered, deleted, or uncontrolled records.5 Any of those findings, discovered post-close, are the acquirer’s problem.

The third difference is the concentration of institutional knowledge. Biotech IT teams tend to be small, deeply specialized, and heavily reliant on a few individuals who understand how the LIMS talks to the ELN, how the Benchling instance was customized, or how the cell-line database was migrated from Access to PostgreSQL in 2018. When those people leave — and they often do post-acquisition — the acquirer inherits systems no one can maintain.

The fourth difference is cross-border data. Biotech targets frequently generate data on subjects and samples in the US, EU, UK, China, Japan, and increasingly India and Southeast Asia. That triggers HIPAA, GDPR, the UK Data Protection Act, China’s PIPL, Japan’s APPI, and a rapidly expanding patchwork of national privacy laws. Cross-border health data transfer restrictions can materially constrain the deal thesis if the acquirer intended to consolidate data platforms.6

The Sakara Digital perspective. The single most useful reframe for biotech IT diligence is this: you are not evaluating technology, you are evaluating a set of regulatory, operational, and financial liabilities that happen to be encoded in software. A senior IT diligence lead who has done ten SaaS deals but no biotech deals will produce a technically sound but strategically incomplete report. Bring domain expertise or accept that you are underwriting risk you cannot see.

The Eight IT Diligence Workstreams

A rigorous biotech IT diligence effort should be organized into eight parallel workstreams. Each has its own scope, evidence requirements, and typical findings. Running them in parallel — rather than as one monolithic IT review — accelerates the effort and produces cleaner findings that non-IT deal team members can act on.

Workstream 1

Validated Systems Inventory

Complete inventory of GxP and business-critical systems with validation status, last periodic review, and current change control posture.

Workstream 2

Data Integrity Assessment

ALCOA+ posture across critical records, audit trail coverage, spreadsheet inventory, and shared-credential findings.

Workstream 3

Cybersecurity Posture

NIST CSF or ISO 27001 mapping, penetration test history, incident log, NIS2 and FDA cyber-device readiness.

Workstream 4

Cloud & SaaS Contracts

Cloud spend trajectory, commitment status, egress exposure, MSA and BAA review, orphaned subscriptions.

Workstream 5

Data Privacy Compliance

HIPAA, GDPR, PIPL, APPI applicability, cross-border transfer mechanisms, DPIA coverage, subject rights posture.

Workstream 6

People & Key-Person Risk

Org chart, single-points-of-failure analysis, documentation depth, retention risk on named individuals.

Workstream 7

Technical Debt Quantification

Code and infrastructure debt inventory, ISO 5055 or SQALE-style principal estimate, remediation runway.

Workstream 8

Integration Complexity Scoring

System overlap map, data model divergence, identity federation feasibility, one-time and run-rate integration cost.

Validated Systems Inventory and GxP Data Integrity

The validated systems inventory is the foundation of biotech IT diligence. Everything else — cybersecurity, cloud, integration, valuation — depends on knowing which systems the target actually uses, which ones fall under GxP, and what state those systems are in.

What to inventory

At minimum, the inventory should capture every LIMS, ELN, MES, EBR, QMS, DMS, TMS, LMS, TrackWise or similar deviation-and-CAPA system, eCTD publishing platform, EDC, CTMS, pharmacovigilance database, and any custom applications supporting regulated processes. Business systems — ERP, CRM, HRIS, finance — matter for integration but sit in a different regulatory bucket.

For each system, the diligence team should collect: system owner, business process supported, GxP classification (GAMP category), validation status, date of last validation, date of last periodic review, current SOP references, vendor and version, hosting model, data classification, users and access model, integration points, and any known open deviations or CAPAs affecting the system.

The unvalidated-Excel problem

Red flag. In the 2025 FDA warning letter cohort, inspectors repeatedly found labs using unvalidated Excel spreadsheets as their primary tool for critical calculations and quality records.5 If a target’s diligence responses describe key stability calculations, batch release calculations, or specification decisions living in shared drives full of .xlsx files, treat this as a Priority 1 finding and escrow the remediation cost.

The unvalidated spreadsheet issue is so widespread that we treat it as a mandatory diligence step, not an optional one. Ask for the target’s spreadsheet inventory. If they do not have one, that is itself the finding. Sampling five to ten “critical” spreadsheets and evaluating them against 21 CFR Part 11 audit-trail, access-control, and validation expectations will reveal within a week whether the target has a manageable exposure or a systemic issue.

ALCOA+ posture

The ALCOA+ principles define what “good” data looks like in a regulated environment: Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available.4 A diligence-grade ALCOA+ assessment does not require auditing every system, but it should sample three to five high-risk systems and evaluate:

  • Attributable: Are there shared logins? Generic service accounts writing to GxP records? Configuration where “the system” is the recorded user?
  • Contemporaneous: Do audit trails timestamp entries at the moment of action, or is there a lag or manual entry gap?
  • Original: Is source data preserved, or is only a processed or summarized version retained?
  • Accurate: Is there evidence of periodic data review? Are there open discrepancies?
  • Complete: Are audit trails enabled and captured across the full transaction lifecycle including deletions?
  • Enduring & Available: Are records retained per the retention schedule and retrievable within regulatory timelines?

Cybersecurity Posture and Regulatory Exposure

Cybersecurity has moved from an IT concern to a board-level and regulatory concern for biotech. Three overlapping regimes now apply to most targets:

EU / EEA

NIS2 Directive

Pharma manufacturers, CMOs, CROs, wholesalers and biotech firms above 50 employees / EUR10M revenue are covered as “essential” entities with board-level cyber accountability, supplier oversight, and 24-hour incident notification.7

US Medical Devices

FDA Cyber Devices

The February 2026 FDA guidance interprets “cyber device” broadly — any device containing or being software with Wi-Fi or Bluetooth. Premarket submissions require SBOMs, risk analyses, and postmarket cyber plans.8

Cross-Cutting

EU Cyber Resilience Act

Full enforcement in 2027, imposing cybersecurity requirements on any product with digital elements sold into the EU. Relevant to connected devices and connected instruments in the diligence scope.

Baseline

NIST CSF 2.0 / ISO 27001

Use one of these as the diligence baseline. Ask for the target’s current maturity assessment. Absence of one is a finding on its own.

What “good” looks like in a diligence context

A well-run biotech cyber program will produce, on request, the following evidence: an information security policy with executive sign-off within the last 12 months, an ISO 27001 or SOC 2 Type II report or equivalent third-party attestation, a documented risk register with owners and remediation dates, an incident register for the past 24 months, results of an independent penetration test within the past 12 months, evidence of vulnerability scanning cadence, phishing simulation metrics, and a current business continuity and disaster recovery plan with test results.

Red flag. A target that cannot produce a penetration test report from the past 12 months, or produces one full of high-severity findings with no remediation evidence, is signaling that cyber will be an integration line item. Budget accordingly and consider a cyber-specific escrow.

The supply-chain angle

NIS2 explicitly extends cyber obligations to supplier oversight. That means the target’s vendor risk program is now in-scope for diligence. Ask for the target’s vendor risk assessments on their top 20 vendors by criticality. If those assessments do not exist, or exist only as a checkbox exercise, the acquirer will inherit that gap.

Cloud Spend, SaaS Contracts, and Vendor Lock-In

Public cloud is now the second-highest expense of most SaaS-native biotech companies, and cloud contracts routinely contain terms that surprise acquirers post-close.9 A structured review has three parts: financial trajectory, contractual exposure, and consolidation feasibility.

Financial trajectory

Ask for the last 24 months of cloud invoices broken out by service and by cost center. Look for four patterns:

  • Growth curve: Is cloud spend growing faster than revenue? By how much? Is the target’s unit economics assumption in the model still valid at scale?
  • Reserved capacity vs. on-demand: What percentage of compute is on 1- or 3-year reserved instances or committed use? What is the effective discount? What is left on the table?
  • Data egress: What is the monthly egress bill? A target with $50K+ per month in egress is either running a heavily distributed architecture or is trapped in a specific region.
  • Orphaned resources: Idle databases, forgotten dev environments, and un-terminated proof-of-concept clusters routinely account for 15-25% of biotech cloud spend. This is post-close synergy, but only if you know it exists.

Contractual exposure

Every enterprise SaaS and cloud contract should be inventoried and reviewed for six specific clauses: change of control, termination for convenience, data portability, price uplifts on renewal, SLA credit mechanisms, and audit rights. Biotech targets in particular should be reviewed for BAA (HIPAA), DPA (GDPR), and Cross-Border Transfer Agreements as separate documents.

The buried clause to look for. Some enterprise ELN and LIMS contracts contain “data conversion fees” or “extraction fees” that become payable if the customer chooses to migrate away. In one deal we reviewed, a target’s ELN vendor had a $1.2M contractual right to charge for structured data export in a machine-readable format. That is a $1.2M line item that shows up nowhere in the target’s financials but hits the acquirer’s integration budget on Day 1.

Consolidation feasibility

If the acquirer intends to consolidate systems — most do — the diligence team must produce an early view on feasibility. Two systems doing similar things do not automatically consolidate. If the target’s LIMS is validated for their specific bioprocess workflows and the acquirer’s LIMS is validated for different workflows, “consolidation” is a multi-year revalidation project. Flag this early.

Data Privacy and Cross-Border Data Flow

The privacy regulatory surface facing biotech acquirers is now genuinely global. Healthcare organizations must comply with 144 national privacy laws while protecting patient data across borders, and cross-border health data transfer is subject to a rapidly evolving patchwork.6 Three regimes almost always apply to biotech targets:

Regime Trigger Diligence Focus
HIPAA (US) Protected Health Information touched by target, or Business Associate relationships with covered entities BAAs, breach log, HIPAA risk assessment, PHI data map, workforce training
GDPR (EU / EEA) Any processing of EU/EEA personal data including trial subjects, patients, and EU employees Records of Processing Activities, DPIAs, transfer mechanisms (SCCs, TIA), subject rights response times
UK GDPR / DPA UK personal data — increasingly diverged from EU GDPR post-Brexit UK-specific representative, ICO registration, cross-border transfer approach
PIPL (China) Any processing of PRC personal data or transferring PRC data out of China Data localization posture, CAC security assessment, standard contract filings, sensitive PI classifications
APPI (Japan) Japanese personal information, common in Asia-Pac trials PPC compliance, cross-border consent mechanisms
State laws (CCPA/CPRA, TX, VA, CO, CT, etc.) Consumer-facing digital assets or California/covered-state resident data Privacy notices, opt-out mechanisms, sensitive PI handling

The practical diligence question is not “do they comply with all of this” — almost no target does, fully. The practical question is: where are the gaps, how large is the exposure, and what does remediation cost. GDPR fines have exceeded EUR 7.1 billion since 2018, with EUR 1.2 billion in 2025 alone, so under-scoping this workstream is not a defensible position.6

Cross-border data transfer as a deal-blocker

If the deal thesis depends on consolidating patient or trial data into a single platform hosted in the acquirer’s country, cross-border rules can materially constrain execution. China’s PIPL, in particular, restricts export of sensitive personal information without a CAC security assessment or standard-contract filing. If the target’s clinical trials generate data in China that the acquirer plans to move to US infrastructure, that is a strategy decision requiring legal input, not an IT decision.

Key-Person Risk and Technical Debt

Two workstreams that consistently produce the most surprising findings are people risk and technical debt. Both are underweighted in traditional M&A diligence.

Key-person risk

Key person risk materializes when critical business knowledge and skills are consolidated in a few individuals; when those people exit, they take institutional knowledge with them and leave downtime, security vulnerabilities, and continuity gaps in their wake.10 In biotech IT, key-person risk is nearly universal. A typical Series B biotech might have a total IT and data team of 8-15 people, with one senior engineer running everything cloud-related, one bioinformatician who owns the pipeline code, and one QA lead who knows how the LIMS was validated. All three of those roles are single points of failure.

A useful diligence exercise: ask the target’s CIO or Head of IT to name, for each critical system, “the one person we cannot afford to lose.” Then look at that person’s tenure, retention risk factors (comp position, equity vesting, personal situation), and the depth of documentation for their system. This exercise routinely surfaces five to ten unmitigated risks that translate directly into integration budget and retention package requirements.

What good looks like. Best-in-class targets show evidence of active knowledge-transfer programs, current runbooks for every critical system, cross-training on named backups, and named succession candidates for senior IT leadership. This is rare in Series B biotech. When you find it, it is a positive value signal.

Technical debt quantification

Technical debt in this context includes both code debt (poorly maintained custom applications, obsolete frameworks, missing test coverage) and infrastructure debt (unpatched operating systems, unsupported database versions, undocumented network configurations). Standards-based quantification — the SQALE method, ISO 5055, or OMG’s Automated Technical Debt Measure — allows the diligence team to translate debt into a principal figure that fits into the deal model.11

A pragmatic diligence approach: run automated code quality scans (SonarQube, CAST Highlight, or equivalent) on any custom code the target has developed, pair that with infrastructure health checks against a supportability matrix, and roll the outputs into three buckets:

  1. Deferred maintenance (must do in Year 1): unsupported software, EOL databases, unpatched OSs on internet-facing infrastructure.
  2. Structural debt (must do in Years 2-3): architectural constraints preventing scale or integration.
  3. Discretionary debt (optional): code quality improvements that would reduce total cost of ownership but do not represent immediate risk.

Integration Complexity Scoring

The last workstream produces the score that translates diligence findings into an integration budget and timeline. IT integration accounts for roughly 70 percent of all synergies in a typical M&A transaction, and lack of IT integration discipline is one of the top drivers of value destruction in life sciences deals.12

A scoring model that works

For each material system pair (target system vs. acquirer system doing similar work), score four dimensions on a 1-5 scale:

  • Functional overlap: How similar are the workflows? 1 = complementary, 5 = fully duplicative.
  • Data model divergence: How different are the underlying data structures? 1 = essentially compatible, 5 = fundamentally incompatible.
  • Regulatory constraint: How much revalidation would consolidation require? 1 = none, 5 = full CSV reboot.
  • Change tolerance: How disruptive would migration be to the business? 1 = trivial, 5 = business-halting risk.

Sum the scores. A system pair scoring 4-8 is a Day-1 consolidation candidate. A pair scoring 9-14 is a Year-1 project. A pair scoring 15-20 is a run-in-parallel scenario or a strategic decision to divest.

Integration budget math. Once the scoring model is complete, the diligence team should produce a rough integration cost envelope: system migration, identity federation, data model harmonization, revalidation, license consolidation, and change management. In life sciences deals, we typically model this at 3-6 percent of enterprise value as a Year-1 one-time cost, with a further 1-2 percent in Year 2. If the model produces a materially higher figure, that is itself a diligence finding.

The 100-Item IT Diligence Checklist

The following checklist is a reference template. Use it as a starting point, tune it for the specific target, and require documented evidence for every “Yes” response. “Yes” without evidence should be treated as “Not Confirmed.”

Category 1: Governance and Organization (Items 1-10)

  1. Current IT organization chart with FTEs, contractors, and offshore/nearshore split
  2. CIO / Head of IT tenure, background, and reporting line
  3. Documented IT strategy and multi-year roadmap
  4. Approved IT budget and last three years of actual spend
  5. IT steering committee governance and cadence
  6. IT risk register with executive-level visibility
  7. Board-level cybersecurity reporting cadence
  8. Named CISO or equivalent security accountable executive
  9. Data governance function and Chief Data Officer or equivalent
  10. Ethics or Responsible AI oversight for AI/ML deployments

Category 2: Validated Systems Inventory (Items 11-25)

  1. Complete validated systems inventory (LIMS, ELN, MES, QMS, EDC, CTMS, PV, etc.)
  2. GAMP category assignment for each system
  3. Current validation status for each system
  4. Date of last periodic review for each validated system
  5. Change control history for the past 24 months
  6. Open deviations and CAPAs affecting validated systems
  7. User access review evidence within the past 12 months
  8. Backup and disaster recovery evidence per system
  9. System retirement plan for EOL systems
  10. Vendor certification (audit, SOC 2, HDS) for each validated SaaS
  11. Data migration validation evidence for prior migrations
  12. Spreadsheet inventory and validation status
  13. Legacy system inventory with support status
  14. Interface and integration map for validated systems
  15. Master data governance for cross-system entities

Category 3: Data Integrity and ALCOA+ (Items 26-40)

  1. Data integrity policy signed off within past 24 months
  2. Named data integrity owner or steward per functional area
  3. ALCOA+ self-assessment evidence
  4. Audit trail configuration evidence for critical systems
  5. Shared login inventory (or attestation that none exist)
  6. Generic account usage review
  7. System clock synchronization evidence
  8. Historian retention policy and evidence
  9. Data review SOP and evidence of routine review
  10. Discrepancy management logs
  11. Records retention schedule aligned to GxP and privacy requirements
  12. Records disposal evidence and SOP
  13. Backup restore test evidence within past 12 months
  14. Long-term readable archive strategy
  15. Data lineage documentation for critical calculations

Category 4: Cybersecurity (Items 41-55)

  1. Executive-approved information security policy
  2. NIST CSF, ISO 27001, or SOC 2 Type II attestation
  3. Vulnerability management program with metrics
  4. Penetration test report within past 12 months
  5. Incident register for past 24 months
  6. Incident response plan and last test evidence
  7. Phishing simulation program and click-rate trend
  8. Endpoint detection and response coverage percentage
  9. MFA coverage across all identity providers
  10. Privileged access management program
  11. SIEM coverage and mean time to detect metrics
  12. Network segmentation between OT (manufacturing) and IT
  13. NIS2 assessment and gap plan (EU targets)
  14. FDA cyber-device assessment if applicable
  15. Cyber insurance coverage and last renewal underwriting

Category 5: Cloud, SaaS, and Infrastructure (Items 56-70)

  1. 24 months of cloud invoices by service
  2. Reserved capacity and committed use inventory
  3. Data egress cost trend
  4. Orphaned resource cleanup evidence
  5. SaaS application inventory with owners and renewal dates
  6. Shadow IT discovery process and findings
  7. Enterprise SaaS contract review (top 20 by spend)
  8. Change-of-control clause identification
  9. Data extraction and portability terms
  10. BAA coverage where PHI is processed
  11. DPA coverage where GDPR-scope data is processed
  12. Standard Contractual Clauses signed where required
  13. Hosting region map for regulated data
  14. Business continuity plan and last test evidence
  15. Disaster recovery plan and RTO/RPO commitments

Category 6: Data Privacy (Items 71-82)

  1. Data inventory and data flow map
  2. Records of Processing Activities (GDPR Article 30)
  3. Data Protection Impact Assessments for high-risk processing
  4. Named DPO or equivalent accountable role
  5. Subject rights response process and metrics
  6. Cross-border transfer mechanism (SCC, adequacy, BCR) inventory
  7. Transfer Impact Assessments post-Schrems II
  8. PIPL assessment for China-generated data
  9. HIPAA risk assessment within past 24 months
  10. State privacy law readiness (CCPA/CPRA, VA, TX, CO, etc.)
  11. Vendor data privacy assessment inventory
  12. Breach notification playbook aligned to relevant regimes

Category 7: People and Knowledge Risk (Items 83-92)

  1. Named single-point-of-failure inventory
  2. Retention risk assessment for named critical IT roles
  3. Cross-training and backup coverage evidence
  4. Runbook and knowledge base for each critical system
  5. Contractor and third-party dependency inventory
  6. Offshore engagement risk assessment
  7. Succession planning for CIO / CISO / Head of Data
  8. Talent attrition trend for past 24 months
  9. Retention package design for named key employees
  10. Non-solicit and non-compete coverage where enforceable

Category 8: Integration Readiness (Items 93-102)

  1. Enterprise architecture documentation
  2. Identity provider (SSO, IDP) inventory and federation feasibility
  3. Master data domains and steward inventory
  4. Integration platform (iPaaS, ESB) inventory
  5. Application dependency map
  6. Data warehouse and analytics stack description
  7. ERP, CRM, HRIS integration surface
  8. Estimated one-time integration cost bottoms-up
  9. Estimated run-rate synergy bottoms-up
  10. Day-1 readiness scorecard

Red-Flag Identification Framework

Not every finding matters equally. The framework below maps common findings to severity tiers. Priority 1 items should trigger deal-team escalation, potential price adjustment, or escrow. Priority 2 items are integration budget line items. Priority 3 items are watchlist.

P1

Deal-blocking or deal-adjusting

Active FDA warning letter or consent decree affecting IT systems. Data integrity finding with regulatory disclosure exposure. Cloud contract with material change-of-control termination fees not disclosed. Cross-border data structure that materially blocks the deal thesis. Ransomware or breach event in the past 24 months not disclosed to the deal team.

P2

Material integration budget impact

Unvalidated critical spreadsheets in GxP processes. Missing or overdue periodic reviews on validated systems. Cybersecurity maturity two or more levels below acquirer baseline. Cloud spend growing 40%+ year-over-year without corresponding revenue growth. Missing BAAs or DPAs. Named key-person risk with no succession plan.

P3

Watchlist and post-close remediation

Code quality below acquirer standards on non-critical systems. Under-utilized reserved cloud capacity. Missing but not overdue SOP reviews. Vendor risk program present but shallow. Documentation gaps on non-critical systems.

Valuation-Impact Model for IT Findings

The final output of a rigorous IT diligence effort should be a quantified translation of findings into deal terms. Three levers are available to the deal team.

Lever 1: Price adjustment

Some IT findings represent a direct reduction in enterprise value. Examples: an unusable cybersecurity posture in the context of NIS2 or FDA cyber-device requirements, a validated system estate requiring wholesale rebuild, or a data integrity finding that will require the acquirer to make a regulatory disclosure. The remediation cost, less any pre-existing accrual, is a candidate for price adjustment.

Lever 2: Escrow or holdback

Some IT findings represent contingent liabilities: a possible regulatory action, a possible litigation exposure, a possible contract dispute with a critical SaaS vendor. Escrow the estimated exposure for a defined tail period, typically 12-24 months.

Lever 3: Integration budget line item

Most IT findings translate directly into integration budget lines. The deal team should build a bottoms-up integration budget covering seven categories, with the diligence findings driving the numbers rather than industry benchmarks.

Category Typical Range (% of EV) Drivers
Validated system revalidation and consolidation 0.5% – 2.0% Number of GxP systems, GAMP category, integration complexity score
Cybersecurity uplift 0.3% – 1.5% Maturity gap vs. acquirer baseline, NIS2/FDA cyber-device scope
Cloud and SaaS rationalization 0.2% – 0.8% Contract exit costs, license consolidation, data migration
Data privacy remediation 0.2% – 1.0% Cross-border exposure, missing DPAs, subject rights process gaps
Data integrity remediation 0.3% – 1.5% Spreadsheet population, audit trail gaps, ALCOA+ posture
Technical debt paydown 0.5% – 2.0% SQALE / ISO 5055 principal, unsupported infrastructure
Retention packages and knowledge transfer 0.2% – 0.6% Named key-person count, tenure, competitive market

The sum of these categories represents a well-supported view of the IT integration bill. If the number falls outside a 3-6 percent of EV envelope for a mid-market biotech deal, either the target is exceptionally well-run or the diligence has surfaced a systemic issue worth escalating.

Conclusion

IT due diligence in biotech is not the generic technology review that corporate development teams routinely commission. It is a specialized exercise in translating regulatory, operational, and financial exposures encoded in software into deal terms an integration team can execute against. The eight workstreams, 100-plus item checklist, red-flag framework, and valuation-impact model in this article are designed to bring that discipline in-house or to inform how you scope an external effort. The goal is not exhaustive coverage. The goal is to ensure that no material IT finding surprises the integration team on Day 90.

Sakara Digital works with pharma and biotech organizations building this kind of due diligence discipline into their corporate development function. If you are preparing for a specific transaction, running a rolling M&A capability build, or wanting an independent second opinion on a diligence report already in flight, we are happy to have that conversation.