Vendor Risk in Nonprofit Web Infrastructure: What to Audit Annually
Key takeaways
- A nonprofit website is a collection of third-party dependencies — hosting, domain, CMS, CDN, payment, email, forms, analytics and plugins — each a vendor relationship that is rarely actively managed.
- The annual review should question each vendor across four areas: ownership and access, contract and commercial terms, business continuity, and security and compliance.
- Confirm that the organisation itself holds direct access credentials and that renewal notifications go to an organisational email address rather than an individual's, then verify that access actually works.
- Set a review rhythm — quarterly checks on renewals, CMS and hosting access and the donation flow; annual review of contracts, plugin maintenance status, credential rotation and tested backups.
- Escalate to the Board any risk that could take the site offline for more than 24 hours, any compliance failure creating regulatory exposure, or any single-vendor dependency with no contingency.
- The highest-risk dependencies are usually domain registration and hosting — low probability but catastrophic impact — because a lapsed domain can make the site unreachable and break email.
Summary
A nonprofit website is not a single piece of infrastructure — it is a collection of third-party dependencies, each of which represents a vendor relationship that may or may not be actively managed. The hosting provider, the domain registrar, the analytics platform, the donation software, the email marketing integration, the cookie consent manager, the form handling service, and the CMS platform are all vendors whose terms, security practices, data processing arrangements, and service continuity policies directly affect the organisation’s website governance.Most nonprofits have not reviewed these vendor relationships since they were established. Some of the vendors in their technology stack may have changed ownership, altered their terms of service, raised their prices significantly, been subject to security incidents, or shifted their service in ways that affect the organisation’s GDPR compliance or data governance obligations. A vendor that was appropriate when selected may no longer be appropriate — but without an annual audit, there is no governance process to identify and act on that change.This post covers the annual vendor risk audit that operations directors and Communications Directors should conduct on their nonprofit web infrastructure: how to compile the complete vendor inventory, what to assess for each vendor, how to prioritise the vendor relationships that represent the highest institutional risk if they fail or change, what the governance response should be when a vendor assessment identifies a significant risk, and how to document the audit in a way that gives the Board assurance that the organisation’s web infrastructure is being actively monitored rather than assumed to be functioning as originally configured.
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.
| Vendor Type | What They Provide | Risk If Relationship Fails |
|---|---|---|
| Domain registrar | Your web address | Site goes offline, email may fail |
| Hosting provider | Where your files live | Site goes offline completely |
| CMS / platform | Content management system | Unable to update site, possible migration required |
| CDN provider | Speed and security layer | Site slowdown, possible security exposure |
| Web agency / developer | Build, maintenance, support | Lost institutional knowledge, no support coverage |
| Payment processor | Donation collection | Donation flow breaks, revenue loss |
| Email marketing platform | Newsletter and campaign sending | List access disruption, campaign failure |
| Analytics provider | Visitor and performance data | Loss of reporting, blind decision-making |
| Form provider | Contact and inquiry forms | Missed enquiries, data loss |
| Plugin / extension vendors | Specific functionality | Broken features, security vulnerabilities |
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.
Frequently asked questions
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
