Signing up a vendor takes ten minutes. Getting rid of one takes months, and sometimes you cannot.

That gap is the whole reason vendor diligence exists. It matters more in estate technology than almost anywhere else, because of one uncomfortable fact: you have promised to hold someone's records until they die and often for years afterwards. Your vendors have made no such promise. They have a standard contract, a startup runway, and a product roadmap that can change next quarter.

The questions below are the ones that decide whether a vendor is safe to depend on. Thirty of them, grouped by what you are trying to find out. Not every question applies to every vendor. A design tool does not need the same scrutiny as the service holding your encryption keys.

Before you start, do one thing: decide how sensitive the data is that this vendor will touch. A vendor that sees nothing personal gets five questions. A vendor that holds identity documents or encrypted records gets all thirty. Applying the full list to everything is how diligence turns into theatre and then gets skipped entirely.

Group 1: Will they still exist? (Questions 1 to 5)

Most vendor checklists start with security. For a product with a multi decade obligation, survival comes first. Perfect security from a company that shuts down in three years is not useful to you.

1. How long has the company existed and how are they funded? You are not asking for their cap table. You are asking whether this is a going concern or a project.

2. Are they profitable, or how long is their runway? Ask directly. Serious vendors answer at some level. Evasion is itself an answer.

3. What happens to our data if they are acquired? Acquisitions change pricing, terms, and priorities. Ask what notice you get and whether you can exit without penalty.

4. What happens if they shut down? Look for a written wind down commitment: notice period, data export window, and whether the export is complete. "We would work with you" is not a commitment.

5. Is this their core product or a side feature? Side features get deprecated. If the thing you depend on is not how they make money, assume a three year life and plan accordingly.

Group 2: Where does the data live? (Questions 6 to 10)

6. Which countries will our data be stored in? Get the actual list, including backups and disaster recovery locations, which are frequently in a different country than the primary.

7. Can we pin storage to a specific region? Some customers and some regulators require it. Retrofitting this later means a migration.

8. Where do their support staff work from? If support in another country can view customer records, that is a cross border transfer regardless of where storage sits.

9. Do they use subprocessors, and who are they? Ask for the current list and whether you get notice before it changes. Your vendor's vendors are your vendors.

10. What is the legal basis for any cross border transfer? For personal data moving across borders, there needs to be an actual mechanism, not just a sentence in a policy.

Group 3: Security basics (Questions 11 to 17)

11. Do they have a current independent security report? SOC 2 Type 2 or ISO 27001. Ask for the report itself, not the badge on the website. Then read the exceptions section, which is where the useful information is.

12. Is data encrypted at rest and in transit, and with what? The answer should be specific. Vagueness here is a signal.

13. Who at the vendor can access our data, and is that access logged? The strongest answer is that nobody can, because they only ever hold encrypted content they cannot decrypt. The next best is a named, small, logged group.

14. Can we get access logs for our own data? If someone at the vendor opens a record, can you find out? For an audit trail you may need to defend for years, this matters.

15. How do they handle security incidents? You want a notification window in hours, a named contact, and evidence they have run the process at least once.

16. Do they run penetration tests, and can we see a summary? Annual at minimum, by an external firm.

17. Do they run a vulnerability disclosure or bug bounty programme? It signals a company that wants to hear bad news rather than avoid it.

Group 4: The contract (Questions 18 to 22)

18. Who owns the data? It should be you, stated plainly. Read carefully for any licence they grant themselves.

19. Can they use our data to train models or improve their product? Ask explicitly and get the answer in writing. Default terms increasingly allow this. For estate data the answer must be no.

20. What is the data processing agreement, and does it cover subprocessors? Standard for anything touching personal data. If a vendor does not have one ready, they are not used to handling personal data.

21. What is the liability cap? Usually twelve months of fees, which is close to meaningless if they lose your customers' records. You will rarely negotiate this as a small company, but you should know the number before you concentrate risk with them.

22. Can they change terms or pricing unilaterally, and with what notice? Watch for terms that let them modify anything with thirty days notice. That is not a contract, it is a subscription to their goodwill.

Group 5: Getting out (Questions 23 to 26)

The exit questions matter more than the entry questions, and almost nobody asks them.

23. Can we export everything, and in what format? Specifically: all data, including files and metadata, in an open format. A vendor whose export is a CSV of half your records has locked you in.

24. How long does an export take at our expected volume? Test this before you scale, not after. Some exports are rate limited to the point of uselessness.

25. What is deleted on termination, when, and how do we get proof? You need this for your own retention obligations.

26. What would migrating away actually involve? Sketch the migration before you sign. If the honest answer is a six month project, you should know that on day one.

Group 6: Operations (Questions 27 to 30)

27. What uptime do they commit to, and what happens when they miss it? Service credits are not compensation. They are an apology with a number attached. Look at their public incident history instead.

28. How much notice do we get for breaking changes? Ask how they handled the last one. Past behaviour beats policy.

29. What support do we get and how fast? Get response times for a genuine emergency, in writing. Free tier support means you have no support during your worst hour.

30. Do we have a named contact? For any vendor holding sensitive data, a person who answers the phone matters more than a portal.

How to actually run this

Four rules keep diligence from becoming a ritual nobody does.

Tier your vendors. Three levels. Vendors that hold sensitive personal data get all thirty questions and an annual review. Vendors that hold internal business data get about half and a review every two years. Vendors that hold nothing sensitive get a short form. Most vendors fall in the third group.

Write down the answers. Not the documents, the answers. One page per vendor with the date and who checked. When an auditor or a large customer asks how you assess vendors, you hand over the pages.

Set a review date. Answers go stale. A vendor that was fine two years ago may have been acquired, changed its terms, or quietly moved storage. Annual for the top tier.

Keep the list current. The single most common failure is not asking bad questions. It is not knowing a vendor exists because someone signed up with a company card. Tie the vendor list to your billing, not to memory.

The three answers that should stop you

Most diligence produces small concerns you accept and note. Three answers are different.

"We can use customer data to improve our services." For estate data, this is disqualifying unless they will amend it in writing.

No meaningful export. A vendor you cannot leave will eventually raise prices or change direction, and you will have no response.

Evasion on where data physically sits. Any vendor that cannot answer this quickly either does not know, which is worse, or does not want to say.

Why this matters more here than elsewhere

An ordinary software company that picks a bad vendor has a bad quarter. They migrate, they complain, they move on.

A company holding wills has a different problem. The data cannot be recreated. The obligation lasts decades. And the moment the data is needed most is the moment a family is least able to cope with you saying that your provider had an issue.

Thirty questions before signing is a small price for that. The vendors worth having answer them without friction. The ones that resist have told you something useful for free.

Frequently Asked Questions

What is vendor diligence?

It is checking, before you sign, whether a supplier can be trusted with your data and your obligations. For products holding sensitive records it covers security, data location, contract terms, exit rights, and whether the vendor will still exist in a few years.

Which vendors need full diligence?

Any vendor that stores, processes, or can view personal data. Cloud hosting, storage, identity verification, payments, email, analytics, and support tools usually qualify. Tools that never touch customer data need a much shorter check.

What is the most overlooked question?

How you get your data out. Exit terms are rarely checked at signing and are the hardest thing to fix later.

Is a SOC 2 report enough on its own?

No. Read the report rather than the badge, especially the exceptions, and pair it with questions about data location, contract terms, and exit.

How often should vendors be reviewed?

Annually for vendors holding sensitive data, every two years for the rest, and immediately after any acquisition or major terms change.

What should be disqualifying?

Terms allowing your customer data to be used for training or product improvement, no meaningful data export, and an inability to say where data is physically stored.

Sources

Further reading: