Short answer: a buyer's diligence team will ask you for a list of every system the business runs on, who owns each one, what each costs, what happens if it goes down, and who can get in. Most companies of 25 to 300 people cannot produce that list in a week, because nobody inside was ever asked to keep it. The fix is not complicated. It is just owned by nobody, which is why it never gets done until someone with a deadline asks.
This is written as a pattern, not a case. The scene below is a composite of how it tends to go, and it is said to be one.
The scene
A founder of a 90-person distribution company takes a call from her banker on a Tuesday. The letter of intent is signed. The buyer's team will be sending a request list by Friday. She has run this business for eleven years and can answer almost anything about customers, margins, inventory, and people without looking anything up.
The request list arrives. Section seven is titled Information Technology. It has nineteen items.
She forwards it to the office manager, who has handled "the computer stuff" since the company was 30 people. The office manager forwards it to the MSP. The MSP replies within the hour with a PDF of the services agreement and a note that says they would be happy to schedule a call to walk through it.
By the following Tuesday, four of the nineteen items have answers. The CFO has pulled the software line from the general ledger and found it is spread across eleven vendors, three credit cards, and one line simply called "subscriptions." Nobody can say when the last full restore of the file server was tested, only that backups "run every night." The ERP was bought in 2019 by a controller who left in 2023. The warehouse scanning system has a login shared by the whole floor.
None of this is a scandal. It is the normal condition of a company that grew faster than its paperwork. But the buyer's team does not know that, and the longer the answers take, the more it looks like something is being hidden. Two of the open items end up in the purchase agreement as specific representations the founder has to make, and one becomes an escrow holdback.
What they actually ask
The nineteen items vary by buyer, but they cluster into five questions. If you can answer these five in writing, you can answer the whole section.
1. What systems does the business run on, and who owns each one?
Not a network diagram. A plain list: the accounting system, the operating system for the core work (ERP, practice management, estimating, dispatch, whatever runs the business), email and files, payroll and HR, the website and whatever sits behind it, and the handful of tools each department bought on its own. For each one: who inside the company is the owner, meaning the person who decides whether to keep it, change it, or cancel it. Not the admin. The owner.
At most companies this size, the honest answer for several systems is "nobody." That is the answer the buyer is probing for, because an unowned system is one that will surprise the new owner.
2. What does it all cost, and when do the contracts renew?
The buyer will build their own model of technology spend from your general ledger whether you help them or not. If you hand them a clean list first, with the vendor, the annual cost, the renewal date, the notice period, and the number of seats, you control the conversation. If you make them assemble it from credit card statements, they will assume the worst about everything they cannot find.
Renewal dates matter more than people expect. A three-year MSP agreement that auto-renewed six weeks before close is a liability the buyer inherits. They will ask about it, and they will price it.
3. If the core system went down tomorrow, how long until you are running again, and how do you know?
This is the backup and restore question, and it is the one companies most often answer with a feeling rather than a fact. "We back up every night" is a description of a process. The buyer wants the result: when did you last restore something from those backups, what did you restore, how long did it take, and who did it?
If the answer is that a restore has never been tested, say so. It is a far better answer than a confident one that falls apart when the buyer's technical adviser asks for the log.
4. Who can get into what, and what happens when someone leaves?
The buyer is thinking about the week after close, when people start leaving. They want to know whether there is a list of who has administrative rights to the systems in question one, whether the accounts of people who left are actually closed, and whether anything important is tied to one person's personal login. The warehouse scanner with the shared password is a question-four problem. So is the domain registration in the founder's personal email, which comes up more often than anyone would like.
5. Who is accountable for all of the above?
This one is rarely written down, but it is the question behind the other four. The buyer wants to know whether there is a person who holds the whole picture, or whether the picture lives in six heads and a PDF from the MSP. If there is no such person, the buyer will either plan to install one, which costs them money, or will decide that the founder is that person, which costs the founder time during the one stretch when they have none.
Why nobody inside can answer
It is worth being precise about why these questions are hard, because the usual explanation, that the company is "behind on IT," is wrong and leads to the wrong fix.
The company is not behind. It has a working MSP, the systems run, and the business makes money. What it does not have is ownership of the decisions. The MSP owns the tickets and the monitoring, which is their job and they are usually good at it. The office manager owns the vendor relationship because someone had to. The CFO owns the invoices. The controller who bought the ERP owned the ERP, until she left. Each piece has a custodian. No piece has an owner who is accountable for the whole, and nobody is paid to keep the list that a buyer wants on day one.
That is also why the MSP's PDF does not answer the request list. The services agreement describes what the MSP does. It cannot describe what the company owns, what it should be paying, or what a buyer would consider a risk, because the MSP was never asked those questions and is not neutral on the answer to one of them.
The second reason is timing. The request list arrives in a window when the founder and the CFO are already working the longest hours of the year on the parts of the deal that move the price. Technology questions get the hours left over, which is none. So the answers come late, incomplete, or from someone who is guessing, and all three of those outcomes cost more than the hour it would have taken to write the list down in the spring.
What to write down this quarter
If a transaction is anywhere in your next two years, these are the five documents to have before anyone asks. None of them requires a project. Each one is a page or two.
The system list. One table. Columns: system, what it is used for, owner inside the company, vendor contact, annual cost, renewal date, notice period, number of users, where the data lives. Put the ones that run the business at the top. Expect the first draft to have gaps in the owner column. The gaps are the finding.
The spend summary. Pull every technology line from the ledger for the trailing twelve months and reconcile it to the system list. Anything on the ledger that is not on the list is either a system nobody told you about or a subscription nobody uses. Both are worth knowing before the buyer finds them.
The restore record. Pick the one system the business cannot run without. Have the MSP or whoever manages it restore a meaningful piece of it to a test location, time it, and write down the date, what was restored, how long it took, and who did it. Do it once a quarter from now on. A single dated entry changes the answer to question three from a feeling to a fact.
The access list. For each system on the system list, who has administrative rights, and the date each departed employee's access was closed. Then the short list of things tied to an individual rather than the company: domain registrations, the main vendor accounts, the bank's online portal, the social accounts. Move them to company-owned accounts with two people on each.
The MSP scorecard. Three questions to put to the MSP before the next renewal, in writing: what is in scope and what is not, what they would need from you to meet the restore time you want, and what they would recommend changing if the contract were being signed fresh today. Their answers, and how long they take to arrive, tell you most of what a buyer will conclude about them.
A founder with these five pages answers section seven in a day instead of three weeks, and the buyer's technical adviser spends their time confirming what is written rather than discovering what is not. That difference shows up in the purchase agreement.
The objection
The usual objection is that this is premature. The sale is a year or two out, maybe more, and there are more pressing things to do.
That is fair, with one adjustment. The five pages are not for the buyer. They are for the company. A system list with an owner column is how you find out that two departments are paying for the same thing, that the MSP contract has drifted from what the business does, and that the one person who knows how the estimating software is configured is retiring in March. Those are this year's problems with a deadline attached. The buyer just happens to ask about the same things.
Questions founders and CFOs ask next
Does the buyer's diligence team actually read all of this? The technical adviser does, usually within the first week, and their summary goes to the deal lead in a page or two. The deal lead reads the summary. What the deal lead remembers is whether the answers were fast and specific or slow and vague, and that impression shapes how hard they push on everything else in the section.
Our MSP says they can handle the request list. Should I let them? Let them supply the technical facts they hold: the backup configuration, the inventory of devices, the licenses they manage. Do not let them be the only voice, because several of the questions are about the MSP, and because the buyer wants to hear from someone inside the company who owns the decisions. If nobody inside can play that role, that is the gap to close before the request list, not after.
How far in advance does this need to be done? The system list and the access list can be built in two to four weeks of part-time attention by whoever owns finance, with the MSP supplying the technical details. The restore record needs one real test, which can be scheduled for any quiet week. Starting a quarter before the banker is engaged is comfortable. Starting after the letter of intent is signed is possible but expensive, because every hour comes out of the deal.
What if the answers are bad? Then you know, and you have time to fix the ones that matter or disclose the ones that do not. A buyer who finds a problem you disclosed treats it as a known cost. A buyer who finds a problem you did not know about treats it as a reason to look harder at everything.
We are not selling. Is any of this worth doing anyway? The spend summary alone usually pays for the time. The rest is the difference between technology that is managed and technology that is tolerated, and a company of this size that intends to keep growing will hit the second one's limits with or without a buyer in the room.
If this is the seat nobody at your company owns, and a transaction is somewhere on the horizon, grab any 30 minutes here and we can walk through the five pages against what you have today.
About the author. Spencer Scherer leads Newf Advisory, the fractional technology leadership division of Newf Technology, Inc., where he is also co-founder and CTO. He works with companies of 25 to 300 people whose technology has outgrown whoever has been handling it: vendors and MSPs, license spend, backup and restore, and the technology questions that come up before a transaction. He previously led IT at a New York litigation firm and a software company, and was the senior IT lead for three operating subsidiaries of a national construction services company. He holds an M.S. in Information Systems Technology from The George Washington University.