Due Diligence: Why Everyone Keeps Asking You the Same 200 Questions

This is the diligence you encounter when someone may invest in your business, acquire your company, purchase a substantial portion of it, buy certain assets, or otherwise put meaningful capital at risk.

This version of diligence has one central concern: is this business really worth what we think it is, and is there anything lurking under the floorboards? Because investors and buyers are not just purchasing your revenue. They may also be inheriting your contracts, your employees, your liabilities, your technology, your regulatory problems, your intellectual property, your vendor relationships, your security weaknesses, your customer concentration, and, occasionally, something everyone wishes had been mentioned several meetings ago.

This is why M&A diligence can feel extraordinarily broad. The financial team wants financial statements. Legal wants contracts, BAAs, and IP. Security wants security logs, incident reports, and testing records. Operations wants process documentation. Technology wants architecture, backlog, and product roadmaps. Compliance wants policies, training records, customer disclosures, and third-party audit reports.

Someone wants board minutes from 2023. Nobody remembers why. But they want them.

Traditional diligence breaks into financial, legal, operational, commercial, and IT and cybersecurity workstreams. Each examines a different part of the same basic question: what risks and opportunities actually exist inside this business?

What buyers and investors are really looking for

Suppose your company says: we have a highly diversified customer base. The buyer may want to see the revenue breakdown, because "highly diversified" and "one customer is 48% of revenue" are not generally considered synonyms.

Suppose you say: we own our technology. Fantastic. Can you prove that? Were developers employees? Contractors? Did they sign IP assignment agreements? Did anyone build a critical part of the product before joining the company? Are third-party licenses properly accounted for?

Suppose you say: we take security seriously. Also fantastic. Now please prove it. Show us your policies, your penetration test, your incident history, your risk assessment, your tabletop exercises, your third-party security audit, evidence of remediation, and possibly a screenshot proving the thing you wrote in policy is actually occurring in practice.

This is a recurring theme in diligence: claims get you through the door. Evidence gets you a seat at the table.

The biggest mistake in funding or M&A diligence

Companies often stay in pitch mode far too long. Pitch mode is: we have incredible technology, an experienced team, a huge market opportunity, and tremendous upside. Due diligence mode is: great. Please pull back the curtain and show us the details.

The transition can be jarring. Fundraising and sales reward a compelling story. Diligence asks whether the story survives contact with the paperwork.

And this is where small inconsistencies become big credibility problems. The sales deck says one thing. The privacy policy says another. The security questionnaire says something slightly different. The contract says something else entirely.

Now everyone has questions. Not necessarily because the company is doing anything wrong. Sometimes the company simply grew faster than its documentation. But diligence does not know the difference until you explain it.

Now let's say nobody wants to buy your company. They just want to buy your product.

Excellent. Surely this will be easier. Sometimes.

Unless your prospective customer turns out to be a hospital system, a bank, a Fortune 500 company, a state government agency, an insurance company, or any organization with a procurement department that considers 200 questions a light warm-up.

This version of diligence usually focuses less on what your business is worth and more on the risk you introduce to the customer. They are asking: if we let you into our ecosystem, what could go wrong for us?

That question can cover cybersecurity, privacy, data handling, regulatory compliance, business continuity, incident response, disaster recovery, subcontractors, insurance, financial stability, access controls, encryption, vulnerability management, employee training, data retention, and fourth parties you did not realize had become fourth parties.

Yes, fourth parties are a thing. No, nobody enjoys explaining them.

Why the customer cares so much

Imagine your company provides a SaaS application. From your perspective: we sell software. From the customer's perspective: you may process our customer information, connect to our systems, rely on five other vendors, store data somewhere in "the cloud", and become an additional way something unpleasant and costly could happen.

Slight difference in perspective.

The larger or more regulated the customer, the more likely they are to have formal vendor-risk requirements. They may be required by internal policy, customer commitments, regulation, audit expectations, cybersecurity frameworks, contractual obligations, or all of the above to demonstrate that they evaluated you before onboarding you.

In other words, sometimes the question is not merely: do we trust this vendor? It is: can we prove that trusting this vendor was a reasonable decision? That distinction explains a lot.

The most dangerous button in customer diligence

The "yes" button.

When a big deal is waiting on a questionnaire, everyone becomes very enthusiastic about the word yes. Do you maintain 24/7 monitoring? Yes. Do you conduct annual disaster recovery testing? Yes. Do all vendors undergo formal risk assessments? Yes.

Do you possess technology developed by benevolent aliens and certified by NIST? Absolutely, we're on the leading edge!

If it gets the contract signed, someone in sales may be tempted to check yes. This is how companies accidentally create obligations they do not actually meet.

A questionnaire is not a test where the company with the most yeses wins. It is where proactive risk management and reasonable action plans stand out. A mature answer can be: no, and here is the compensating control that addresses the risk. That answer is infinitely better than a confident fiction that later finds its way into a contract.

Because enterprise diligence has an interesting habit of beginning as: do you do this? And ending several weeks later as: vendor shall do this.

Pay attention to that transition. One is a question. The other is a legally binding promise.

Now we get to the fun one. Strategic partnerships. Joint ventures. Embedded products. Deep integrations. Banking-as-a-Service relationships. Co-branded offerings. Distribution arrangements.

Relationships where two organizations are not simply buying and selling something. They are operating together.

This version of diligence is deeper because the risk is shared. Your partner is not only asking: are you secure? They may be asking: can our security programs work together?

Not only: do you have an incident response plan? But: if an incident happens, who calls whom, who investigates it, who decides whether it is reportable, who notifies customers, and which one of us is answering the regulator?

This is where things get interesting.

Banking-as-a-Service is a perfect example

Say a fintech wants to launch a financial product through a bank partner. From 30,000 feet: the fintech has a cool product. The bank has banking infrastructure and market reach. Everyone works together. Customers rejoice.

Wonderful.

Down at ground level, someone now needs to answer. Who performs customer identification? Who monitors transactions? Who handles complaints? Who approves advertising? Who performs sanctions screening? Who oversees vendors? Who handles suspicious activity? Who retains which records? Who owns which data? Who manages security incidents? Who reports regulatory issues?

What gets escalated? To whom? How quickly? And what happens if either party does not do the thing it promised to do?

Congratulations. You are no longer completing a questionnaire. You are designing a relationship. A marriage of sorts. That is the fundamental difference with strategic-partner diligence.

Why good companies still struggle here

A company can have a perfectly respectable security program and still be unprepared for a strategic partnership.

Why? Because having controls is not the same as having interconnected controls.

You may have an incident response plan. They have an incident response plan. Terrific. But if neither plan explains how the two organizations coordinate during the same incident, we have discovered a new problem.

You may have a vendor management program. They have a vendor management program. Also terrific.

Whose model is used to evaluate a vendor's inherent and residual risk? Who monitors it? Who gets notified if that vendor has an incident? Who can terminate it? Who approves a replacement?

This is why strategic partnership diligence often evolves into responsibility matrices, governance models, escalation procedures, joint policies, contractual operating requirements, reporting obligations, audit rights, monitoring routines, and recurring oversight meetings.

The questionnaire may start the conversation. It never finishes it.

Here is the easiest way to see the difference. Someone asks: do you have an incident response plan?

Seems straightforward, right? Not really.

The investor is thinking: could an improperly handled cyber incident materially affect the value of this company? The enterprise customer is thinking: if your environment is breached while holding our data, can you respond appropriately and protect us? The strategic partner is thinking: if something happens in our shared ecosystem, can our organizations respond in time and minimize the fallout together?

Same question. Three risks. Three decisions.

Now try another one: do you use third-party vendors?

Investor: are there dependencies that could affect the value or continuity of this company? Customer: will somebody else receive or process our information? Strategic partner: which third parties become part of our combined operating and regulatory environment?

Again: same question. Different question.

This is why copying and pasting your last diligence response into the next questionnaire without thinking is dangerous. The underlying facts should remain consistent. The context will often change.

Companies often approach diligence like fifth grade homework. Question. Answer. Question. Answer. Upload. Submit. Done.

Except it is not done.

Because the questionnaire is usually just the first round. The answers generate document requests. The documents generate questions. The questions generate calls. The calls generate follow-up questions. The follow-up questions generate a request for a screenshot of a configuration setting maintained by the one engineer who happens to be on vacation in Fiji.

This is normal.

Good diligence is iterative because the reviewing party is trying to validate information, distinguish actual problems from theoretical ones, and understand how material each issue is. That is the process in every serious diligence framework: define scope, gather documents, assess risks, conduct interviews where necessary, and turn the findings into something decision-makers can actually use.

So the goal is not: finish the spreadsheet. The goal is: give the other party enough confidence to make the decision.

I have completed more due diligence exercises than I can count, and a few patterns show up over and over. Not actually millions, though. That disclaimer is for the niche group of 1990s wrestling fans and UDAP warriors in the audience.

First, nobody owns the process. Sales has some answers. IT has others. Legal has a few contracts. Finance has the insurance. HR knows about training. The CEO has a document saved locally called FINAL_Final_Updated_CompanyInfo_v6_USETHISONE.docx.

And now someone has to assemble all of this by noon Eastern on Thursday.

Diligence works much better when one person or team consistently coordinates the response.

Second, everyone answers in isolation. This is how contradictions happen. Security says data is retained for 30 days. Legal says 90 days. The privacy policy says "as long as necessary". Engineering says: wait, we save that?

None of these people are necessarily being dishonest. They just have different pieces of the puzzle. Good diligence requires cross-functional review.

Third, the company confuses documentation with reality. Having a policy does not prove the process happens. Not having a beautiful policy does not automatically mean the company has no control.

Reviewers often care about both: what are you supposed to do, and can you prove you actually do it?

A policy saying access is reviewed quarterly is lovely. Evidence showing the review happened is lovelier.

Fourth, gaps are treated like state secrets. Companies sometimes believe they must appear flawless. Sophisticated reviewers know better. Every company has gaps.

The real question is whether the gap is known, understood, owned, prioritized, and being addressed appropriately.

"We do not currently have that control" is not always fatal. "We have a control addressed in policy but had no idea it was failing" is considerably less comforting.

Fifth, the answers are technically correct but strategically useless. Question: do you encrypt data? Answer: yes.

Technically an answer. Not a particularly helpful one.

A stronger response may explain encryption in transit, encryption at rest, key management, scope, relevant standards, and any exceptions.

You do not need to write War and Peace: The Encryption Edition. But you should answer enough of the question behind the question that the reviewer does not immediately have to ask three more questions or schedule a deep dive call.

Despite the drama surrounding these exercises, finding an issue does not automatically implode a deal.

Often it changes the conversation.

An investor may adjust valuation. A buyer may require remediation before closing. A customer may request a contractual commitment. A partner may require additional monitoring. A risk may be accepted. An implementation may be phased. A control may be strengthened. A responsibility may be clarified.

That is what diligence is supposed to do. It takes uncertainty and turns it into something the parties can make a decision about.

Diligence findings are useful because they allow parties to negotiate, plan for integration, address risks before closing, and create ongoing monitoring where the relationship continues.

The purpose is not to discover that everyone is perfect. That would be a very short industry.

And then there is the part nobody tells you.

Due diligence is usually described as a risk-management exercise. It is. But for a growing company, it is also something else: due diligence is a growth gate.

Think about when these questionnaires arrive. Right before funding. A major customer. An acquisition. A strategic partnership. A market expansion. A bank relationship.

In other words, some of the most painful operational work tends to appear at exactly the moment something very good is trying to happen.

That is why treating diligence as random administrative work is a mistake. The 237 questions are not merely paperwork. They are the final yards sitting between your company and a significant growth event.

And that reframes the exercise.

You are not completing a security questionnaire. You are helping close a customer. You are not organizing corporate records. You are helping complete an investment. You are not mapping operational responsibilities. You are helping launch a partnership.

This is why I think about due diligence through the lens of three growth pathways.

Funding: can someone put capital behind this business with confidence? Customers: can a sophisticated organization safely buy from this business? Partnerships: can another organization safely build something alongside this business?

Different opportunities. Different risks. Different diligence.

It is one business saying to another: we like where this is going. Before we commit, help us understand what we need to know.

Sometimes that means financial statements. Sometimes it means a SOC 2 report. Sometimes it means your cap table. Sometimes it means an architecture diagram. Sometimes it means explaining why Question 164 asks whether your office has a fire suppression system when your entire company works remotely.

There will be moments.

But the goal is always the same: reduce uncertainty, understand risk, make a decision.

And ideally, get everyone comfortable enough to say: yes, let's move forward.

Which is considerably more exciting than: question 237 of 237. Although, to be fair, finishing question 237 feels pretty good too.

Related reading: explore AskDegree solutions when you need an owner for the whole diligence workload, or use the Security Questionnaire Response Plan when a buyer's questionnaire has just landed.