Most nonprofits depend on outside organizations to help them operate.
Those third parties may provide:
- donor management
- payment processing
- payroll
- accounting
- cloud hosting
- websites
- case management
- human resources
- IT support
- cybersecurity
- marketing
- fundraising platforms
- file sharing
- communications
Those services make the mission possible.
They also create dependency.
A nonprofit can outsource the technology, but it cannot automatically outsource the consequences if that technology fails, is compromised, or exposes sensitive information.
That is why third-party cyber risk should begin with five practical questions:
- What does this vendor do for us?
- What systems or information can they access?
- What happens to the mission if they fail?
- What responsibilities still belong to us?
- What evidence tells us the relationship is being managed appropriately?
The goal is not to audit every vendor like a cybersecurity company.
The goal is to understand which third-party relationships could materially affect the organization.
Third-Party Risk Begins With Dependency
A vendor is not automatically a cyber risk simply because the nonprofit uses its service.
Risk grows when the organization depends on the vendor.
Consider a donor management platform.
It may support:
- donor records
- giving history
- fundraising campaigns
- receipts
- communications
- reporting
- integrations with payment systems
If the platform is unavailable for two hours, the impact may be small.
If it is unavailable during a major fundraising campaign, the consequences could be more significant.
The technology did not change.
The organizational context did.
That is why third-party risk should be discussed in terms of dependency and impact, not just vendor names.
Not All Vendors Need the Same Level of Attention
A nonprofit may use dozens of outside services.
Treating every vendor as equally important would create unnecessary work.
A more useful approach is to group vendors based on what they do and what happens if something goes wrong.
Lower-Dependency Vendor
A service used occasionally that does not have access to sensitive information or mission-critical systems.
Important Vendor
A provider that supports meaningful business activity, but whose failure would be inconvenient rather than severely disruptive.
Mission-Critical Vendor
A provider whose outage, compromise, or loss could materially interrupt programs, fundraising, financial operations, communications, or access to sensitive information.
This simple distinction helps leadership focus attention where it matters most.
Educational Example: The Donation Platform
Imagine a nonprofit receives a significant percentage of annual donations online.
The organization uses a third-party platform to:
- collect donor information
- process online giving
- send receipts
- manage recurring donations
- provide campaign reporting
Leadership may think:
“The vendor handles that.”
Technically, that may be true.
But the nonprofit still depends on the outcome.
If the platform becomes unavailable during a year-end campaign, fundraising could be interrupted.
If donor information is exposed, supporters are unlikely to view the issue only as the vendor’s problem.
They gave their information to the nonprofit.
That is why third-party risk is partly about understanding the gap between:
who operates the technology
and
who experiences the consequence.
Start With a Vendor Dependency Map
The easiest way to understand third-party risk is to map where outside providers support the mission.
Start with important activities such as:
- accepting donations
- serving constituents
- running payroll
- paying vendors
- managing employees
- communicating with donors
- storing important records
- operating the website
- processing financial transactions
- delivering programs
Then ask:
Which vendors make this activity possible?
For example:
| Mission Activity | Third Party | What They Support |
|---|---|---|
| Online donations | Donation platform | Giving, donor records, receipts |
| Payment processing | Payment processor | Credit card transactions |
| Payroll | Payroll provider | Employee compensation |
| Cloud provider | Communication and collaboration | |
| Case management | SaaS provider | Constituent services |
| IT support | Managed provider | Systems, devices, access, support |
This gives leadership a much clearer picture of where the organization relies on outside parties.
Question 1: What Does the Vendor Actually Do for Us?
This sounds simple.
It is not always simple in practice.
Over time, a vendor may begin with one responsibility and gradually gain more.
An IT provider may start with user support and eventually manage:
- Microsoft 365
- network equipment
- endpoint protection
- administrator credentials
- backups
- security monitoring
A donor platform may begin as a contact database and later become connected to:
- online payments
- email campaigns
- accounting
- event registration
- analytics
Leadership should understand the real role the vendor plays today, not only the original contract.
Ask:
- What business process depends on this provider?
- Which teams use it?
- Is the service optional or mission-critical?
- Which other systems connect to it?
- Who inside the organization owns the relationship?
That is the first layer of third-party visibility.
Question 2: What Systems or Information Can the Vendor Access?
A vendor does not have to store your information to create risk.
It may be able to access it.
Outside providers may have access to:
- donor records
- financial information
- employee information
- constituent records
- cloud systems
- administrative accounts
- servers
- network equipment
- security tools
- payment systems
- sensitive files
The leadership question is:
“If this vendor’s account or environment were compromised, what could someone reach?”
That is often more useful than asking:
“Is the vendor secure?”
No organization can guarantee perfect security.
What leadership can understand is the potential impact of the access being granted.
Educational Example: The Vendor Account Nobody Remembered
Imagine a nonprofit changes website providers.
The old provider finishes the project and the contract ends.
Six months later, someone discovers that the former vendor still has administrator access to the website and an associated cloud account.
Nothing bad has happened.
But the access is no longer necessary.
This is a common type of third-party risk because access can outlive the business relationship that justified it.
A simple vendor offboarding process could ask:
- Which accounts did the vendor use?
- Which permissions did they have?
- Have those permissions been removed?
- Did they have shared credentials?
- Are any API keys or integrations still active?
- Is the vendor still listed as an administrator anywhere?
The goal is not to distrust vendors.
It is to make sure access matches the current relationship.
Question 3: What Happens to the Mission if the Vendor Fails?
Every important vendor should be viewed through the mission.
Ask:
- Can we operate if the vendor is unavailable?
- For how long?
- Is there a manual workaround?
- Can we export our data?
- Can we communicate with constituents another way?
- Is there another provider we could use?
- Does the organization know who to contact during an outage?
The answer may be very different depending on the vendor.
If a marketing design tool is unavailable for a day, the impact may be small.
If payroll is unavailable on payday, the issue is different.
If a constituent-management platform is unavailable during a critical program period, the consequences may be greater still.
Third-party risk becomes useful when it is connected to the mission.
Educational Example: Vendor Outage During a Fundraising Campaign
Imagine a nonprofit launches its largest annual giving campaign.
The donor platform becomes unavailable for several hours.
The outage is entirely outside the nonprofit’s network.
Still, the nonprofit may face:
- missed donations
- disrupted campaign momentum
- staff confusion
- delayed donor communication
- board questions
- uncertainty about transactions already submitted
The nonprofit did not cause the technical failure.
But the organization still experiences the operational consequence.
If donor information were also involved, reputational, regulatory, or legal questions could emerge.
That is why vendor dependency belongs in a Cyber Liability conversation.
Question 4: What Responsibilities Still Belong to the Nonprofit?
Outsourcing a service does not necessarily transfer every responsibility.
This is one of the most important concepts in third-party risk.
A vendor may operate the platform.
But the nonprofit may still be responsible for decisions such as:
- what information is collected
- who is given access
- how long information is retained
- which vendors are selected
- whether contracts are reviewed
- whether insurance requirements are met
- whether legal or regulatory obligations apply
- how donors or constituents are communicated with after an incident
That division of responsibility can become confusing.
The organization should know where the vendor’s responsibility ends and its own begins.
Shared Responsibility Should Be Clear Before Something Goes Wrong
Many technology relationships are based on shared responsibility.
For example:
A cloud provider may secure the infrastructure.
The nonprofit may still be responsible for:
- user accounts
- passwords
- MFA
- permissions
- data handling
- employee behavior
- configuration decisions
A payment processor may handle transactions.
The nonprofit may still have responsibilities related to:
- its website
- access
- integrations
- policy
- documentation
- applicable payment requirements
A managed IT provider may maintain systems.
Leadership may still be responsible for:
- approving budgets
- accepting risk
- selecting vendors
- setting organizational policy
- deciding what information can be stored
- providing governance
That is why the question:
“Isn’t the vendor responsible for that?”
often deserves a more careful answer.
Contracts Can Help Clarify Responsibility
Leadership does not need to become contract counsel.
But important vendor agreements should make key responsibilities easier to understand.
Depending on the relationship, useful questions may include:
- Who owns the data?
- Can we retrieve our data if the relationship ends?
- How does the vendor protect access?
- What happens if the vendor experiences a security incident?
- Will we be notified?
- How quickly?
- Who is responsible for what?
- Are there limits on subcontractors?
- What happens when the contract ends?
- Are there service availability commitments?
- What insurance does the vendor maintain?
These questions are especially useful for high-dependency vendors.
Not every small vendor requires the same level of contract review.
The depth of review should match the potential impact.
Question 5: What Evidence Tells Us the Relationship Is Being Managed?
Third-party risk should not rely entirely on trust or assumptions.
That does not mean every nonprofit needs to perform a technical security audit of every vendor.
Evidence can be appropriate to the relationship.
Depending on the provider, leadership might review:
- security documentation
- contract terms
- insurance information
- compliance documentation
- service reports
- incident-notification terms
- access lists
- administrator accounts
- backup or recovery commitments
- onboarding and offboarding records
The point is not to collect documents for the sake of collecting them.
The point is to know enough about important relationships to make an informed decision.
Not Every Vendor Needs a 50-Question Security Questionnaire
Third-party diligence can become excessive.
A small nonprofit might use dozens of outside services.
Sending a large security questionnaire to every provider is unlikely to be practical.
A better process is proportional.
Low-Impact Vendor
Basic ownership and access information may be enough.
Moderate-Impact Vendor
Review access, sensitive information, dependency, and contract terms.
High-Impact or Mission-Critical Vendor
Consider deeper diligence, including security evidence, contractual responsibilities, recovery expectations, incident notification, and ongoing review.
This keeps the process realistic.
The strongest risk-management process is not always the most complicated one.
It is the one the organization can actually maintain.
A Simple Four-Level Vendor Risk Model
A nonprofit can use a practical classification model.
Level 1: Limited Risk
The vendor has little or no access to sensitive information and limited mission impact.
Examples may include:
- design tools
- noncritical subscriptions
- public information services
Level 2: Business Support
The vendor supports important work but does not control a mission-critical function.
Examples may include:
- marketing tools
- scheduling services
- collaboration platforms
Level 3: Sensitive Access
The vendor stores or accesses important data or administrative systems.
Examples may include:
- payroll
- HR systems
- donor platforms
- IT providers
Level 4: Mission Critical
Failure or compromise could materially interrupt the mission, expose sensitive information, or create significant regulatory, legal, or reputational consequences.
Examples may include:
- core donor platforms
- payment processors
- case-management systems
- key cloud infrastructure
- mission-critical managed services
The exact categories can be adjusted.
The point is to give leadership a way to decide which relationships deserve more attention.
Third-Party Risk Can Affect All Four Areas of Cyber Liability
A vendor incident may begin outside the organization.
The consequences can still affect all four Cyber Liability areas.
Operational
Can programs, fundraising, payroll, or services continue if the vendor is unavailable?
Reputational
Could donors, constituents, employees, partners, or funders lose trust?
Regulatory
Does the vendor store or process information subject to requirements?
Legal
Could contracts, notification duties, privacy obligations, or insurance responsibilities become involved?
That is why vendor risk is not just a procurement issue.
It is an organizational risk.
Educational Example: One Vendor, Four Risks
Imagine a nonprofit uses a cloud-based donor platform.
The provider experiences a security incident.
Leadership might ask:
Operational
Can the fundraising team still access the donor system?
Reputational
Could donor confidence be affected?
Regulatory
Is protected, payment-related, or otherwise regulated information involved?
Legal
What notification, contractual, insurance, or other responsibilities apply?
The board does not need to understand how the vendor’s systems were attacked.
It needs to understand what the event means to the organization.
Vendor Selection Is Only the Beginning
Many organizations perform due diligence before signing a contract and then never revisit the relationship.
But vendors change.
The nonprofit changes too.
Over time:
- access may expand
- new integrations may be added
- more information may be stored
- contract terms may change
- ownership may change
- subcontractors may change
- the service may become more mission-critical
- regulatory requirements may evolve
That means vendor risk should be reviewed periodically, especially for important providers.
The question is not:
“Did we review them once?”
It is:
“Does our understanding of the relationship still match reality?”
A Vendor Review Does Not Have to Be Complicated
For an important provider, an annual review might ask:
- What does the vendor do for us today?
- What systems or information can they access?
- Has their access changed?
- Is the service more critical than it was last year?
- Did the vendor experience any significant incidents we should understand?
- Are contract terms still appropriate?
- Do we still need the service?
- What happens if we have to replace the vendor?
That can be enough to keep the relationship visible.
Offboarding Is Part of Vendor Risk Management
Vendor relationships eventually end.
That should trigger a deliberate process.
When a relationship ends, consider:
- remove accounts
- revoke administrative access
- disable integrations
- rotate shared credentials
- retrieve organizational data
- confirm data disposition
- remove API keys
- update contact information
- identify replacement responsibilities
- document the termination
A vendor that no longer works with the organization should not retain unnecessary access.
The same principle applies to consultants, contractors, temporary service providers, and former technology partners.
What Happens if the Vendor Holds Your Data?
This deserves special attention.
Before relying heavily on a third-party platform, leadership should understand:
- Can we export our information?
- In what format?
- How long would that take?
- What happens if the vendor shuts down?
- What happens if we terminate the contract?
- Are backups available?
- Is there a process for data return or deletion?
- Are there costs associated with retrieving information?
This becomes especially important for systems containing:
- donor data
- financial records
- constituent information
- employee records
- program information
The organization should avoid discovering during a crisis that access to its own information depends entirely on a vendor relationship it no longer controls.
Educational Example: Data Exists, But Can We Get It Back?
Imagine a nonprofit has used the same cloud application for seven years.
The platform contains thousands of donor and program records.
Leadership decides to switch providers.
Only then does the organization learn that exporting some information is straightforward, while several years of historical records require a special paid migration process.
Nothing has been breached.
There is no cyberattack.
But the organization has discovered a dependency it did not fully understand.
Third-party risk is not only about attacks.
It is also about control, access, continuity, and the ability to change direction.
How Should Leadership Prioritize Vendor Risk?
Use the same principles discussed earlier in the Knowledge Center.
Ask:
Mission Impact
What happens if this provider becomes unavailable?
Data Sensitivity
What information can the provider access or store?
Access
Can the vendor reach administrative or mission-critical systems?
Regulatory Complexity
Do contracts, insurance, payment requirements, privacy obligations, or other standards apply?
Replaceability
Could the organization switch providers if necessary?
Existing Safeguards
What controls already reduce the risk?
Evidence
What do we actually know about the relationship?
A vendor that scores high in several of these areas deserves more leadership attention.
A Simple Vendor Risk Inventory
The organization does not need complicated software to begin.
A spreadsheet may be enough.
Consider columns such as:
| Vendor | Service | Data Access | System Access | Mission Impact | Owner | Review Date |
|---|---|---|---|---|---|---|
| Donation platform | Online giving | High | Moderate | High | Development | Annual |
| Payroll provider | Payroll | High | Moderate | High | Finance | Annual |
| Design tool | Marketing | Low | Low | Low | Marketing | As needed |
| IT provider | IT support | High | High | High | Executive | Quarterly/Annual |
The point is visibility.
If leadership cannot identify its most important vendors, that is a useful place to start.
Five Questions for Every Mission-Critical Vendor
For the vendors that matter most, leadership should be able to answer five questions.
1. What do we depend on this vendor for?
Be specific.
2. What can the vendor access?
Understand systems, information, and administrative privileges.
3. What happens if the vendor is unavailable?
Think in terms of mission continuity.
4. What responsibility remains with us?
Clarify shared responsibility.
5. How do we know the relationship is still appropriate?
Use evidence, periodic review, and documentation.
Those five questions are more useful than asking:
“Is this a secure vendor?”
Security is not a yes-or-no condition.
Risk is contextual.
The Board Does Not Need to Review Every Vendor
Board members do not need a list of every subscription the nonprofit pays for.
They should know about vendors whose failure or compromise could materially affect the organization.
A useful board-level summary might include:
- top mission-critical vendors
- significant access or data dependencies
- major changes since the last review
- unresolved concerns
- regulatory or contractual considerations
- major incidents
- planned replacements
- accepted third-party risks
That keeps the board focused on consequence rather than procurement detail.
What Should a Nonprofit Leader Take Away From This Chapter?
Third-party systems make modern nonprofit work possible.
They also extend the organization’s Cyber Liability beyond the systems it directly controls.
You do not need to treat every vendor as a threat.
You do need to understand the relationships that matter.
Start with five questions:
- What does the vendor do for us?
- What systems or information can they access?
- What happens to the mission if they fail?
- What responsibilities still belong to us?
- What evidence tells us the relationship is being managed appropriately?
That creates clarity.
It also helps leadership distinguish between ordinary vendors and relationships that deserve more oversight.
The goal is not to eliminate third-party risk.
That is impossible.
The goal is to understand which dependencies matter, manage them proportionately, and make informed decisions about the risk the organization is willing to carry.
Applying the Education: How MTS Helps Clients See Third-Party Risk
MTS looks at third-party risk as part of the broader Cyber Liability picture.
The focus is not only on whether a vendor appears secure.
The more useful questions are:
- What does the organization depend on the vendor for?
- What access exists?
- What information is involved?
- What happens if the vendor becomes unavailable?
- What Operational, Reputational, Regulatory, or Legal impact could follow?
- What decisions should leadership make?
This is particularly important for nonprofits because donor systems, payment platforms, cloud services, IT providers, and other third parties can become deeply connected to the mission.
MTS helps leadership create clarity around those dependencies, understand what evidence is available, and identify which vendor relationships deserve greater attention.
The client remains the decision-maker.
The goal is not to create another compliance exercise.
It is to help leadership see where third-party dependency creates meaningful Cyber Liability and decide what to do about it.
A Practical Next Step
Choose your five most important vendors.
For each one, answer:
- What do they do for us?
- What can they access?
- What information do they hold?
- How long could we operate without them?
- What responsibility would still belong to us if something went wrong?
You will probably learn more about your third-party risk from those five conversations than from a long list of vendor names.
Continue Learning
Previous Chapter
Chapter 7: What Do Backup and Recovery Have to Do With a Nonprofit’s Mission Continuity?
Next Chapter
Chapter 9: What Should Nonprofits Know About AI, Sensitive Data, and Cyber Liability?
AI tools can create tremendous value for nonprofit organizations.
They can also introduce new questions about:
- sensitive information
- donor data
- employee use
- approved versus unapproved tools
- vendor risk
- privacy
- governance
- accountability
Chapter 9 will focus on how nonprofit leaders can use AI responsibly without treating every new tool as either completely safe or completely dangerous.
