Your data does not live only with you. It lives with your CRM vendor, your email vendor, your payment processor, your accounting software, your backup service, and a dozen other suppliers you may not have thought about since the day you signed up. If any one of them is breached, your data might leak, and the people whose records were exposed will not draw a careful distinction between your organization and your supplier. You cannot control what a vendor does. What you can do is assess them before you hire them, contractually require them to protect the data, and audit them periodically. This lesson covers all three.

The Vendor Risk Assessment

Before signing with a vendor, assess their security maturity. This does not require a security background; it requires a questionnaire and the willingness to send it. The value of a written questionnaire is partly the answers and partly the response itself, because a vendor's reaction to being asked tells you a great deal about how they think about the data they are about to hold on your behalf.

Basic questions, for every vendor

• Where do you store data, meaning which country and which data center?
• Is data encrypted in transit, over HTTPS, and at rest?
• What is your data retention policy if we leave?
• How do you handle customer data if you get breached?
• Do you have cybersecurity insurance?
• Can we audit your security practices?
• Do you have SOC 2 or ISO 27001 certification?

Advanced questions, for vendors handling sensitive data

• What is your incident response process?
• Do you have a bug bounty program?
• How do you vet your own vendors, since your vendor has vendors too?
• What security training do your employees receive?
• Do you have a security officer or a security team?

The red flags are consistent across both lists. The vendor is evasive. They claim "we are secure" without offering evidence. They describe encryption as optional. They do not carry insurance. They have never had a security audit. Any one of those is a reason to slow down, and the pattern behind all of them is the same: a vendor who treats a security questionnaire as an obstacle rather than a normal part of procurement is telling you how they will treat your incident report later.

The Data Processing Agreement

Your contract with a vendor should specify how they handle data. Most vendors have a Data Processing Agreement, a DPA, that you can review, and reviewing it before signature is far easier than renegotiating it after something has gone wrong. The terms that matter are these:

• The vendor must implement reasonable security.
• The vendor must notify you immediately if they are breached.
• The vendor must not use your data for their own purposes.
• The vendor must delete or return your data when you leave.
• You have the right to audit their security practices.
• The vendor carries cyber liability insurance.

Do not sign contracts that allow vendors to sell your data, use it for their own marketing, or share it with anyone. If a vendor pushes back on those points, consider a different vendor; the pushback is the information. Note how the six terms work together rather than separately. The notification clause is what makes your own breach obligations achievable, since you cannot notify your donors about something you have not been told. The audit right is what makes the security clause enforceable rather than aspirational. And the deletion clause is what stops your data continuing to sit somewhere long after the relationship has ended.

Vendor Audit Checklist

For your most critical vendors, meaning the CRM, the payment processor and the accounting system, conduct an audit annually. The audit is not a technical exercise; it is a set of confirmations you can make from your desk.

• Review their latest security audit report, whether SOC 2 or equivalent.
• Confirm they are following your DPA terms on data encryption, retention and deletion.
• Check whether they have had breaches, by searching news coverage and monitoring their status page.
• Request proof of cyber liability insurance, and check both the amount and the coverage.
• Verify that they have disclosed any subcontractors, meaning the vendors they themselves use.

Document this annually, because the value of an audit is largely in the comparison with last year's answers. If a vendor fails the audit, escalate rather than filing it away: can they remediate, and by when? If they cannot, start planning a migration to a different vendor before the situation forces one on you at a worse moment.

Managing Multiple Vendors

Create a vendor inventory. For each vendor, record what data they hold, how sensitive it is, and how critical they are to your operations. The inventory is what turns vendor risk from an anxiety into a work plan, because it tells you where to spend the limited attention you have. A short version looks like this:

The cadence follows the sensitivity column. Audit critical vendors annually. Audit medium sensitivity vendors every two years. Audit low sensitivity vendors as needed. That schedule is deliberately uneven, because attempting to audit everything at the same depth means auditing nothing properly, and the payment processor and the file-sharing tool do not carry the same consequences if they fail.

Vendor Exit Plan

What happens if a vendor goes out of business, or you simply need to switch? The questions to answer are the ones that become impossible to research once the vendor stops responding to email.

• Can you export all your data in a standard format such as CSV or JSON?
• How long does the vendor keep your data after you leave?
• Is there a data deletion request process?
• What is the transition timeline, whether 90 days, six months, or something else?

Get those answers before you need them. A vendor going dark while holding your data is a nightmare, and the two questions that turn it into a survivable inconvenience are export format and retention period. The first determines whether you can leave at all; the second determines how long your data continues to exist somewhere you no longer have any influence over.

Red Flag Vendors

• No security certifications. SOC 2 and ISO 27001 are the standard. If a vendor has neither, the question to ask is why not.
• Unclear data practices. "We are secure" without specifics usually means they are not, because a vendor with real controls finds them easy to describe.
• No cyber insurance. If they are not insured, they are not treating security seriously, and you have no financial backstop behind their promises.
• Refuses a DPA. Legitimate vendors will sign a Data Processing Agreement. If they refuse, walk away.
• Overseas data storage. Some countries have weak data protection. Ask where the data is stored, which is why that question is first on the basic list.

Incident: A Vendor Gets Breached

A vendor notifies you that they were breached and your data might have leaked. Work through the following sequence in order, because each step supplies information the next one needs.

1. Get details. What data was involved? How many people? When did they discover it?
2. Review the DPA. Did they meet their obligations to notify you, investigate, and everything else the agreement requires?
3. Assess impact. Is this a breach affecting your donors? If it is, you likely have to notify them.
4. Contact your insurance. Let them know.
5. Plan notification. If your donor data was exposed, you notify your donors. The vendor notifying their own customers does not discharge that.
6. Consider changing vendor. If this is the second breach, or if it was preventable negligence, evaluate moving.

The point that organizations most often get wrong is in step five. You are liable to your donors even when the breach was the vendor's fault. The relationship your supporters have is with you, and the obligations that attach to their data are yours regardless of which company was holding it at the moment it leaked. That is the whole reason vendor choice and vendor auditing matter: you are not outsourcing the risk when you outsource the system, you are only outsourcing the control.

Anti-Patterns

• Assessing security only for the systems that feel technical. The email platform and the file-sharing drive hold personal data just as the CRM does, and they are usually adopted with less scrutiny.
• Accepting "we are secure" as an answer. A claim without evidence, a certification, or a report behind it is a marketing statement.
• Signing the DPA without reading the data use clause. The clauses that let a vendor use, share or monetize your data are the ones you cannot fix later.
• Auditing once, at procurement. Certifications lapse, subcontractors change, and companies get acquired. An annual confirmation for critical vendors is the minimum.
• Treating a vendor breach as the vendor's problem. Your donors are yours to notify, and your liability does not transfer with the data.
• Having no exit plan. If you have never confirmed that you can export your data in a standard format, you have not chosen this vendor, you have been captured by them.
• Ignoring the vendors your vendors use. Subcontractors hold your data too, which is why disclosure of them belongs in the audit.
• Disqualifying any vendor that has ever been breached. The response matters more than the incident, and a vendor that has never been tested is not the same as a vendor that has never failed.

Practice Prompts

• Build your vendor inventory with the four columns used above, and do not stop at the systems finance pays for. Include anything holding donor, beneficiary, volunteer or staff data.
• Mark every row in that inventory as critical, medium or low, then assign each one an audit cadence: annually, every two years, or as needed.
• Send the basic questionnaire to the vendor holding your most sensitive data, and note not only the answers but how long they took and how willingly they were given.
• Pull the DPA for your CRM and check it against the six key terms, marking which are present, which are weaker than stated here, and which are absent.
• For your payment processor and your CRM, answer the four exit questions in writing today, while nothing is wrong.
• Write the first three steps of your response to a vendor breach notification, naming the person who performs each one.
• Identify which of your vendors have disclosed their own subcontractors, and ask the ones that have not.

Reflection

Think about the vendor holding your most sensitive data and ask yourself, honestly, how they were chosen. In most nonprofits the answer involves a recommendation, a price, and a demo, and does not involve a security questionnaire or a reading of the data processing terms. That is not negligence so much as sequence: the tool was selected to solve a program problem, and the data implications arrived afterwards with nobody assigned to think about them. The useful question is therefore not whether your past selections were rigorous, but who owns that question now. If a breach notification arrived from that vendor this week, would anyone in your organization know where the agreement is, what it promises, and who is supposed to read it?

Glossary

• Third-party vendor risk. The exposure created by data your organization holds that physically lives in someone else's systems.
• Data Processing Agreement (DPA). The contract governing how a vendor handles your data, covering security, breach notification, permitted use, deletion on exit, audit rights and insurance.
• SOC 2. A security audit standard. A Type II report means an independent auditor verified the vendor's security over a period rather than at a single moment.
• ISO 27001. An international information security certification, treated alongside SOC 2 as a standard credential for vendors handling data.
• Encryption in transit. Protection of data while it moves between you and the vendor, indicated by HTTPS.
• Encryption at rest. Protection of data while it sits stored on the vendor's systems.
• End-to-end encryption. Encryption where even the vendor cannot read the data, which sometimes prevents them from providing the service at all, and which is therefore not a reasonable universal requirement.
• Cyber liability insurance. Coverage a vendor carries against the cost of a breach, and a signal of whether they treat security as a real risk.
• Subcontractor. A vendor used by your vendor, which may hold your data without ever having contracted with you.
• Bug bounty program. A vendor's standing offer to pay researchers who report security flaws, which indicates active rather than assumed security work.
• Vendor inventory. The record of which vendor holds what data, at what sensitivity, and how critical each one is.
• Exit plan. The answers to how you get your data out, in what format, how long they keep it afterwards, and how long the transition takes.

Related Lessons

The internal controls that sit alongside vendor management are covered in Cybersecurity for Nonprofits: The Essential Checklist, and the notification sequence in the incident section is developed fully in Incident Response Planning: What to Do When You Get Breached. Your obligations to the people whose data a vendor holds are set out in Donor Data Privacy: Your Legal and Ethical Obligations and, jurisdiction by jurisdiction, in State Privacy Law Compliance for Nonprofits: A Practical Matrix, with GDPR for Nonprofits with International Supporters covering supporters outside the United States. For vendors that process data through AI systems, see Data Privacy and AI: A Nonprofit Compliance Guide. On the selection side, Nonprofit CRM Comparison: Salesforce vs. Bloomerang vs. Neon One vs. Kindful and Moving to the Cloud: A Nonprofit Migration Guide are where these questions belong in the buying process, and the staff behaviors that protect the accounts themselves are in Staff Cybersecurity Training: The 1-Hour Program That Sticks.

Closing

Your vendors are extensions of your security posture, whether or not you manage them that way. Assess them before you hire them, using a questionnaire you actually send. Require contractual commitments to protect the data, and read the clauses about what they may do with it. Audit the critical ones annually and the rest on a slower cycle. Keep an inventory so you know which is which. And answer the exit questions while the relationship is healthy, because they are unanswerable once it is not. None of this requires a security team, only the decision that these questions belong to someone. Your data is only as secure as your weakest vendor, and the weakest one is usually the one nobody has looked at since the day it was purchased.

Key Takeaways

• Your data lives with your CRM, email, payment, accounting and backup vendors. A breach at any of them can expose it.
• Assess security maturity before signing, using a basic questionnaire for every vendor and a deeper one for those handling sensitive data.
• Red flags: evasiveness, unevidenced claims of being secure, optional encryption, no insurance, no security audit history.
• The DPA should require reasonable security, immediate breach notification to you, no use of your data for the vendor's own purposes, deletion or return of data on exit, audit rights, and cyber liability insurance.
• Never sign terms letting a vendor sell your data, use it for their marketing, or share it. If they push back, choose another vendor.
• Audit critical vendors annually, medium sensitivity vendors every two years, and low sensitivity vendors as needed, documenting each round.
• Keep a vendor inventory recording what data each holds, how sensitive it is, and how critical the vendor is.
• Answer the exit questions in advance: export format, post-departure retention, deletion process, and transition timeline.
• After a vendor breach, get details, review the DPA, assess impact, contact insurance, plan your own notification, and consider changing vendor.
• You are liable to your donors even when the breach was the vendor's fault. Outsourcing the system does not outsource the obligation.

Frequently Asked Questions

Is SOC 2 certification required? Not required, but it is the gold standard. SOC 2 Type II, as opposed to Type I, means an independent auditor verified their security for at least six months. Most vendors you would want to work with have it. If a vendor does not, ask why. They might be a startup, since new vendors sometimes do not have it yet, and that is acceptable if they carry cyber insurance and will sign a DPA.

Can we demand encryption before a vendor signs with us? You can ask, but do not make it a blocker. Most modern vendors encrypt. If a vendor specifically refuses encryption, that is suspicious. But do not reject a vendor because they do not offer end-to-end encryption, where even they cannot see the data, since that sometimes breaks their ability to serve you at all. Data encrypted in transit and at rest is the standard to hold them to.

Should we pay more for a vendor with better security? Usually, yes. Once you factor in breach risk, the cheaper vendor with weak security can turn out to be the more expensive choice. That said, major vendors such as Salesforce, Google and Stripe offer strong security at reasonable prices, so paying more is not automatically buying more. You do not need to overpay to be well protected.

What if a vendor has had a breach in the past? Not disqualifying. Everyone gets hacked eventually. What matters is how they responded: did they notify customers quickly, did they fix the vulnerability, did they improve their security afterwards? A vendor that had one breach and fixed it is less risky than a vendor that has never been hacked, which may only mean never tested. Look at their incident response, not just the breach itself.

Do we need to conduct security assessments ourselves or hire someone? For major vendors with SOC 2 certification, reviewing their certificate and their DPA is sufficient. For smaller vendors, or vendors with access to sensitive data, hire a third party such as a security consultant to assess them. That costs money, and for your genuinely critical vendors it is worth it.

How do we handle vendors our vendors use? Ask about them directly, both in the advanced questionnaire and in the annual audit, where verifying disclosed subcontractors is one of the checks. Your data can reach a company you have never contracted with, so the question of how a vendor vets its own suppliers is a real part of assessing your exposure rather than a technicality.