Due Diligence Monitoring Checklist

Somewhere between "this is a real company" and "we're getting acquired," small businesses encounter due diligence. A prospective investor runs diligence. An enterprise customer sends a vendor security questionnaire — often built on the Shared Assessments SIG^[1] or the Cloud Security Alliance's CAIQ^[2], which are the two dominant standardised questionnaires in the market. An acquirer's team spends a week asking pointed questions about how the business runs.

Most small businesses aren't ready for this moment. Not because their operations are bad, but because they've never thought about their operations from the perspective of someone evaluating them.

This is a checklist of what serious due diligence actually looks at, specifically on the infrastructure and monitoring side, with an eye to what an SMB can do today so the conversation goes smoothly later.

What due diligence is actually checking for

Due diligence isn't a compliance audit. It isn't looking for certifications. It's trying to answer a few simple questions:

1. Can this company operate reliably as we scale it up?
2. Is there hidden risk we haven't priced in?
3. Is the team telling us the truth about how the business runs?

Monitoring and infrastructure questions sit in the middle of all three. Good monitoring is evidence of a reliable operation. Poor monitoring is either a risk or a signal that the team isn't being candid.

The difficulty is that "good monitoring" isn't a certification — it's something the team either demonstrates or doesn't, usually through specific questions and the quality of the answers.

The questions that actually get asked

In roughly declining order of frequency and weight:

"Walk me through what happens when your site goes down." This is the most common opening question. It's looking for: do you know when it goes down? Who finds out? How fast? What's the typical response time? Do you have a post-mortem process? Can you show a recent example?

Bad answer: "We'd know pretty quickly." Good answer: "Here's our monitoring dashboard. Alerts route to [person]. Median response time in the last six months was [X]. Here's our last incident from [date], here's the post-mortem, here's what we changed afterwards."

"How do you handle vendor outages?" Looking for: dependency awareness, fallback thinking, monitoring of third parties.

Bad answer: "Our vendors are reliable." Good answer: "Here's our dependency list. We monitor status for critical vendors. For [X, Y, Z], we have fallbacks configured. For [A, B], we don't, and here's why we've accepted that risk."

"What have you missed?" This is the test question. Diligence teams know every business has had silent failures. They want to know if you know yours. The correct answer isn't "nothing" — that's transparently not true — it's "here's one, here's what we learned, here's what we did about it."

Bad answer: "Nothing comes to mind." Good answer: "Yeah — [specific incident from 2023]. We didn't detect it for two weeks. Here's what we changed so it can't happen again."

"How do you know your customer data is safe?" Not a compliance question (unless you're in a regulated industry). A practical question. Who has access, how is it logged, what would detect a breach.

Bad answer: "We follow best practices." Good answer: "Access is controlled via [mechanism]. Here's who has what. Access reviews happen quarterly — here's the last one. All access to customer data is logged. If there was unauthorised access, here's how we'd detect it."

"Show me an incident you handled well." Looking for a real example, with detail, that demonstrates competence under pressure.

"Show me an incident you handled badly." Looking for honesty and learning. Everyone has one. Not having one to share is the red flag.

The artifacts diligence wants to see

You don't need compliance-level documentation. You need evidence that the basics are in place and maintained. Specifically:

If you have all of this, a diligence conversation on infrastructure goes well. If you're missing half of it, the diligence team will find the gaps, and the gaps will be priced into whatever deal is on the table.

The preparation most SMBs should do

The mistake SMBs make is waiting until diligence is imminent to get this together. It doesn't work — retroactively constructing monitoring history isn't possible.

The preparation is ongoing:

1. Monitor the basics continuously. Domain, SSL, uptime, DNS, email auth, vendor status. The monitoring checklist for SMBs covers the full list.

2. Keep post-mortems for real incidents. Not every hiccup — but real, customer-affecting incidents. A one-page write-up each. Stored somewhere findable.

3. Maintain a dependency list. Updated whenever you add or remove a vendor.

4. Do quarterly access reviews. Note who has what, prune what shouldn't be there, keep the record.

5. Do annual restore drills. Verify backups actually work. Keep a log.

Each of these takes a few hours per quarter. Together they constitute "an infrastructure story that holds up under scrutiny."

The mindset shift

The SMBs that handle due diligence smoothly aren't the ones with compliance programmes. They're the ones who've been running their operations as if someone might ask hard questions — not because of diligence, but because the hygiene is worth having for its own sake.

This is close to the compliance-vs-common-sense argument. Compliance pushes you toward controls that satisfy a framework. Due diligence tests whether the controls are real. The way to pass both is to run the operation well in the first place.

The short version

Diligence teams ask practical questions and look for practical evidence. Monitoring, runbooks, post-mortems, vendor maps, access records. None of it requires a large investment. All of it requires sustained attention.

The pillar on boring IT for SMBs is the full framing; this piece is the specific application. A small business that's been running the pillar playbook for a year or two walks into diligence with most of the answers already prepared — not because they were preparing for diligence, but because they were running operations that happened to be diligence-ready.

That's the goal. Ops good enough that the hard questions have easy answers.

References

1. Shared Assessments, Standardized Information Gathering (SIG) Questionnaire — 855 questions across 19 risk domains, updated annually and mapped to NIST CSF, ISO 27001, PCI DSS, and CCM. sharedassessments.org/sig. ↩
2. Cloud Security Alliance, Consensus Assessments Initiative Questionnaire (CAIQ) — 261 yes/no questions mapped to the CSA Cloud Controls Matrix. cloudsecurityalliance.org. ↩