How to audit your nonprofit website for privacy risks.

Most nonprofit leaders assume their website is basically fine from a privacy standpoint. They have a privacy policy somewhere in the footer, they’re not selling data, and they’re not doing anything sketchy. What more is there to think about?

Quite a bit, it turns out—and most of it is invisible unless you know where to look.

Your website is probably collecting more data than you realize, sharing it with more third parties than you’d expect, and retaining it longer than is necessary. None of that is unusual, and none of it means your organization has done something wrong. It means you’re using tools that were built to collect data by default, and no one has gone back to examine what’s actually happening under the hood.

This post walks you through a practical self-audit you can do without a technical background. You don’t need to understand code. You just need to know where to look and what questions to ask.

Step one: find out what’s loading on your site

The first thing to understand is what third-party scripts are running on your website. Every time someone visits your site, their browser loads not just your content but potentially a collection of scripts from other companies—analytics tools, social media platforms, advertising networks, embedded widgets, font libraries. Each of those is a data relationship you’ve entered into on behalf of your visitors, whether you meant to or not.

To see what’s running, open your website in Google Chrome or Brave Browser, right-click anywhere on the page, and select “Inspect.” Click the “Network” tab, then reload the page. You’ll see a list of everything loading—look specifically at the entries that aren’t your own domain. You’re looking for things like google-analytics.com, facebook.net, doubleclick.net, platform.twitter.com, or any other third-party domains.

If that feels too technical, a simpler option is to use a tool like Blacklight (themarkup.org/blacklight) — paste in your URL and it gives you a plain-language report of the trackers, ad networks, and third-party scripts it detects on your site. It was built specifically to make this kind of information accessible to non-technical people, and it’s free.

Once you know what’s loading, you can start making decisions about what should stay and what should go.

Step two: evaluate each third-party tool

Not all third-party scripts are equal. Here’s a framework for thinking through each one:

Do you know it’s there? Sometimes scripts end up on a site through an embedded widget, a social sharing button, or a plugin someone installed years ago without fully understanding what it did. If you’re not sure why something is loading, that’s worth investigating before you decide whether to keep it.

What data does it collect, and where does it go? Analytics tools collect visitor behavior. Social pixels collect information about who visits your site and share it with advertising platforms. Embedded maps and video players may collect location and viewing data. Each tool’s privacy policy will tell you what it collects—though reading those is its own adventure—and whether that data is shared with or sold to third parties.

Is it necessary? This is the most important question. For every third-party tool on your site, ask what you’d lose if you removed it. If the answer is “not much,” remove it. If it’s serving a purpose, ask whether there’s a less data-intensive way to serve that same purpose.

Social media sharing buttons are a common example of tools that feel useful but aren’t worth the tradeoff. The buttons themselves load scripts from Facebook, Twitter, and other platforms that track every visitor who lands on the page—regardless of whether they click the button. A plain text link to share something accomplishes the same goal without the tracking infrastructure.

Step three: look at your analytics setup

If you’re using Google Analytics, there are a few specific things worth checking.

First, confirm you’re using GA4 rather than the older Universal Analytics. GA4 anonymizes IP addresses by default, which is a meaningful baseline privacy improvement.

Second, check your data retention settings. In GA4, go to Admin > Data Settings > Data Retention. The default is two months for user-level data, which is reasonable—make sure it hasn’t been changed to a longer period without a clear reason.

Third, look at whether Google Signals is enabled. Google Signals connects your analytics data to Google’s advertising network, enabling cross-site tracking and behavioral targeting. For most nonprofit websites, this feature serves no purpose and should be turned off. You’ll find it under Admin > Data Settings > Data Collection.

If you’re open to switching analytics tools entirely, privacy-focused alternatives like Plausible or Fathom collect only what you actually need—page views, referral sources, popular content—without the broader data collection that comes with Google’s ecosystem. They’re not free, but they’re not expensive, and the tradeoff is worth considering for organizations serving vulnerable populations.

Step four: review your forms

Your contact forms, intake forms, and newsletter sign-ups are some of the most sensitive data collection points on your site. A few things to check:

What platform is handling your forms? If you’re using Google Forms, your submissions are stored in Google’s infrastructure. If you’re using Typeform or JotForm, your submissions are in their databases, under their privacy policies. Native form tools built into your website platform—like Squarespace’s built-in forms—typically give you more control over where data goes and who can access it.

Where do submissions go after someone fills out a form? Most platforms send an email notification, store the submission in a backend database, or both. Check whether submissions are accumulating in your platform’s backend without anyone actively managing or deleting them. Old form submissions are data you’re responsible for—and data you’re not actively using is data you probably shouldn’t be keeping.

How long do you keep form submissions? If you don't have an answer to this question, that’s the gap to close. A simple retention policy—“we delete intake form submissions after 90 days unless they've been transferred to our case management system”—is better than no policy, and it protects your clients.

Step five: check your privacy policy

Your privacy policy should accurately describe what your site actually does—not what you intended it to do when the policy was written, but what it does right now. If you’ve added tools or changed platforms since the policy was last updated, it may no longer be accurate.

At minimum, your privacy policy should cover: what data you collect and why, what third-party tools you use and what they collect, how long you retain data, and how someone can request that their data be deleted. It should be written in plain language, not legal boilerplate, and it should live somewhere easy to find—not buried at the bottom of a page nobody visits.

A privacy policy that doesn’t reflect your actual practices isn’t just a document problem. It’s a trust problem.

What to do with what you find

A privacy audit isn’t meant to produce a perfect score—it’s meant to give you a clear picture of where you are, so you can make deliberate decisions about where you want to be. You might find that most of your setup is fine and there are two or three specific things to address. You might find a tracking pixel that got added during a social media campaign and was never removed. You might find that your analytics data retention is set to something nobody consciously chose.

Whatever you find, the goal is the same: make sure the data your website collects is the data you’ve decided to collect, for reasons you can explain, handled in ways you’ve thought through.

If you’d like help working through this audit—or want someone to do a more thorough technical review—that’s work I do with organizations regularly. Sometimes a second set of eyes finds things that are easy to miss when you’re close to the work.