What operational due diligence is actually testing, and why the technology was never the problem.
What operational due diligence is actually testing, and why the technology was never the problem.
An emerging manager gets a term sheet, or close to one, and then the allocator's operational due diligence team sends over the questionnaire. Somewhere around section six there are forty questions about information security, and the COO forwards them to whoever handles the laptops.
The panic that follows is almost always misdirected. In our experience the firm has most of the technology. What it does not have is a single piece of evidence that the technology exists, has an owner, or has ever been tested.
That distinction is the entire exercise.
An operational due diligence team is not trying to determine whether you have multi-factor authentication. They assume you do. Everyone says they do.
They are trying to determine whether there is an adult in the room. Whether the firm treats operational risk as something that is owned, documented, reviewed, and improved, or as something that gets attention when an investor asks.
They test that by asking for artifacts. And artifacts are the thing you cannot produce on three weeks' notice.
Consider the difference between these two answers to the same question.
"Do you conduct periodic user access reviews?"
Answer A: Yes. Access is reviewed regularly.
Answer B: Yes. Quarterly, via Entra ID access reviews. Site and application owners attest to their own membership lists, with the CFO as fallback reviewer. The last review completed 12 March, covering 14 applications and 31 SharePoint sites. Four stale grants were removed. Review artifacts are retained for 24 months and available on request.
Answer A is what most firms give. It is not a lie. It is worthless, and the ODD analyst has read three hundred of them.
Answer B does not describe better technology. Both firms are running the same Microsoft tenant. Answer B describes a firm that has a process, a cadence, an owner, and a record.
Skim any allocator DDQ and the security section will cover roughly the same ground. Most of it is table stakes. These are the ones where answers diverge sharply, and where a weak answer does real damage.
"When was your incident response plan last tested?" Not "do you have one." Every firm has a document. Very few have run a tabletop exercise, and the ones that have will name the date, the scenario, and what the exercise revealed. If your answer is the date the document was written, the analyst knows exactly what they are looking at.
"Describe your offboarding procedure for an employee with access to sensitive information." This question is doing more work than it appears to. It tests whether your process is a written runbook or a person's memory, and whether it covers the things that are easy to forget: privileged role eligibility, third-party SaaS that is not federated, sharing links the user created, application ownership.
"How do you supervise and retain business communications?" This is where regulatory exposure and IT posture meet, and the enforcement history in this area is not gentle. Off-channel communications on personal devices are a live problem at firms of every size. A confident answer requires that you have both a policy and a technical control, and that they agree with each other.
"Describe your vendor due diligence process." Firms with a five-person operation genuinely do not have one, and saying so honestly is better than inventing one. The good answer describes what you do proportionately: which vendors touch sensitive data, what you require of them, what you review and how often.
"What is your recovery point and recovery time objective, and when did you last test a restore?" Discussed at length in a separate piece. Suffice to say: "our data is in Microsoft 365" is not an answer, and an analyst who knows the difference will note that you do not.
The good news for a firm already on M365 is that most of the artifacts an allocator wants can be produced from the tenant, if you have been running it deliberately.
None of these are exotic. All of them take months of operating history to look credible, and none can be conjured in the three weeks between the questionnaire arriving and the response being due.
You cannot backfill twelve months of quarterly access reviews.
You can write the policy document this week. You can tighten the Conditional Access policies this week. But you cannot produce a record of a process you have not been running, and a sophisticated ODD team can tell the difference between a program and a fire drill. They see both constantly.
The firms that pass cleanly are not the ones with the biggest budgets. They are the ones that started eighteen months earlier, quietly, at a scale proportionate to their size, and then simply had the answers when the questionnaire arrived.
If the questionnaire has already landed, the goal is an honest, specific, well-organized response, and a credible remediation roadmap with dates for the gaps. Allocators do not expect a nine-person fund to have a security operations center. They expect you to know what you have, know what you do not, and have a plan. A candid gap with an owner and a date reads far better than a confident non-answer.
If the questionnaire has not landed yet, and you intend to raise institutional capital in the next two years, this is the cheapest work you will ever do, and it gets more expensive every quarter you wait.
Preparing for operational due diligence?
KYA Consulting builds and evidences the IT posture that institutional allocators expect, for managers who intend to pass diligence rather than survive it.
Get in Touch