What a Nonprofit CMS Audit Actually Reveals

When a nonprofit's CMS lands on our desk, the first task isn't to run scans or generate reports. It's to diagnose what we're actually dealing with. Is this a live system? Is it documentation handed over by a previous vendor? Is it a code repository without context? Each of those starting points changes what an audit can responsibly conclude.

From there, the work runs across three layers in parallel:

• What's documented
• How the Drupal architecture is built, including content types, taxonomy, and configuration
• What the actual user experience shows

The audit looks for consistency across those three layers. Where they don't align, that misalignment is where defects, liabilities, and system risks start to surface.

Image

What Clients Expect vs. What the Audit Actually Reveals

Clients usually expect a CMS audit to focus on technical issues, outdated modules, security gaps, and performance bottlenecks. Those things matter, and the audit checks them. The deeper findings, though, are almost always structural and organizational rather than technical.

That surprises most teams. A site can have clean code, no major security exposures, and acceptable performance, and still carry problems that compromise its purpose. Those problems don't appear in a vulnerability scan. They appear when you trace what a user actually experiences against what the organization intended them to experience.

Why Content Fragmentation Is the Most Common Finding in Global Nonprofits

One of our clients is a global nonprofit. When we audited their site, the most significant finding wasn't technical. The site had multiple versions of the same content, all leading to the same conversion goal.

The cause was organizational. Editors in different countries were each producing their own version of the same content. Each version was reasonable on its own. Together, they created a broken user journey.

Nonprofit users are not the same as e-commerce users. On a shopping site, a visitor knows what they're trying to do, complete a purchase, and the steps are obvious. On a nonprofit site, a visitor often arrives without a clear idea of what action to take. They rely on the content to guide them. When the content contradicts itself, the journey breaks. Users don't register, don't submit forms, and don't donate.

Image

Campaign Lifecycle Is a Nonprofit-Specific Audit Concern

Another finding that surfaces almost exclusively on nonprofit sites is campaign management. Which campaigns are still live, and which should have been archived? When last year's campaign sits next to this year's, two things happen:

• Users get confused and grow suspicious when they see outdated dates while attempting to donate to what they think is a current campaign.
• Donor data gets contaminated because contributions can be attributed to the wrong campaign cycle.

This is a content governance problem that no security scan will surface. It only appears when the audit is treated as a review of the operating system, not just the codebase.

Because the platform is yours, open source, and fully owned, these governance choices stay with the organization, not locked behind a vendor's roadmap.

Image

The Recommendation Most Clients Don't Expect: Fix First, Then Build

After the audit, the conversation usually heads in a direction the client isn't ready for. They expect the vendor to start building new features and editing existing ones. The recommendation is often the opposite: stabilize what's broken first, then build.

It's the equivalent of driving to the beach but forgetting to pack the swimsuits, the sunscreen, the towels. You arrive at the destination, but you can't actually do what you came for.

The reasoning is straightforward. New features built on top of unresolved structural issues inherit those issues, and they amplify them.

The Analytics Data Most Nonprofits Overlook

A consistent pattern across nonprofit clients is limited use of their own analytics. Which buttons are users clicking? What does their journey look like end-to-end? Which existing features are performing well enough to build on?

Skipping that data is expensive. It produces a familiar outcome: a client insists on adding a feature they're convinced users want, the team builds it, and post-launch data shows that users don't engage with it. Months of work end up shelved because the user journey wasn't examined before the build started.

Increasingly, this kind of journey analysis is augmented by AI, tracing patterns across millions of sessions that would take a human analyst weeks. As a Drupal AI Initiative Gold Sponsor, we treat that capability as part of the audit toolkit, not a separate product.

A CMS Audit Is a System Review, Not a Technical Checklist

A CMS audit is a system review. Diagnosing technical issues is part of that work, but it isn't the work itself.

The job is to investigate why and how the issue occurred, fix the root cause, and ensure it doesn't recur. Closing tickets and applying patches is the floor, not the ceiling.

An audit report can be read two ways. It can tell a client what is broken. Or it can tell a client why it's broken, what it's connected to, and what will break next if it isn't addressed. The second is the work we sign up for.

What Makes a Nonprofit CMS Audit Different

A nonprofit audit doesn't apply a one-size-fits-all framework. Several constraints reshape what the audit looks for:

What Nonprofit Decision-Makers Should Know Before Commissioning an Audit

For a nonprofit leader commissioning a CMS audit for the first time, the most useful thing to understand is what the audit is actually for.

It is a system review. The most consequential findings are organizational rather than technical. The recommendations call for stabilization before expansion. And the value of the work is not in the volume of issues it identifies. It is in whether those issues are traced to root causes that prevent recurrence.

For nonprofit teams considering an audit, that distinction is the place to start.

Hamza Al-Jundi is QA Technical Lead at Vardot, with 8 years in software quality and manual testing and 10 years in automation engineering across commercial enterprises and non-profits. He holds a Master's from Middle East University, where his research applied machine learning to bug severity detection. His automation work spans Selenium, Appium, Cypress, and Playwright, backed by ISTQB certifications including CTFL, Agile, Mobile, CTAL-TAE, and CTAL-TM (ASTQB certified). Hamza is the creator of two open-source tools for the Drupal ecosystem: Varbase Test Recorder, which generates Playwright test specs from browser interactions, and Drupal Documentation Writer, which auto-generates user manuals from a project's configuration.