Nonprofit Website Vendor Risk Audit | Ops Director Guide

Your finance team audits supplier relationships. Your HR team reviews employment contracts. Your safeguarding lead reviews policies annually. Nobody reviews your website vendor relationships — until something goes wrong, at which point you discover you don't hold the domain, the agency has closed, or the plugin your entire site depends on stopped being maintained eighteen months ago.

The Vendor Stack You May Not Know You Have

A typical nonprofit website depends on more vendors than most operations directors realise. Each represents a dependency, a contract (formal or informal), and a point of failure.

The Annual Vendor Risk Questions

Ownership and Access

For each vendor relationship: does the organisation hold direct access credentials, independent of any third party? Are renewal notifications going to an organisational email address rather than an individual's personal or work email? Has access been tested recently — not assumed to exist, but actually verified?

Contract and Commercial Terms

What are the notice periods for each vendor relationship? What happens to your data and assets if a relationship terminates? Are there auto-renewal clauses that could create unexpected commitments? For agency relationships: does the contract specify who owns intellectual property created during the engagement?

Business Continuity

What is the organisation's plan if each of these vendors became unavailable tomorrow — through closure, acquisition, or service discontinuation? Which dependencies would cause the most immediate operational disruption? Which have acceptable alternatives, and which are effectively irreplaceable in the short term?

Security and Compliance

When were vendor credentials last rotated? Are any shared credentials used across multiple platforms — a practice that creates single points of failure? Do any vendor integrations have access to personal data that isn't covered by your current privacy notice? Are any plugins or extensions no longer actively maintained — which means security vulnerabilities are no longer being patched?

The Twelve-Month Review Schedule

A practical annual review assigns responsibility for each vendor category and sets a calendar for when each is reviewed. For most organisations, this means:

Quarterly: check that all renewal notifications are going to live organisational email addresses. Verify that CMS and hosting credentials work. Confirm that the donation flow is functioning end-to-end.

Annually: review all vendor contracts for renewal terms and ownership provisions. Audit plugin and extension maintenance status. Rotate credentials for any shared access accounts. Confirm that backup processes are functioning and that a restore has been tested.

When to Escalate to the Board

Any vendor risk that could result in the website going offline for more than 24 hours, any compliance failure that creates regulatory exposure, or any single-vendor dependency with no identified contingency should be escalated to the board as a governance risk. The board cannot manage what they aren't aware of — and website vendor risk is consistently underreported at trustee level.

Further Reading

• The Real Cost of Developer Dependency in Nonprofit Websites
• What Happens to Your Website When Your Lead Developer Leaves
• Why Your Nonprofit Website Is a Governance Liability
• NGO Websites Are Governance Problems Not Design Problems

What Risk-Aware Web Infrastructure Feels Like

Operations directors who run this audit for the first time almost always find something they didn't know existed — a subscription renewing to a departed staff member's email, a plugin that hasn't been updated in two years, a hosting account that technically belongs to the agency rather than the organisation. Finding these things proactively, before they become incidents, is the entire point.

The organisations that manage web vendor risk well don't have fewer vendor relationships — they just know what they have, who owns it, and what happens if any part of it fails. That knowledge is the difference between a manageable incident and an operational crisis.

Q1: What is a vendor risk audit for nonprofit web infrastructure?

A vendor risk audit is an annual review of all the third-party providers and tools that the nonprofit's website depends on, assessing: the risk each vendor represents if it becomes unavailable, the terms of each vendor relationship, the data each vendor accesses and how it is protected, and the organisation's dependency on each vendor relative to available alternatives. It produces a risk register for the web infrastructure and a set of actions to reduce the highest-priority risks.

Q2: Which vendors should be included in a nonprofit website vendor risk audit?

The audit should cover: domain registrar, web hosting provider, CMS platform, content delivery network, DNS provider, SSL certificate provider, payment processors, CRM integration, email marketing platform, analytics tools (GA4, Microsoft Clarity), cookie consent platform, form handling tools, social media scheduling tools integrated with the site, and any third-party APIs used by the site. Any service that the website depends on to function should be included.

Q3: What are the highest-risk vendor dependencies for nonprofit websites?

The highest-risk dependencies are typically: domain registration (if this lapses, the site becomes unreachable and email fails — sometimes irreversibly), hosting (if the provider terminates the account or closes, the site goes offline), and the primary CMS (if the platform changes its pricing model or terms significantly, migration can be costly and disruptive). Secondary risks include payment processors (affecting donation capability) and email platforms (affecting donor communication). Risk is assessed as probability multiplied by impact — domain and hosting have low probability but catastrophic impact.

Q4: What should a nonprofit check when auditing its domain registration?

Check: the domain is registered in the organisation's name (not an individual's), the renewal date and whether auto-renewal is enabled, the email address that receives renewal notices and whether it is an organisational rather than personal address, whether the domain is locked against unauthorised transfer, the registrar's process for account recovery if access is lost, and whether the domain registration also controls DNS (common but creates a single point of failure). Domain failures are among the most disruptive and potentially irreversible web infrastructure risks.

Q5: How should a nonprofit assess the financial stability of its web vendors?

For critical vendors (hosting, CMS platform, payment processor), assess: how long the company has been operating, whether it is profitable or VC-funded (VC-funded companies have higher closure risk), what the community or user base size is (larger is more stable), what the contractual terms are if the service closes, and whether the organisation's data can be exported in a portable format if migration becomes necessary. This assessment doesn't need to be exhaustive — it should focus on the vendors where loss of service would be most damaging.

Q6: What contracts should a nonprofit have in place with web vendors?

Written agreements (terms of service, data processing agreements, or formal contracts) should exist with: any vendor that processes personal data (GDPR requirement for data processing agreements), vendors providing services valued at more than £1,000 annually, and vendors whose termination would require significant migration work. The agreements should specify: data ownership and portability, notice period for service termination, liability limitations, and support terms. Many nonprofits have no formal contracts with their web vendors — which means all terms are the vendor's default terms of service.

Q7: What is a data processing agreement and which vendors need one?

A data processing agreement (DPA) is a GDPR-required contract between a data controller (the nonprofit) and a data processor (any vendor that processes personal data on the nonprofit's behalf). Vendors that require DPAs include: analytics platforms (Google Analytics, Microsoft Clarity), email marketing platforms (Mailchimp, Campaign Monitor), CRM systems (Salesforce, HubSpot), form handling tools, payment processors, and any other vendor that receives or processes data about the nonprofit's donors, beneficiaries, or staff. Operating without DPAs where they are required is a GDPR compliance failure.

Q8: How should a nonprofit reduce vendor concentration risk in its web infrastructure?

Vendor concentration risk occurs when multiple critical functions depend on the same vendor — for example, using the same company for domain registration, hosting, and email. If that vendor experiences a problem, all three functions fail simultaneously. Reducing concentration risk means distributing critical functions across independent vendors: domain registration separate from hosting, hosting separate from email, analytics separate from CRM. This creates more vendor relationships to manage but eliminates single points of failure.

Q9: What should trigger an unscheduled vendor risk review outside the annual audit cycle?

Unscheduled reviews should be triggered by: a vendor announcing significant pricing changes or terms of service updates, a vendor being acquired by another company, a significant outage or security incident affecting a vendor, a change in the organisation's data handling practices that affects existing vendor agreements, a new regulatory requirement affecting vendor relationships, or a staff change that affects who manages vendor relationships. Treating the annual audit as the only review point misses material changes between cycles.

Q10: How does a vendor risk audit connect to a nonprofit's broader organisational risk management?

Web infrastructure vendor risks should appear in the organisation's operational risk register alongside other key operational risks. The risk register entry should note: the vendor and the dependency, the assessed probability and impact of failure, the current mitigations in place, and the residual risk level. The board should be aware of the highest-rated web infrastructure risks in the same way it is aware of financial, reputational, and programme risks. Web infrastructure is operational infrastructure — its risks belong in operational risk management.