Assess a donation platform's security by asking for evidence rather than assurances: current PCI DSS v4.0.1 validation with an Attestation of Compliance, role-based access with audit logs covering every party that touches donor data, application-level defense against card-testing bots, documented isolation and data residency, and an export timeline measured in hours.
The five questions below are written for the people who carry the risk: the CTO, CIO, or VP of Technology at an enterprise nonprofit moving donor money across markets. Each one asks for something a vendor can produce or cannot, which makes the review conclusive either way.
The Five Questions
Which version of PCI DSS are you validated against, and when was it last validated?
Who and what can see donor data, and what records the access?
What stops card-testing bots before they reach the payment processor?
Is our environment isolated, and where does donor data physically live?
If we leave, what arrives in the export and how quickly?
1. Which Version of PCI DSS Are You Validated Against Right Now?
A strong answer names a version and a date. PCI DSS v3.2.1 was retired on 31 March 2024, and since 31 March 2025 every applicable requirement in v4.0.1 is mandatory at assessment, including the 51 requirements that were future-dated when v4.0 was published. Any platform handling donor card data today should be able to state its version and its most recent validation date without preparation.
One point of vocabulary saves time in these conversations. The PCI Security Standards Council does not issue certificates to merchants or service providers, so "we are PCI certified" describes something the standard does not produce. Validation is evidenced through an Attestation of Compliance, a Report on Compliance or Self-Assessment Questionnaire depending on scope, and quarterly scans by an Approved Scanning Vendor.
What a strong answer contains
The version (v4.0.1), the current AOC, the most recent ASV scan date, and the SAQ type or ROC that applies. For any platform rendering a payment form on your own domain, ask specifically about requirements 6.4.3 and 11.6.1: every script on the payment page authorized, inventoried, and justified, with tamper detection on scripts and security-impacting HTTP headers as the donor's browser receives them. These address e-skimming, where the attacker alters a browser-loaded script and never touches the server.
A follow-up worth asking
The revised SAQ A removed requirements 6.4.3, 11.6.1, and 12.3.1 while adding new eligibility criteria. "We file SAQ A" and "our payment page scripts are monitored" are now different statements, so it is worth asking which one is meant.
Where VarGive lands
VarGive reduces PCI scope rather than managing it. Full card numbers are never stored or exported, only safe transaction metadata, which keeps the surface that has to be defended small by design. Our note on payment compliance in Drupal Commerce covers how that is enforced at the application layer.
2. Who and What Can See Donor Data, and What Records the Access?
A strong answer describes roles scoped to responsibility, multi-factor authentication enforced by default, and an edit log your team can read without filing a request. Access control tends to fail quietly, because over-permissioned accounts cause no visible problem until one is compromised. At that point the useful question is not who had access but who used it, and only a log answers that.
Blanket administrator access is worth probing wherever it appears. It is usually adopted for speed rather than by design, and the cost is that no record distinguishes routine work from anything else.
What a strong answer contains
Role definitions you can review, MFA enforcement, and a live demonstration of the audit log. Two minutes of screen share showing who changed what and when tells you more than a security whitepaper. Ask what your finance and audit teams can pull from it independently.
Where VarGive lands
Role-based access with market-level administration and extensible permissions, so a regional fundraising team manages its own campaigns without reaching into another market's, supported by revision history and edit logs recording user and date.
Does the Answer Cover AI Providers That Process Donor Content?
This part of the question was absent from most procurement checklists two years ago and now belongs inside it. Donation platforms are adding AI to translation, content generation, tagging, moderation, and fraud scoring, and each of those is a decision about which third party processes your content. A complete access answer names the model providers alongside the human roles.
"AI is built in" is a capability statement rather than a governance one. Three specifics separate a complete answer: whether you can change providers without re-platforming, whether a data-sovereign or self-hosted option exists for sensitive workloads, and whether AI activity is logged and observable the way the rest of your stack is. Human review matters too, since generated donor-facing copy should reach approval through the same editorial controls as everything else.
Where VarGive lands
AI capabilities run across 48+ model providers that can be swapped without re-platforming, with a private AI option using a bundled data-sovereign provider so donor data need never reach a third-party model. Guardrails, external moderation, request logging, and OpenTelemetry export to Datadog, Grafana, or Sentry keep AI activity inside the same observability perimeter as the rest of the platform.
3. What Stops Card-Testing Bots Before They Reach the Payment Processor?
A strong answer describes defense in depth that starts at the edge and continues into the application, not a single control at the gateway. Card testing is the attack donation forms attract most, because donation forms are built to accept small amounts from people the organization has never met. Attackers run stolen card lists through automated scripts in micro-transactions to identify which cards are still active, and small amounts draw less attention on a cardholder's statement.
The cost is operational as much as reputational. Each attempt carries a network fee, disputed charges add chargeback and resolution costs, and a sustained wave can move an organization into a card network monitoring program with higher processing fees attached. Processor-side fraud tools are necessary and do good work, but they engage at the point where those fees have already begun.
What a strong answer contains
Bot challenges at the CDN or WAF layer, rate limiting and velocity checks on the form itself, allow and deny lists, and monitoring that surfaces an anomaly within minutes. Ask who receives the alert at 02:00 and what your team can do without the vendor on the call.
Where VarGive lands
IP and email allow and deny lists, velocity checks, and domain blocking, with AI-assisted form protection that filters donation form spam without adding friction for legitimate donors. Email and SMS validation flows can be enabled for repeat donations where the risk profile calls for it.
4. Is Our Environment Isolated, and Where Does Donor Data Physically Live?
A strong answer explains isolation at the database, application, and infrastructure layers, names the region the data sits in, and states plainly what happens to your environment if another organization on the same platform is compromised. Shared infrastructure is an architecture choice with real efficiencies, and the point of the question is not to rule it out. It is to establish what you can verify independently and what you are accepting on trust.
Residency turns this into a legal question as well as a technical one. Data protection rules, donor consent regimes, and internal policy commitments differ by jurisdiction, so a platform that cannot name the region holding the data cannot help you evidence compliance in any of them. "Globally distributed infrastructure" describes the vendor's architecture rather than answering the question a regulator or a board will ask.
Retention deserves the same attention as location. A platform that holds abandoned donation records and non-donor personal data indefinitely is enlarging the volume you would have to report and notify on after any incident, without adding value for the fundraising team.
What a strong answer contains
Architecture documentation rather than a summary slide, a named isolation model, region selection you control, a current sub-processor list, and a documented deletion schedule you can configure. Ask for incident precedent as well: has a tenant been compromised, and what was the blast radius? Where isolation cannot be demonstrated at every layer, a candid explanation of the compensating controls is a better sign than a confident generality.
Where VarGive lands
Deployment on your preferred infrastructure, whether cloud, managed hosting, or on-premises where a requirement demands it, with configurable scheduled deletion of non-donor personal data after a defined window and configurable retention for abandoned donations.
5. If We Leave, What Arrives in the Export and How Quickly?
A strong answer gives a timeline in hours and an itemized list of contents. Exit terms are among the most informative questions in a security review, because they establish how much of the platform you actually control while you are still using it.
Press on the contents, since donation records alone are not portability. A complete export covers donor records, recurring agreements with their billing schedules, campaign content and configuration, integration mappings, and full historical transaction data, in an open format that loads elsewhere without a migration project.
What a strong answer contains
The timeline, the itemized contents, and the format, written into the contract rather than confirmed in a meeting. Ask what happens to active recurring donor agreements during a transition, since that is the detail most likely to be missing and the most expensive to reconstruct.
Where VarGive lands
Donor and donation data sync to your CRM through API-based integration, with Salesforce a proven supported option mapping to NPSP and Nonprofit Cloud, alongside CSV and Excel exports filterable by campaign, status, payment method, date range, currency, and country. Because the platform is open source and runs on your infrastructure, the code and configuration are yours alongside the data.
What Evidence Should You Request Before the Meeting?
Send this list ahead of the call and ask for documents rather than slides. Each row is an artifact that either exists or does not, which keeps the review factual.
Question
Artifact to request
What it confirms
PCI validation
Current AOC, latest ASV scan date, SAQ type or ROC
Validation is current against v4.0.1, and the scope is what you assumed
Access and AI
Role definitions, a live edit log view, model provider list and log destinations
Every party touching donor data is named, scoped, and attributable
Fraud defense
Control list by layer, and the alerting runbook
Bot traffic is addressed before the gateway, and someone is on call
Isolation and residency
Architecture documentation, incident history, region options, sub-processor list, retention policy
Isolation is designed and tested, and you can answer a regulator without contacting the vendor
Portability
Export timeline, itemized contents, sample file
The exit is a defined process rather than a negotiation
Why Does Ownership Change What a Security Review Can Verify?
Vardot's position: all five questions are answerable in documents, but only some are answerable in the platform itself, and that difference tracks with who owns the infrastructure. When your organization owns the platform, a security review becomes a code and configuration review. Your team reads the access model, inspects the logs, selects the region, and follows the AI request trail directly, at whatever depth the review requires and without waiting on a ticket.
That is the argument for open source in this category, and it is a capability argument rather than a caution. Ownership is also the one platform property that is difficult to add later, which is why it belongs in the evaluation rather than the renewal.
Vardot builds enterprise donation infrastructure on Drupal as a Drupal Diamond Certified Partner, with 200+ platforms launched, a 4.9/5 Clutch rating across verified reviews, standing among the top 20 Drupal contributors worldwide, and Gold Sponsorship of the Drupal AI Initiative. VarGive is the donation platform that work produced.
What Ownership Looks Like in Practice
Organizations including UNHCR run donor infrastructure they control: 67M+ USD processed, 3,000 campaigns published across markets, 56+ currencies, 10+ languages, and $0 in platform fees
Security teams read raw server and application logs directly as events occur
Isolation and residency questions resolve at the architecture level, because the environment is yours alone
Fundraising teams have published crisis and evergreen campaigns in 15 to 30 minutes, with a reported 63% reduction in time to build, design, and publish
How Do You Run This Review in a Single Vendor Meeting?
Send the five questions and the evidence table in advance, then work the meeting in this order. The sequence mirrors the Align stage of the Vardot Delivery System, where markets, payment methods, data flows, and reporting requirements are mapped before any build decision is made.
Open with the artifacts. AOC, last ASV scan date, SAQ type or ROC. If they are not available in the meeting, note the gap and move on rather than debating it.
Ask for one screen share. The access model and a single edit log entry. Two minutes of demonstration is worth more than a security questionnaire.
Walk one scenario out loud. A card-testing wave begins at 02:00 on day two of an emergency appeal. Who is alerted, what happens automatically, and what can your team do independently?
Get portability in writing. Timeline in hours, contents itemized, format named, placed in the contract rather than the transcript.
Record what remains open. Every platform will answer some questions more completely than others. The pattern of what stays unresolved is the most useful output of the meeting.
What Should You Do Next?
Security claims are easy to state and hard to test, which is why each of these five questions asks for a version, a document, a log, or a timeline instead. Compliance status, access control including AI providers, fraud defense, isolation and residency, and exit terms are all verifiable when the request is specific enough to be answered or not.
Where an answer cannot be produced, record it and weight it alongside cost and capability. Donor trust is the asset the platform holds on your behalf, and a platform you can inspect is the most direct way to keep it under your own supervision.
Sovereign Infrastructure: A Security Pillar for Enterprise Donation Platforms
Nauras Abul-Haija is the Content and SEO Manager at Vardot, where she built and leads the agency's content and SEO function: editorial strategy, search, and content operations aimed at the nonprofit, higher education, media, and healthcare organizations Vardot works with. She is multilingual, which shapes how she approaches search across languages and content built to travel between markets. Her writing covers search performance and AI-era discovery most often, alongside content operations, digital strategy, and the occasional detour outside her lane.
Yes. Open-source platforms like Drupal allow for transparent security audits. Because you own the infrastructure, you aren't vulnerable to breaches targeting other "neighbors" on a shared SaaS platform.
We implement multi-layered protection including honeypots, behavior-based bot blocking, and Cloudflare WAF rules designed specifically for high-volume donation forms.
Role-Based Access Control minimizes the "blast radius." If an individual staff account is compromised, the damage is restricted to that specific user's permissions, protecting the core donor database.
Ask for the version and the last validation date. Since 31 March 2025, all applicable PCI DSS v4.0.1 requirements are mandatory at assessment. Validation is evidenced through an Attestation of Compliance, a Report on Compliance or SAQ depending on scope, and quarterly scans by an Approved Scanning Vendor.
Ask how tenants are isolated at the database, application, and infrastructure layers, whether any cross-tenant incident has occurred and what its blast radius was, and whether load elsewhere on the platform can affect campaign performance during a peak appeal. Shared infrastructure is a valid choice; the goal is knowing what you can verify.
Donation records alone are not portability. A complete export includes donor records, recurring agreements with billing schedules, campaign content and configuration, integration mappings, and full historical transaction data, in an open format, delivered within hours. Put the timeline, contents, and format in the contract rather than relying on a verbal commitment.
