IT and software due diligence checklist for sellers

Start with claims, evidence and scope

Technical due diligence sits inside the wider company assessment. The Swiss SME Portal explains that due diligence informs the purchase decision, price and transaction contract, and that its scope changes with the contemplated transfer. A buyer of shares may examine the whole operating history and liability perimeter. An asset buyer may focus on the technology, contracts and rights being transferred. Qualified advisers should define the legal and transaction scope.

Build an index before uploading files. For every important statement in the sale material, identify the artefact that supports it, its owner, its date and any exception. A claim such as "deployments are automated" should point to a pipeline configuration, a recent run and a named backup owner. This approach makes contradictions visible before a buyer finds them.

Document architecture, inventory and change

Provide a current system map showing applications, data stores, hosting, integrations, critical vendors and trust boundaries. Pair it with an inventory that names each production service, technical owner, lifecycle status and dependency. A diagram without owners becomes stale; an inventory without relationships hides concentration risk.

Buyers also test reproducibility. Show where source code lives, how branches and reviews work, how a release reaches production and how it can be rolled back. Select one representative release and trace it from approved change through build, test, deployment and monitoring. If a founder or one engineer must remember an undocumented step, record it as a remediation item rather than disguising it.

• Architecture diagram and data flows
• Application, infrastructure and vendor inventory
• Repository ownership and access model
• Build, test, release and rollback evidence
• Environment and configuration management
• Roadmap, end-of-life components and technical debt register

Make security and resilience testable

The Swiss Federal Office for Cyber Security baseline protection guidance treats information security as both an organisational and technical responsibility. Your evidence should therefore connect controls to accountable people, not merely list tools. Show identity administration, privileged access, patching, vulnerability handling, endpoint and cloud controls, logging, incident response and staff responsibilities.

Backups are evidence only when restore has been tested. Record scope, frequency, retention, separation from production and the most recent recovery exercise. Map recovery expectations to customer promises and internal priorities. List material incidents with dates, impact, response, corrective action and present status. A concise incident record is more credible than an unsupported claim that nothing has ever happened.

A buyer is asking a practical question: can a second person deploy, restore and respond without relying on undocumented memory?

Control data and privacy disclosure

A data room does not remove confidentiality, contractual or data-protection duties. The FDPIC guidance on technical and organisational measures emphasises purpose, proportionality and restricted access. Inventory personal and sensitive datasets, processing purposes, locations, processors, retention, deletion and cross-border flows. Ask qualified counsel how the Swiss Data Protection Act and customer obligations apply to the actual transaction.

Use staged disclosure. Early evidence can describe controls and aggregated data. Identifiable customer or employee records should be shared only when necessary, with defined recipients, redaction where appropriate, access expiry and a disclosure log. Record security questionnaires, processor agreements and unresolved privacy matters so the commercial story matches the evidence.

Check licences, ownership and key people

Technology and ownership evidence must reconcile. Link each core component to its repository, author or supplier, employment or contractor relationship, assignment or licence, and third-party dependencies. Maintain an open-source component inventory with licence and notice obligations. The companion guide on software IP ownership gives a fuller provenance checklist.

Map each critical system to a primary and backup owner. Include employees, contractors and vendors, then record notice periods, handover capacity and privileged access. The map should reveal where one person controls architecture, releases, customer incidents or vendor relationships. Buyers can then distinguish manageable handover work from an operating risk.

Use a red, amber and green evidence register

Consider an illustrative Swiss SaaS company that says recovery is tested quarterly. The team finds a current backup policy, but the last recorded full restore was eleven months ago and only the founder holds a cloud recovery credential. The claim should be amber or red, not green. The register assigns a platform lead, schedules a controlled restore, creates separately governed emergency access and records the result.

This example is not a clean-bill-of-health test. The colour is an internal prioritisation tool. Define the meaning of each status, retain the underlying facts and avoid changing labels merely to improve presentation. A buyer will place more trust in a documented exception with an owner and date than in a broad assurance that cannot be reproduced.

1. List claims made in the sale materials.
2. Attach current artefacts and named owners.
3. Test one representative process in each critical area.
4. Record exceptions and commercial relevance.
5. Remediate high-impact gaps before outreach where practical.
6. Keep an auditable disclosure log.

Anticipate the questions behind the checklist

A buyer does not review technology in isolation. The reviewer is connecting technical facts to customer continuity, future investment and the warranties or disclosures under discussion. For each critical system, prepare a short explanation of business purpose, users, current scale, service expectations, owner, likely failure mode and planned investment. Keep observed facts separate from forecasts. If capacity has not been tested beyond today's load, describe the current evidence and the next test instead of claiming unlimited scalability.

Prepare an evidence path for the questions that commonly follow. How does a new engineer obtain access? Which changes require peer review? Who can approve an emergency release? How are customer-specific configurations separated? What happens when a critical vendor fails? Which components are near end of life? How are security findings prioritised? The answer should point to a policy, system record, recent example and accountable person. Rehearse the path with someone who does not normally perform the task.

Reconcile the roadmap with budgets, customer commitments and technical debt. A roadmap full of product features but no security, platform or lifecycle work is likely to prompt questions. Distinguish committed customer work, internal priorities and optional ideas. Record dependencies and the decision process used when priorities conflict. Buyers need to see how management turns constraints into a plan, not only a polished list of ambitions.

Run quality control before opening the data room

Review dates, entity names, environments and definitions across every artefact. Architecture diagrams, vendor lists, incident logs, headcount schedules and financial materials should describe the same business at the same cut-off date. Remove obsolete duplicates but preserve an audit trail. Mark drafts clearly. If a policy says quarterly access reviews occur, confirm the review records exist and cover the systems named in the policy.

Use a question log during diligence. Assign an owner, due date, source documents and approval for every answer. Capture corrections visibly. A controlled correction builds trust; an unexplained replacement can create concern about the wider dataset. Separate factual responses from legal interpretation and management forecasts, and route each to the appropriate specialist.

Prepare the review without freezing the business

Start with systems that affect customers, revenue, rights or continuity. Assign one coordinator, preserve normal engineering ownership and use a versioned index. Early document gathering can save time and cost, according to the Swiss SME Portal, but indiscriminate uploads create noise and disclosure risk.

Run a short internal review against the buyer questions: what is critical, what can fail, who responds, which rights transfer, which commitments constrain change and what investment is already expected? Reconcile the answers with financial and commercial materials. Then use the guide to selling an IT company in Switzerland to place technical preparation inside the wider exit process.

The pack is ready for controlled buyer review when every material claim has a current artefact, named owner, test date, documented exceptions and an approved disclosure class.