Technology due diligence: what to check when acquiring a small business

Most small business acquisitions get a quality of earnings review, a legal review, and a look at the customer contracts. Technology usually gets a conversation. Someone asks whether the systems are in the cloud, someone else says mostly, and the subject closes. Then the deal completes and the buyer discovers that the accounting system runs on a server in a closet under a desk, that the design software is licensed to a person who left in the first month, that the shared drive has fifteen years of client records nobody has ever classified, and that the entire environment is held together by a contractor who was never going to stay.

None of that is a disaster on its own. Every one of those things is fixable, and small businesses routinely get bought with far worse. The problem is timing. Each of those findings has a cost, and every one of them was discoverable before signing. Found before close, they are negotiating material: a price adjustment, an escrow holdback, a closing condition, or a specific representation with an indemnity behind it. Found after close, they are simply the buyer’s problem, paid for twice, once in the purchase price and once in the remediation.

This article covers what a technology due diligence review actually examines, how to scope one so it finishes inside the diligence window rather than after it, which findings should move the valuation or the deal terms as opposed to going quietly into the integration plan, and how a vCIO or MSP supports both the buyer and the seller through it. It is written for the person on the buy side who has to decide how much technology risk is in a deal, and for the owner on the sell side who wants to stop being surprised by questions their own systems cannot answer.

Short answer

Technology due diligence answers one question: what will it cost to own and operate this technology after close, and what could it cost if something already went wrong. Cover seven areas – infrastructure, software licensing and transferability, security posture and incident history, technical debt and key person risk, vendor contracts and their assignment clauses, data governance and compliance, and the IT function itself. Scope it to the deal size, start it the week diligence opens rather than the week before close, and sort every finding into one of three buckets: it changes the price, it changes the terms, or it changes only the integration plan. Most technology findings belong in the third bucket. Presenting them as if they belonged in the first is the fastest way for a technology reviewer to stop being listened to.

Technology due diligence at a glance

Question	Short version
What is technology due diligence?	A structured review of what the target runs, what it owns, what it owes, and what is already broken.
When should it start?	The week diligence opens. It is the review most often scoped last and finished late.
How long does it take?	Two to four weeks for a small business, running in parallel with financial and legal.
What does it cost?	Typically a fraction of a percent of deal value. Well under the cost of one unfound problem.
Who does it?	A vCIO, an MSP with diligence experience, or an independent technology advisor. Not the target’s own provider.
Does it need system access?	No. Most of it runs on documents, interviews, and read-only exports.
What is the most expensive thing missed?	Software that does not transfer, and a breach that already happened and has not been found.
Does asset versus stock purchase matter?	Enormously. It decides whether contracts and licenses come with the business or have to be re-bought.
What changes the price?	A quantified, certain cost the buyer will incur. Nothing else.
What changes the terms?	Anything uncertain: unknown breach exposure, license non-compliance, a key person who will not stay.
Should the seller do this too?	Yes, six to twelve months out. Sell side findings are cheap to fix and expensive to concede.

What the review is actually for

It is worth being precise about the purpose, because technology reviews go wrong when the person running them is not sure what they are producing.

A technology due diligence review is not a security assessment, although it looks at security. It is not a network assessment, although it inventories the network. It is not an audit, and it does not produce a compliance opinion. Those are all deliverables that answer “is this good,” and a buyer is not asking that. The target’s technology is very unlikely to be good. It is a small business, and small business technology is almost always somewhere between adequate and held together with tape.

The buyer is asking four narrower questions.

What am I actually buying? An inventory, with enough detail to tell the difference between an asset and a liability.

What comes with it and what does not? This is the question that surprises people. A substantial amount of small business technology does not transfer in an acquisition, and nobody finds out until the vendor sends a new quote.

What is already wrong that I will have to pay to fix? Deferred work, end of life systems, unsupported software, nonexistent backups.

What could have already happened that I would be buying? Prior breaches, unlicensed software, data the business had no right to collect or keep. These are contingent liabilities, and they follow the entity in a stock purchase.

The first three are estimates you can put a number against. The fourth is exposure you cannot quantify, which is why it gets handled in the terms rather than in the price. Holding that distinction is what makes the review useful to the deal rather than an interesting document nobody reads.

Scope it to the deal, and start it early

The single most common failure is not depth. It is timing. Technology is scoped last, usually after the financial review has already found something interesting, and the reviewer gets handed a two week window that includes a holiday. What comes back is an inventory with no analysis, delivered after the terms are largely agreed, which means it cannot change anything.

Three tiers work for small business deals. Pick one at the start and say what is out of scope.

Deal profile	Scope	Effort	What you deliberately skip
Small tuck-in, few employees, mostly cloud	Document review, two interviews, license and contract check	Three to five days	Technical debt depth, code review, anything requiring system access
Typical SMB acquisition, on-premises plus cloud, regulated or not	Full seven-area review, document requests, four to six interviews, read-only exports	Two to three weeks	Penetration testing, source code, exhaustive endpoint inventory
Technology-dependent business, custom software, regulated data	Everything above plus architecture review, source code and IP ownership, compliance evidence	Four to six weeks	Rarely anything

Scale the effort to what technology actually contributes to the business being bought. A distribution company with twelve staff and an off-the-shelf ERP does not need six weeks. A managed services firm, a software company, or any business where a system is the product needs the deepest tier regardless of headcount, because the thing generating the revenue is the thing being reviewed.

State the deliverable date against the deal calendar, not against your own availability. If the review cannot finish before terms are agreed, say so at the start and ask for either more time or a narrower scope. A complete review delivered after the letter of intent is signed has become an integration document, and it should be described that way rather than presented as diligence.

Area one: infrastructure

Start with what physically and logically exists, because everything else attaches to it.

Servers and where they live. Physical servers, virtual machines, cloud instances. For each: what runs on it, the operating system and version, whether that version is still supported, warranty or support status on physical hardware, and age. A physical server past warranty running an operating system past end of support is not an inventory line, it is a dated replacement cost.

End user devices. Count, age distribution, operating system versions, whether they are managed centrally or not, and how many are personally owned. A fleet of five year old laptops is a capital expense arriving in year one. Unmanaged personally owned devices holding business data are a governance finding, not a hardware one.

Network. Firewall make, model, and whether its support subscription is current. Switches, wireless, internet circuits and contract end dates, any site to site connectivity. A network assessment covers what a proper look at this layer produces, and in a larger deal it is worth commissioning one as a diligence input rather than trying to reconstruct the network from a conversation.

Backup and recoverability. Not “do you have backups.” Three questions: what is protected, when was a restore last tested, and what is the documented recovery time. Most small businesses answer the first confidently and the second with silence. An untested backup is an assumption, and why most companies never test theirs explains how that state becomes normal. If the target has no tested recovery capability, the buyer is acquiring the recovery gap along with everything else, and ransomware makes that gap concrete rather than theoretical.

Facilities dependencies. This one gets missed. If the deal includes vacating a leased office, everything in that office has to move, and the lease end date is now a technology deadline. Server rooms, wiring, phone systems, and anything depending on a specific circuit at a specific address become a project with a hard date, and that project has a cost that belongs in the model.

Area two: software licensing, and whether it transfers

This is where the largest unexpected number usually hides, and it is the area most specific to acquisitions rather than to ordinary operations.

The inventory itself is a solved problem. How to manage software licenses and renewals without losing track defines exactly what to capture per license, including the operational fields beyond cost and renewal date. Use those fields, and do not invent a different set for diligence. If the target already maintains that inventory, the licensing portion of the review takes a day rather than a week, which is one of the better arguments for a seller building one before going to market.

What due diligence adds to that inventory is one column the operating business never needs: does this survive a change of control, and under what conditions.

The answer depends heavily on the deal structure, and the difference is not a technicality.

In a stock purchase, the legal entity continues and simply has new owners. Most contracts and licenses continue with it, unless they contain a change of control clause that says otherwise. Many do.

In an asset purchase, the buyer acquires specified assets, and every contract has to be assigned. Assignment usually requires the vendor’s consent. A vendor asked for consent has a commercial opportunity, and some of them take it.

So the review goes license by license against four questions: is this assignable, does it require consent, is that consent likely to be free, and is it licensed to the business or to a person. That last one matters more than it sounds. Design tools, developer tools, and professional subscriptions are frequently held in an individual’s name, sometimes on a personal card, and they leave when the person does. Shadow IT bought on personal cards is an operating annoyance and an acquisition problem, because the buyer cannot acquire something the business never owned.

Three specific traps worth naming.

Perpetual licenses tied to a legal entity. Older on-premises software with a one time purchase often names the licensee. An asset purchase can require re-purchase at current pricing, which for some categories is a substantial number.

Tenant to tenant migration. Microsoft 365 and Google Workspace tenants do not merge. If the target is being folded into the buyer’s tenant, that is a migration project with real cost and real risk to mailbox data, not an administrative change. Microsoft 365 licensing explains why the SKU mix matters here, and removing licenses the wrong way destroys data, which is a mistake people make during exactly this kind of consolidation.

Unlicensed or over-deployed software. More installations than seats. This is a contingent liability rather than a cost, because the exposure is an audit that may or may not happen, and the vendor’s true up pricing is not the price you would have paid. It belongs in the terms, not the price.

Area three: security posture and incident history

Security in diligence is a different exercise from security in operations, and conflating them produces a document the deal team cannot use.

An operating business wants to know how to improve. A buyer wants to know two things: what will it cost to bring this environment to an acceptable baseline, and is there an incident in the past that has not surfaced yet.

For the first, a short fixed list is more useful than a scan. Multi-factor authentication, and whether anyone is exempt. Administrative accounts and how many there are. Whether endpoints have modern detection or just antivirus. Patching, with an actual figure. Email security. Whether former employees still have access to anything. The Microsoft 365 security audit checklist covers the cloud identity half of that list in detail, and a practical network security checklist covers the rest. Price the gap to baseline and put the number in the model.

For the second, ask directly and in writing. Has the business experienced a security incident, a ransomware event, a business email compromise, or a data breach. Has it made a breach notification to any regulator, client, or individual. Has it filed a cyber insurance claim. Has it received a ransom demand, paid or unpaid.

Ask for the cyber insurance application as well as the policy. The application is the more revealing document, because the business made specific factual assertions on it to obtain coverage. If the application says multi-factor authentication is enforced on all remote access and the environment shows otherwise, that is a finding with two consequences: the control gap, and a policy that may not respond when it is needed. What cyber insurance covers and does not explains why misrepresentation on the application is one of the main reasons claims fail, and in an acquisition the buyer inherits that problem.

Undiscovered incidents are the reason security exposure is handled in the terms. You cannot prove absence. What a breach actually costs a small business gives you the range to argue with, but the right instrument is a representation with survival period and indemnity behind it, not a price reduction. Also look for the signals that something is currently wrong rather than historically wrong, because a compromised network gives off indications that a review is well placed to notice.

Area four: technical debt and key person risk

Technical debt is the accumulated cost of work that was deferred. In a small business it is rarely dramatic and almost always present, and the useful output is not a catalog of everything imperfect. It is a dated list of what forces action and when.

Sort every item by what makes it urgent.

End of support dates. An operating system, database, or application that loses vendor support on a known date. This is the cleanest category in the entire review, because it has a date on it and the date is not negotiable.

Single points of failure. One server that everything depends on. One internet circuit. One person who holds a password. These do not have dates, but they have probabilities and consequences, and RTO and RPO give you the vocabulary to express what an outage would actually mean.

Custom and semi-custom software. Anything built for this business rather than bought. Who wrote it, who owns the intellectual property, who can maintain it, is there source code and documentation, and does it run on anything still supported. An undocumented application written by a contractor a decade ago, still running, still essential, is one of the highest-consequence findings a small business review produces.

Scale ceilings. Something that works at current volume and does not at the volume the acquisition thesis assumes. If the deal model has revenue doubling, ask what breaks first.

Key person risk deserves its own treatment, because in businesses of this size the technology is frequently in one person’s head rather than in any document.

Ask who would be called at two in the morning. Then ask what happens if that person declines to stay, because in a small business acquisition the answer is frequently that they are not staying. Establish whether the knowledge exists anywhere else: documentation, a second person, or a provider with the same access. If the answer is no, that is not a technology finding, it is a retention question, and it belongs in front of the deal team immediately rather than in a technology appendix. Retention agreements are cheap relative to reconstructing an undocumented environment, but only if someone raises it before the terms are set.

Watch the direction of this too. The signs a business has outgrown DIY IT read very differently in a diligence context, because the buyer is not deciding whether to fix them. The buyer is deciding what they cost.

Area five: vendor contracts, assignment, and exit

How to evaluate technology vendors as a small business works through the clauses that matter in a technology contract and what good looks like in each, including a full treatment of exit provisions. Read it rather than re-deriving it here. Everything in that article applies unchanged to reading the target’s contracts.

What diligence changes is the point of view. That article is written for a business signing a contract, where the assignment clause is something you want in case the vendor is acquired. In diligence you are on the other side of the same clause: the customer is being acquired, and every one of those contracts is now being read to answer whether it survives.

Go through the target’s material contracts and pull four facts for each: term end date, notice period, whether it auto-renews, and what it says about assignment or change of control. Sort the results into three groups.

Transfers cleanly. Nothing to do.

Requires consent. Build a consent list with a realistic timeline. Some vendors process these in a week, some take two months, and a few treat it as a renegotiation.

Terminates or reprices on change of control. These are the ones that matter. A contract that a vendor can terminate on a change of control is leverage held by a third party over your deal.

Look hard at the target’s managed services agreement in particular, because the provider relationship shapes everything that happens on day one. What should be in a managed IT services agreement gives you the checklist. In diligence, focus on the exit terms specifically: notice period, what documentation is returned, who holds administrative credentials, and whether licenses purchased through the provider transfer to the client or stay with the provider. That last point is a genuine trap. A provider who bought the target’s Microsoft licenses under their own agreement may not be able to hand them over, and the buyer discovers this while trying to move the tenant. Switching managed IT providers without losing everything describes what a bad provider exit actually looks like, and an acquisition is the single most likely moment to trigger one.

Also identify any contract where the target’s own provider is the counterparty to a clause you are relying on. A provider who knows the business is being sold, and whose contract ends at close, has limited incentive to be helpful during transition. Handle that relationship deliberately rather than assuming goodwill.

Area six: data governance and compliance

This area produces the fewest line items and the largest tail risk, which is why it gets skipped in small deals and should not be.

What data does the business hold. Categories, not volumes. Customer personal information, employee records, payment data, health information, anything under a client NDA. In a stock purchase the buyer acquires all of it along with every obligation attached to it.

Where does it live. Including the places nobody lists: the shared drive, individual mailboxes, a departed employee’s personal cloud storage, and a spreadsheet on somebody’s desktop. The honest answer for most small businesses is that data is in more places than the inventory says, and the finding is the absence of a map rather than any particular copy.

What can be deleted. Retention is the quietest risk in a small business acquisition. Fifteen years of records kept because nobody decided to delete them is fifteen years of breach exposure with no business value attached. It is also the cheapest thing on the entire list to fix, and one of the few findings where the right answer costs nothing.

What obligations attach. Sector rules like HIPAA for anything touching health information, state privacy laws that vary by where customers live rather than where the business is, contractual security commitments made to the target’s own clients, and payment card obligations. Data privacy law as it applies to small businesses covers the framework. Ask specifically for any security questionnaire, client audit, or vendor assessment the target has completed in the last two years, because those documents contain the target’s own written statements about its posture, made to a customer who was relying on them.

What has already been committed to in writing. This is the fastest route to a real finding. Compare what the business has attested to – in an insurance application, a client questionnaire, a signed contract clause, a compliance self-assessment – against what the review actually found. A gap between an attestation and reality is not a technology problem. It is a misrepresentation that already exists, made to a party who relied on it, and it belongs in front of deal counsel rather than in a technology summary.

Also check AI use, which is new enough that most small businesses have no record of it. Which AI tools are in use, under what terms, and what business data has been put into them. An unmanaged AI tool holding client material under an NDA is a contractual exposure the target may not know it has.

Area seven: the IT function itself

The last area is not systems, it is how the systems are run, and it determines what day one looks like.

Who provides support, on what agreement, and what does it cost. Is there internal IT, and if so, is it a dedicated person or someone doing it alongside another job. Co-managed IT describes the hybrid arrangement small businesses often land in without naming it. Find out whether the target is in one.

Then check the administrative layer, because this is the part that fails most visibly at close.

Who holds the top-level administrative credentials for every system. Where do the domain names live and who can log in to the registrar. Who controls the DNS. Who is the billing contact on each cloud subscription. What happens to service accounts and shared credentials when the owner leaves. And who has access today who should not: former employees whose access was never fully removed are common in small businesses and are a finding in their own right.

Establish what documentation exists. Network diagram, asset list, password vault, runbooks, vendor contact list. The realistic answer for a small business is a partial list in one person’s email, and that is fine as an answer. It is not fine as a discovery made in week one after close, when the seller has moved on and is no longer obliged to answer questions.

A useful concrete request: ask for a copy of the password vault export, held in escrow with counsel, as a closing deliverable. It is a small ask, it is easy for the seller to satisfy, and it converts the single most common post-close problem into an administrative step.

The document request list

Send this at the start. Most of it is documents the target already has, and the ones they cannot produce are themselves the finding.

Request	What it tells you
Asset list: servers, devices, network equipment	The inventory, and whether one exists
Software and subscription list with costs and renewal dates	The recurring cost base, and licensing exposure
All technology vendor contracts and MSP agreement	Assignment, exit, and what is actually committed
Last twelve months of technology invoices	The real spend, which rarely matches the stated spend
Cyber insurance policy and the application	Coverage, and what was asserted to obtain it
Backup configuration and most recent restore test	Whether recovery is capability or assumption
Any security assessment, scan, or audit in the last two years	Known issues, and whether they were acted on
Client security questionnaires completed in the last two years	Written commitments made to customers
Compliance documentation for any applicable regime	Whether obligations are met or merely acknowledged
Network diagram and system documentation	Whether the environment is documented or resident in one head
Administrative account list and who holds credentials	Day one control, and orphaned access
Domain registrar and DNS control details	The most commonly lost asset in a transition
Custom software: source code location, IP assignment, contractor agreements	Whether the business owns what it runs on
Breach and incident history, written confirmation	Contingent liability

Track what comes back and what does not, and put the gaps in the report explicitly. “The business could not produce a list of administrative accounts” is a finding about how the business is run, and it is often more informative than the list would have been.

Red flags, sorted by what they should change

This is the part that makes a technology review useful to a deal team, and the part most reviews get wrong. Findings are not equal, and they do not all deserve the same response. Sort them by what they should change.

Findings that change the price. A certain, quantifiable cost the buyer will incur on a known schedule. Hardware past end of life with a replacement cost. Software that does not transfer and must be re-bought at a quoted price. A tenant migration with a scoped cost. A facilities move with a lease-driven date. Each of these is a number, defensible in a spreadsheet, and each belongs in the model as a real adjustment.

Findings that change the terms. Real exposure that cannot be quantified. Undisclosed or suspected prior breaches. Software licensing non-compliance with unknown true up exposure. Data retained with no legal basis. A regulatory obligation not met. A gap between what the business attested to a client or insurer and what is true. These get handled with representations and warranties, a specific indemnity, an escrow holdback, or a closing condition, because you are pricing uncertainty rather than cost.

Findings that change only the integration plan. Poor documentation. Aging but functional equipment. No formal change process. Weak but not absent security controls. Everything the buyer will improve anyway as part of normal operation. These belong in the first hundred days plan and nowhere else.

The temptation is to escalate everything into the first bucket, because that is where a reviewer feels most influential. Resist it. A technology report arguing that fifteen findings should all reduce the price is arguing against itself, and the deal team will discount the entire document including the three findings that were real. Two priced findings and one term change, stated plainly with the arithmetic shown, will move a deal. Fifteen will not. This is the same discipline that makes a security report land with leadership rather than get filed, and the reason is identical in both cases: credibility is spent, and spending it on things that do not matter leaves none for the things that do.

A handful of findings deserve to stop a deal outright rather than adjust it, and they are worth naming. An active, ongoing compromise. A regulatory breach obligation that was triggered and never discharged. Custom software essential to revenue that the business does not own the rights to. A single person holding sole administrative control who has already said they are leaving. Each of these is recoverable, but none of them should be discovered the week after close.

What you cannot find out before close

Be honest in the report about the limits, because an overstated review is worse than a narrow one.

You will usually not get live system access. Most reviews run on documents, interviews, and read-only exports, which means you are largely assessing what the business says and can evidence rather than verifying the environment directly.

You cannot prove the absence of a prior breach. You can confirm whether one is known and whether the controls that would have detected one exist. That is a different claim and should be written as one.

You will not see everything. Shadow IT, personal cloud accounts holding business data, and undocumented integrations are by definition not on the list you were given.

Interviews reflect what people believe. In a sale process, the person answering may have incomplete knowledge, or a strong interest in a particular answer, or both.

State these as scope limitations rather than burying them. A buyer who knows the review could not verify something can decide to cover it in the terms. A buyer who thinks it was verified cannot.

Sell side: what to fix before you go to market

Everything above works in reverse, and it is significantly cheaper to run on yourself six to twelve months before a sale than to concede during one.

The mechanism is simple. In diligence, every unanswerable question becomes an assumption, and buyers assume unfavorably because that is the rational thing to do with an unknown. A business that cannot produce a software inventory is assumed to have licensing exposure. A business with no restore test is assumed not to be recoverable. Those assumptions get priced, and the price is almost always worse than the cost of the fix.

The highest-return sell side work, in order:

Build the software and vendor inventory. It is the single most requested artifact and the one most small businesses cannot produce. The fields are already defined; use them rather than inventing a diligence-specific format.

Move anything licensed to an individual into the business name. Do it now, while it is an administrative change, rather than during diligence, when it is a finding.

Run a restore test and keep the evidence. One test, documented, converts an assumption into a fact.

Close the obvious identity gaps. Multi-factor authentication everywhere with no exemptions, and remove access for everyone who has left. Both are free and both are asked about in every questionnaire.

Write down what is in one person’s head. Even a rough runbook removes the key person discount, which is one of the larger adjustments a buyer can justify.

Delete what you do not need. Old records are pure liability. This costs nothing and reduces real exposure.

Reconcile your attestations. Read your own cyber insurance application and your last three client security questionnaires, and confirm the answers are still true. If one is not, fix the control rather than waiting for a buyer to find the gap.

None of that requires a large budget, and all of it is work the business benefits from whether or not a sale happens. That is the argument to make to an owner who is not yet certain about selling.

How a vCIO supports both sides

This is one of the clearest cases for the role, because it needs someone who can read a technical environment and talk to a deal team in the same afternoon, and who is not the incumbent provider. What a vCIO does covers the function generally. In a transaction it splits by side.

On the buy side: scope the review to the deal, run the document request and interviews, produce the three-bucket findings report with arithmetic on the priced items, brief the deal team in their language, sit in the negotiation as the technical voice, and then own the first hundred days plan the diligence produced. That continuity is the argument for using the same person for both. A reviewer who will never have to execute what they wrote tends to write differently.

On the sell side: run the same review against your own business early, fix what is cheap, prepare the artifacts buyers will ask for, and be the person who answers technical questions during diligence so the owner does not have to. A seller with a technology advisor who can answer a buyer’s question in an hour rather than a week visibly changes the tone of a process.

A word on independence. The target’s existing MSP should not run the buy side review. They are being reviewed, their contract is a finding, and their position after close is uncertain. None of that requires bad faith to produce a compromised document. It is the wrong person for the job for the same reason you would not have the seller’s accountant do the quality of earnings work.

Cost sits in the same range as other advisory work at this scale, and how MSPs and vCIOs price this kind of engagement is usually a fixed fee for a defined scope rather than a retainer. Against a typical small business deal, it is a rounding error next to one unfound problem.

What diligence hands the integration plan

The review is not finished when the deal closes. Everything that landed in the third bucket becomes the first hundred days, and the work is already sorted if the report was written properly.

Day one items are narrow and mostly about control: administrative credentials transferred and the old ones revoked, domain and DNS control confirmed, billing contacts changed, backup verified as still running, and anyone who left with the seller removed from every system. An offboarding checklist is the right instrument for that last one, applied to a group rather than a person.

The first quarter is the consent list from the contract review, the security baseline gaps that were priced, and any end of support date falling inside the year. Anything involving a tenant merge or a server move to the cloud is a project with its own plan and its own cost estimate, not a task on a list, and consolidation driven by an acquisition is one of the most common reasons small businesses migrate at all.

Beyond that, the findings become an ordinary technology roadmap and an ordinary budget line. The acquisition simply gave you an unusually complete picture of what belongs in them, which is more than most businesses ever get about their own systems.

Common mistakes

1. Scoping technology last. The review gets two weeks at the end and cannot influence anything. Scope it the week diligence opens.

2. Delivering an inventory instead of an analysis. A list of assets with no cost, no ranking, and no recommendation is raw material. The deal team needed the conclusion.

3. Arguing that everything should reduce the price. Fifteen price adjustments is not a strong position, it is a discounted document. Two real ones and a term change is stronger.

4. Confusing cost with exposure. A known replacement cost belongs in the price. An unknown breach liability belongs in the terms. Putting either in the wrong place gets it handled wrongly.

5. Ignoring deal structure. Asset and stock purchases produce completely different licensing and contract answers. Ask which it is before you start reviewing contracts.

6. Letting the incumbent provider run the buy side review. They are one of the things being reviewed.

7. Missing key person risk because the person is still there. They are there during diligence. Ask whether they are staying, and ask early enough for it to be actionable.

8. Accepting “we have backups” as an answer. The question is when a restore was last tested. The answer is usually never.

9. Skipping the insurance application. It is the document where the business made specific written claims about its own security, and it is often the fastest route to a real finding.

10. Treating the report as the end. The third bucket is the integration plan. If nobody owns it after close, the review was an expensive way to produce a document.

How this fits the rest of your IT

Technology due diligence is the same discipline as the rest of this series, applied under a deadline and to someone else’s environment. The inventory work is what software license management produces continuously. The contract reading is vendor evaluation run in reverse. Sorting findings by what they should change is the same judgment that makes a security report or a disaster recovery proposal approvable rather than merely accurate. And the output feeds straight into IT strategy, because an acquisition is the event most likely to invalidate a plan that was correct the week before.

The businesses that find diligence easy are the ones already running these practices. They do not build anything for the transaction. They hand over documents they already maintain, which is both cheaper and, from the other side of the table, considerably more reassuring than a business scrambling to assemble them. Whether that discipline sits with an internal IT manager or a vCIO matters less than whether it exists at all, and a managed provider maintaining it as part of normal service is how most small businesses get there without adding headcount.

What is next in this series

This article closes the second group in the series. Next is the pillar it has been building toward: virtual CIO services for small business, pulling together what strategic technology leadership actually delivers at this scale, how an engagement is structured and priced, what it looks like across a full year of roadmap, budget, reporting, and vendor work, and how to tell whether your business is at the point where it pays for itself.

How Sequentur can help

If you are looking at an acquisition and technology is the part nobody has scoped, or you are thinking about selling in the next year and would rather find your own problems first, we run this review from either side of the table. Schedule a call.