Our Expert in Ireland
Software due diligence Ireland has become materially more demanding heading into 2026, as buyers and sellers of technology businesses confront a tightening web of AI regulation, the transposition of the NIS2 cybersecurity directive, and increasingly assertive data protection enforcement. Where deal teams once treated code, licences and privacy as second-order workstreams, these areas now sit at the centre of valuation, warranty negotiations and post-closing risk allocation. This guide sets out a practical, executable checklist for acquirers, founders, in-house counsel and M&A advisers operating in the Irish market. It ties legal, IP, licensing, data protection, cybersecurity and AI-compliance risks into a single remediation-focused playbook.
TL;DR for buyers: verify chain of title to all code and IP, scan for open-source contagion, confirm GDPR and NIS2 posture, and secure warranties, indemnities and holdbacks calibrated to what diligence uncovers. TL;DR for sellers: clean up IP assignments, inventory your open-source usage, refresh privacy documentation and remediate critical vulnerabilities before you go to market, every unresolved issue becomes a price-chip or an escrow.
Effective software due diligence in Ireland depends on sequencing and clear allocation of responsibility. The checklist below is written to be shared across legal, technical and commercial teams, with each item assigned an owner, a document request and a severity rating. Treat it as a living data-room request list rather than a one-off exercise.
Sellers should assemble a due-diligence pack before a buyer ever asks. A well-ordered data room, with IP assignment registers, an open-source inventory, employee and contractor agreements, data mappings and security test reports, signals maturity, reduces deal friction and protects valuation.
Most valuation leakage in Irish tech deals is avoidable. The issues buyers penalise most, unclear IP ownership, unmanaged open source, stale privacy notices and known-but-unpatched vulnerabilities, are precisely the ones sellers can remediate cheaply in advance. A short, disciplined clean-up before going to market repays itself many times over.
Confirm that the company legally owns, or is validly licensed to use, the code, designs and inventions in its products. Gather assignment deeds, records of invention and evidence that founders, employees and contractors have assigned their work. Contractor-created code is a frequent gap: under Irish copyright law, absent a written assignment the developer, not the company, may retain ownership of the work.
Build a single register of all inbound third-party software and its licence terms. Missing or unread licences are a classic red flag that slows every buyer.
Run a scan, produce an open-source inventory and address any copyleft components in your proprietary codebase before diligence starts.
Refresh privacy policies, records of processing and data-processing agreements so they reflect what the business actually does. Under the GDPR and the Data Protection Act 2018, controllers and processors are generally required to maintain records of processing activities, and the Data Protection Commission expects those records to be accurate.
Close known critical vulnerabilities, patch dependencies and document your incident-response process.
Sample 30/60/90 remediation plan:
This is the core of any software due diligence Ireland exercise. For each item below, request the listed documents, watch for the flagged red flags, and rate severity High, Medium or Low based on how central the issue is to the product and how expensive remediation would be. High-severity findings should feed directly into indemnities or holdbacks; medium findings into warranties and remediation covenants; low findings into a disclosure schedule.
Documents to request: assignment deeds, records of invention, employment and contractor agreements, and any prior share purchase or asset transfer agreements that moved IP between entities.
Red flags: gaps in the chain of title, unassigned contractor work, jointly developed code without clear ownership, and reliance on founders’ pre-incorporation work never formally transferred in.
Evidence to accept: a complete, signed assignment chain from every contributor to the company. Severity: High where the affected code is core.
Documents to request: read access to repositories, commit history, contributor lists, branch and merge policies and CI build logs.
Red flags: unexplained large code drops (suggesting copied code), external contributors with no assignment, secrets or credentials committed to history, and missing history that prevents provenance checks.
Severity: Medium to High depending on provenance concerns.
Documents to request: a third-party licence inventory, licence headers, and full FOSS scanning reports.
Red flags: copyleft licences embedded in distributed proprietary code, licences with unsatisfied attribution or source-disclosure obligations, and components with no identifiable licence at all. Licensing risk is treated in depth in the dedicated open-source section below.
Severity: High for copyleft contagion in distributed products.
Documents to request: architecture diagrams, design documents, product roadmaps and coding standards.
Red flags: undocumented “tribal knowledge” architectures, single points of failure in the engineering team, and no documented release process. These raise integration risk even where legal title is clean.
Severity: Medium.
Documents to request: build scripts, dependency manifests, a Software Bill of Materials (SBOM), CI/CD pipeline configuration and vulnerability-scanning outputs. ENISA promotes SBOMs and structured dependency management as good cybersecurity practice, and their absence is itself a diligence finding.
Red flags: no SBOM, unpinned or abandoned dependencies, manual and unrepeatable builds, and secrets stored in pipelines.
Severity: Medium to High.
Documents to request: hosting architecture, tenancy model documentation, backup and restoration procedures and monitoring dashboards.
Red flags: weak tenant data separation, untested backups, and no disaster-recovery plan. The SaaS-specific checklist further below expands on these operational checks.
Severity: High for multi-tenant platforms handling personal data.
Documents to request: dependency trees, third-party API agreements and details of any critical single-source suppliers.
Red flags: heavy reliance on a single upstream component or vendor, use of end-of-life libraries, and unmonitored transitive dependencies.
Severity: Medium.
Documents to request: existing escrow agreements, key-person arrangements and business-continuity plans.
Red flags: mission-critical code held only by departing founders, and customer contracts that promise escrow the seller never established.
Severity: Medium to High.
Documents to request: customer master agreements, SLAs, supplier and hosting agreements, and cloud provider terms.
Red flags: change-of-control or assignment restrictions that a sale would trigger, uncapped liability, unusually generous SLA credits, and hosting terms that undermine data-protection commitments.
Severity: High where change-of-control clauses could terminate key revenue.
Documents to request: employment contracts, contractor agreements, confidentiality and IP-assignment clauses and any restrictive covenants.
Red flags: contractors without written IP assignment, weak confidentiality terms, and key engineers with no retention arrangements.
Severity: High for unassigned contractor IP in the core product.
Open source is embedded in almost every modern codebase, and it is one of the most common sources of deal friction in software due diligence Ireland. The legal exposure turns on the licence attached to each component. Permissive licences impose light obligations; copyleft and network-copyleft licences can require you to disclose or license your own source code under certain conditions, a phenomenon often called “contagion.”
| Licence type | Typical obligations | Deal impact | Remediation options |
|---|---|---|---|
| Permissive (e.g. MIT, BSD, Apache) | Attribution; retain notices; sometimes patent grants | Low, generally compatible with proprietary distribution | Confirm attributions are in place; document usage |
| Weak copyleft (e.g. LGPL, MPL) | Disclose modifications to the licensed component; allow relinking | Medium, manageable if the component is isolated | Keep component modular and dynamically linked; disclose modifications |
| Strong copyleft (e.g. GPL) | Distribute derivative works under the same licence, including source | High, can compromise proprietary distribution if entangled | Isolate, replace, re-engineer, or obtain a commercial licence |
| Network copyleft (e.g. AGPL) | Source-disclosure obligations extend to network/SaaS use | High for SaaS, triggers even without traditional distribution | Replace component or negotiate commercial terms |
Buyers care about three things: whether obligations have been met, whether contagion threatens the proprietary value they are paying for, and whether the seller can warrant the position. Undisclosed copyleft in a distributed or network-facing product can materially reduce value, because remediation may require re-engineering. Sellers who cannot produce a scan will face wider warranties and larger holdbacks.
Diligence findings only protect a buyer if they are converted into enforceable contractual protection. In Irish software sale agreements, the representations and warranties (R&W) and indemnity package is where the risk allocation is settled. The severity ratings from your checklist should map directly onto the negotiation priorities here.
Sellers commonly seek knowledge qualifiers (“to the best of the sellers’ knowledge”), disclosure against the warranties, and materiality thresholds. Buyers should resist knowledge qualifiers on fundamental ownership warranties, where the seller should stand behind the position absolutely, while accepting them for third-party infringement, which is genuinely harder to police.
The commercial levers are the liability cap, the de minimis and basket thresholds that filter small claims, and the survival period during which claims can be brought. IP and data-protection warranties are frequently treated as “fundamental,” attracting a higher cap and a longer survival period than general commercial warranties. Where diligence uncovers a specific, quantifiable risk, say a known copyleft entanglement, a standalone indemnity, uncapped or separately capped and often backed by an escrow, is the appropriate tool rather than a general warranty.
Data protection and cybersecurity are now among the highest-stakes workstreams in software due diligence Ireland, both because of enforcement exposure and because remediation can be slow and costly. The framework combines the GDPR, the Data Protection Act 2018, the NIS2 Directive and the emerging EU AI regime, with data protection overseen in Ireland by the Data Protection Commission.
Documents to request: records of processing, data-flow maps, the lawful basis relied on for each processing activity, consent mechanisms and privacy notices. Under the GDPR and the Data Protection Act 2018, controllers and processors are generally required to maintain records of processing activities, and their absence is a clear compliance gap.
Tests: reconcile the records of processing against what the product actually does; mismatches indicate the documentation is stale.
Confirm that data-processing agreements meeting the requirements of Article 28 GDPR are in place with every processor and that customer contracts allocate responsibilities correctly. Missing or non-compliant processing terms are a frequent finding and are usually remediable through covenants.
Where personal data leaves the EEA, verify the transfer mechanism, an adequacy decision or Standard Contractual Clauses with any required supplementary measures. Undocumented international transfers are a significant risk given the DPC’s enforcement focus.
Documents to request: the data-breach register, correspondence with the DPC, and the incident-response plan. A pattern of unreported or poorly handled incidents signals systemic weakness. The Data Protection Commission can impose corrective measures and, for serious GDPR infringements, significant administrative fines, so incident history feeds directly into risk pricing.
Confirm whether the target is required to appoint a Data Protection Officer and whether Data Protection Impact Assessments have been carried out for higher-risk processing. Absent DPIAs where the law requires them is a documentable gap.
The NIS2 Directive (Directive (EU) 2022/2555) broadens the range of entities subject to cybersecurity risk-management and incident-reporting obligations, and can capture digital infrastructure and service providers relevant to many SaaS vendors. Ireland is implementing NIS2 through national legislation, and deal teams should confirm the current state of transposition and the designated competent authorities. Confirm whether the target falls in scope, whether it has implemented the required risk-management measures, and whether reporting processes exist. In-scope targets that have not prepared present both a compliance gap and a remediation cost.
Where the product incorporates AI, extend diligence to the provenance and licensing of training data, model documentation, and DPIAs for higher-risk processing. The EU Artificial Intelligence Act (Regulation (EU) 2024/1689) introduces obligations that phase in over several years, with different requirements depending on an AI system’s risk classification. Buyers should seek representations on training-data rights, model provenance and compliance with the applicable AI framework, and consider standalone indemnities where the AI functionality is central to value. AI documentation is increasingly becoming a standard diligence item across Irish tech deals as the EU framework beds in.
Documents to request: penetration-test reports, vulnerability-management logs and remediation tracking. ENISA’s guidance on vulnerability management, SBOMs and dependency management provides a useful benchmark for what “good” looks like. Unremediated critical findings should be reflected in a holdback with a fixed remediation deadline.
SaaS targets carry operational and commercial risks that go beyond the legal and IP workstreams. A SaaS acquisition checklist should test both how the platform runs and how the revenue behaves.
Diligence does not end at signing. The findings that could not be fully resolved beforehand should be managed through structured post-signing mechanisms tied to clear triggers and timetables.
For proprietary core code that is critical to continuity, a source-code escrow gives the buyer or customers access on defined trigger events, such as insolvency or a failure to maintain the software. Agree the verification procedure, confirming that the deposited materials are complete and buildable, and the release conditions in advance.
Where remediation of a specific diligence finding cannot complete before closing, hold back part of the consideration against a documented remediation schedule, or place funds in an indemnity escrow. Tie release to independently verifiable milestones. A short, dated remediation plan, mirroring the 30/60/90 approach sellers use pre-sale, keeps post-close obligations measurable and reduces the scope for later dispute.
| Risk area | Buyer objective | Seller objective | Common contractual lever |
|---|---|---|---|
| IP ownership | Absolute, unqualified title warranty | Knowledge qualifiers and disclosure | Fundamental warranty; higher cap; specific indemnity |
| Open source | Full disclosure and remediation of copyleft | Limit scope of warranty to known usage | OSS warranty; specific indemnity; escrow tied to fix |
| Data protection | Robust GDPR/DPA compliance warranties | Cap exposure for historical processing | Fundamental warranty; longer survival period |
| Cybersecurity / NIS2 | Evidence of controls and reporting readiness | Exclude pre-signing unknown incidents | Warranty plus holdback for remediation |
| Contracts | No change-of-control termination risk | Limited assignment/consent obligations | Consents as closing conditions; indemnity |
| Continuity | Access to critical code and key people | Minimise post-close obligations | Source-code escrow; retention packages |
| AI functionality | Training-data rights and compliance warranties | Narrow representations to known facts | Specific AI indemnity; documentation covenant |
Software due diligence Ireland in 2026 is no longer a box-ticking exercise. The combination of the EU AI Act, NIS2 transposition and active data-protection enforcement means that IP, open source, privacy and cybersecurity now shape valuation, warranties and post-closing risk directly. Buyers who work through a structured, severity-rated checklist, and convert findings into precise warranties, indemnities, escrows and holdbacks, protect the value they are paying for. Sellers who remediate early and present a clean, well-documented data room protect their price and speed the deal to close.
Because the Irish transposition of NIS2 and the phased application of the EU AI framework continue to develop, deal teams should treat this checklist as a baseline and confirm the current legal position before signing. This guide is general information and not a substitute for tailored legal advice.
This article was produced by Global Law Experts. For specialist advice on this topic, contact Dean Cunningham at Cunningham Solicitors, a member of the Global Law Experts network.
posted 14 minutes ago
posted 56 minutes ago
posted 1 hour ago
posted 2 hours ago
posted 2 hours ago
posted 3 hours ago
posted 3 hours ago
posted 3 hours ago
posted 3 hours ago
posted 4 hours ago
posted 4 hours ago
posted 4 hours ago
Find the right Legal Expert for your business
Send welcome message