Last week's post covered two breaches, at a managed IT provider and at a nonprofit software platform, that hit hundreds of small organizations through no fault of their own systems or staff. The organizations affected did not lack security awareness. What most of them lacked was a habit: asking a short set of questions before signing a contract, and writing the answers down somewhere they could find them again.
That habit is the entire subject of this post. You do not need a procurement department. You do not need a security questionnaire with two hundred line items that no vendor will actually complete. You need five questions, asked every time, before access is granted and before the contract is signed.
Before anything else, get specific about scope. A tool that only needs your organization's name and a billing email is a fundamentally different risk than one that requests full access to your email system, your donor database, or your file storage. Vendors, and the staff signing up for their tools, tend to grant broader access than necessary because the broader option is usually the default during setup.
This question also surfaces a category of risk many small organizations miss entirely: the tools staff sign up for on their own, sometimes called shadow IT. A well-meaning employee connecting a scheduling app to the shared calendar, or a project tool to the file drive, can grant access nobody in leadership ever evaluated.
- Before approving any new tool, ask what specific data or systems it needs to connect to, and whether a narrower option exists.
- Periodically review connected apps and integrations in your email, file storage, and donor or CRM platforms. Most platforms have a settings page listing every third-party app with access.
- Remove anything connected that nobody can explain the purpose of.
Every vendor holding meaningful data should be able to tell you, in plain language, what they commit to if they are breached. How quickly will they notify you? What information will they share about what was exposed? Who is responsible for notifying the people whose data it actually is, your donors or clients, versus the vendor's own customers, which is you?
The Blackbaud breach covered in last week's post is instructive here. Affected nonprofits found out about a breach that happened at their vendor, and then had to manage their own donors' expectations and notifications based on information the vendor controlled. Knowing the notification commitment in advance does not prevent a breach, but it tells you what to expect and how fast, instead of finding out for the first time in a crisis.
- Ask directly: "If you have a data breach, how and how quickly will you notify us?" A vendor that cannot answer this clearly is telling you something.
- Check whether the vendor's contract or terms of service specify a notification timeframe. If it is vague, ask for it in writing.
- For your highest-risk vendors, note the answer somewhere your team can find it quickly if something goes wrong.
You do not need to evaluate a vendor's entire security program. You need to confirm the same fundamentals covered in the earlier posts on this blog: does the vendor require multi-factor authentication for accounts that access your data? Do they encrypt data at rest and in transit? Have they had a security incident before, and if so, what changed afterward?
Larger, more established vendors will often point you to a security page, a SOC 2 report, or a trust center. Smaller vendors and individual contractors usually will not have formal documentation, and that is fine. The goal is a direct answer to a direct question, not a certification. A vendor who gets defensive or evasive about basic security questions is telling you something a glossy compliance badge would not.
- Ask whether MFA is required for any account or portal that accesses your data, and whether you can require it for your organization's users specifically.
- Ask whether data is encrypted in transit and at rest. You are checking for a confident, specific answer, not grading the technical details.
- Ask if they have had a security incident in the past two years, and if the answer is yes, ask what changed as a result. A vendor that has been through an incident and improved is often a better bet than one that has never been tested.
The Kaseya attack covered in last week's post did not compromise your MSP directly in most cases. It compromised a tool your MSP relied on. This is the fourth-party risk problem: your vendor has its own vendors, and their weaknesses become yours without you ever signing a contract with them.
You will not always get a full answer to this question, and that is a realistic limitation, not a failure on your part. But asking it accomplishes two things. It signals to the vendor that you are paying attention, which tends to produce more candid answers to the other questions. And for your highest-risk vendors, the ones holding financial data or sensitive client information, it is worth the extra five minutes to understand whether your data is passing through a chain of other companies you have never heard of.
- For your top two or three most critical vendors, ask what other companies or subprocessors have access to your data as part of delivering their service.
- Check whether the vendor publishes a subprocessor list, many larger SaaS platforms do, usually linked from their trust or privacy page.
- Do not expect a complete map. A partial answer that shows the vendor understands its own supply chain is a good sign in itself.
The moment nobody thinks about when signing a contract is the moment they end it. What happens to your data when the relationship ends, whether by your choice or theirs? Is it returned to you in a usable format? Is it deleted, and on what timeline? Can you get a written confirmation of deletion?
This question matters for two reasons. First, a vendor relationship that becomes a security liability, because the vendor was acquired, changed ownership, or simply stopped investing in security, is much easier to exit if the offboarding terms were clear from the start. Second, data that lingers in a former vendor's systems long after you stopped using them is exposure you no longer have any visibility into or control over.
- Before signing, read the termination section of any contract or terms of service. Look specifically for what happens to your data.
- Ask for written confirmation of data deletion as a standard part of offboarding any vendor relationship that involved sensitive data.
- Keep a simple list of which vendors currently hold sensitive data, so that when a relationship ends, deletion does not get forgotten.
What five questions actually gets you
None of these questions require technical expertise to ask or to evaluate the answer to. They require the discipline to ask them every time, not just for the vendors that feel obviously risky. The tool a well-meaning staff member signs up for in an afternoon carries the same underlying questions as the six-figure contract with your donor database provider. The stakes differ. The questions do not.
Where this fits into the bigger picture
Asking these questions consistently does something beyond reducing individual vendor risk. It builds a record. If something does go wrong at a vendor down the line, you will already know what data they had, what they committed to, and how to reach them, instead of scrambling to reconstruct that information during an active incident.
The next post in this series addresses a belief that quietly undermines all five of these questions before they ever get asked: the assumption that outsourcing your IT to a managed service provider means someone else has already handled security. It has not, and understanding why is the difference between real protection and a false sense of it.
Want a second set of eyes on your highest-risk vendor relationships?
A 30-day Security Business Review includes a practical review of your critical vendors, not a two-hundred-question audit, just the gaps that actually matter and a prioritized way to close them.
Start a Conversation