PCI Compliance for Small Nonprofits: An AI-Assisted Readiness Review

What PCI DSS Requires of a Small Organization

PCI DSS is not a law. It is a contractual standard maintained by the PCI Security Standards Council, which was founded by the major card brands, and it reaches your organization through your merchant agreement with an acquiring bank or payment processor. That distinction matters because enforcement runs through the payments system rather than through a regulator. Your processor decides what validation it requires, charges fees when you fall behind, and, after a breach, passes along whatever assessments the card brands impose. State data breach notification laws and state attorneys general sit alongside this as separate legal exposure, but PCI itself is a private obligation you agreed to when you started accepting cards.

The current version is PCI DSS v4.0.1. Version 3.2.1 retired at the end of March 2024, version 4.0 retired at the end of 2024, and the "future-dated" requirements introduced in version 4.0, which had been best practices only, became mandatory on March 31, 2025, as compliance consultancies tracking the transition have documented. The Council has begun gathering comments toward a future major revision, and its 2025 annual report describes that work, but no release date has been announced and v4.0.1 is the standard you are attesting against today. If your organization's PCI documents still reference version 3.2.1, which is common among small nonprofits that set up card processing years ago, the review described here is overdue.

The standard groups its requirements under twelve headings: install and maintain network security controls, apply secure configurations, protect stored account data, protect cardholder data in transit, protect systems from malicious software, develop and maintain secure systems, restrict access by business need, identify and authenticate users, restrict physical access, log and monitor access, test security regularly, and support all of it with organizational policies and programs. The full standard runs to hundreds of individual requirements. The reason a small nonprofit can realistically comply is that most of those requirements apply only to systems that handle card data, and a well-designed small organization can arrange its operations so that almost no such systems exist on its side.

Merchant levels determine how you validate compliance. The card brands tier merchants by annual transaction volume, and nearly every small nonprofit sits in the lowest tier, commonly described as Level 4 for merchants processing fewer than 20,000 e-commerce transactions a year and under a million transactions overall, though thresholds vary by brand and your acquirer can assign a higher level after an incident. Level 4 merchants validate through an annual SAQ and Attestation of Compliance rather than an on-site assessment, plus quarterly vulnerability scans by an Approved Scanning Vendor if they have internet-facing systems in scope. That is the regime this article assumes.

Choosing the Right Self-Assessment Questionnaire

The Council publishes several SAQ types, each matched to a particular way of handling cards, and choosing the wrong one is the single most common error in small-merchant compliance. The questionnaires differ enormously in length. SAQ A, for merchants who fully outsource card handling to compliant third parties, is the shortest by a wide margin. SAQ D, the catch-all for merchants who do not fit any other type, covers the full standard and runs to several hundred questions. Your data flow inventory tells you which one you can honestly complete.

SAQ A fits e-commerce and mail or telephone order merchants who have outsourced all cardholder data functions to validated third parties and retain only paper reports or receipts. For a nonprofit, this typically means a hosted donation page where the donor is redirected to the platform's own domain, or an embedded form where every element of the payment fields is delivered directly from the compliant provider. SAQ A-EP applies to e-commerce merchants whose own website affects the security of the payment transaction even though the card data goes to a third party, for instance when your site's code builds the payment form. It is substantially longer than SAQ A. SAQ B covers merchants using standalone dial-out terminals or imprint machines with no electronic storage. SAQ B-IP covers standalone terminals connected over the internet. SAQ C-VT covers merchants who key transactions one at a time into a web-based virtual terminal from an isolated computer with no electronic storage. SAQ P2PE covers merchants using a validated point-to-point encryption solution for card-present transactions. Anything else, including any electronic storage of account data, lands in SAQ D.

A change in early 2025 matters for every nonprofit with a donation page. Version 4.0 had added two requirements aimed at the growing problem of malicious scripts skimming card data from payment pages: Requirement 6.4.3, an inventory and authorization process for scripts on payment pages, and Requirement 11.6.1, a mechanism to detect unauthorized changes to those pages. Both initially appeared in SAQ A, which alarmed small merchants who did not control the technical details of their embedded forms. In January 2025 the Council released a revised SAQ A that removed those requirements and replaced them with a new eligibility criterion: the merchant must confirm its site is not susceptible to script attacks that could affect the payment page. As SecurityMetrics explains, the Council's accompanying FAQ gives two ways to meet that criterion: implement protections like those in 6.4.3 and 11.6.1 yourself, or obtain confirmation from your compliant payment provider that its solution protects the payment page. Processors have published their own guidance on which integration methods qualify, and merchants who fall under SAQ D still carry both requirements directly.

The practical consequence for nonprofits is that the question "does my donation platform handle the payment fields?" is no longer sufficient. The right questions are whether the payment page or form elements originate only and directly from a compliant provider, whether your website could load a script that interferes with them, and whether your provider will put in writing that its integration method qualifies for SAQ A under the revised criteria. A full redirect to the provider's hosted page is the cleanest answer. An iframe embedded in your site usually qualifies with provider confirmation. A form built by your own website code generally does not, and pushes you toward SAQ A-EP.

AI helps here in a specific way. Give it your data flow inventory and ask it to walk through each SAQ type's eligibility criteria against your actual setup, flagging where you clearly qualify, clearly do not, and where the answer depends on a fact you still need from a vendor. It can draft the precise question to send your donation platform about SAQ A eligibility and script protection. It cannot tell you how your platform's integration actually works. That answer must come from the vendor in writing, and the written answer belongs in your evidence file.

Running the Readiness Review With AI Support

With the inventory done, the scope reduced, and the SAQ type chosen, the review itself becomes a structured gap analysis: for each question on the questionnaire, do you have the control it describes, and can you show it? Small nonprofits stall here because the questions are written for security professionals and the honest answer to many of them is "I do not know what this means." AI removes that barrier. It can read the SAQ you have selected and restate each requirement as a plain question about your organization, explain what evidence an assessor would typically expect, and keep a running list of yes, no, and not-sure answers with the reasons.

Run it as a working session rather than a one-shot prompt. Paste the requirements one section at a time, describe your actual practice, and let the model tell you whether what you described satisfies the requirement, what is missing, and what document or screenshot would prove it. Where you do not know the answer, record who to ask: your website host, your donation platform, your IT contractor, your bookkeeper. The output is a remediation list with owners and due dates, which is the core deliverable of a readiness review. The remediation list is also what you need if your processor or an auditor ever asks how you arrived at your attestation, and it becomes the starting point for next year's review.

The second major use is the evidence binder. PCI attestations are only as good as the documentation behind them, and small organizations rarely keep any. For each requirement you answer "yes" to, you should be able to produce something: a policy, a screenshot of a configuration, a vendor's Attestation of Compliance, a training record, a device inventory, a scan report. AI can generate the index for the binder from the SAQ, name each piece of evidence you need, and draft a short cover note explaining what each document demonstrates. The binder is also where the written answers from your donation platform about SAQ A eligibility live. If you have already built a structure for organizing evidence for your financial audit, as described in our article on audit preparation with AI, the same discipline transfers directly.

A third use is translation between people. The executive director needs a one-page summary of risk and cost. The board finance committee needs to understand why the organization is changing how it handles mail. Staff need instructions they will actually follow. The web contractor needs a precise technical question. AI can produce all of these from the same underlying remediation list, in the right register for each reader, which is a real saving for a finance manager who would otherwise write each from scratch.

The limits are just as important. AI does not know your systems. It cannot verify that a setting is actually configured, that a vendor's attestation is current, that your website loads no unauthorized scripts, or that your staff follow the phone procedure you wrote. Every "yes" on the questionnaire must rest on something a person checked, not on a plausible-sounding paragraph the model produced. And the model should never see a card number, a full donor record with payment details, or a scan report full of your network's vulnerabilities unless your organization has decided that the specific tool is approved for that category of data. For most small nonprofits the review can be conducted entirely with descriptions of practices and systems, which contain nothing sensitive.

Vendors, Attestations, and Shared Responsibility

Outsourcing card handling to a compliant provider is the right strategy, but it does not outsource the obligation. The standard requires you to maintain a list of the third-party service providers that touch your card data, to understand which PCI requirements each one handles on your behalf and which remain yours, to confirm their compliance status at least annually, and to have written agreements acknowledging their responsibility for the security of the data they handle. For a small nonprofit, this usually means three to six vendors: a donation platform, a payment gateway or processor, perhaps an event or auction platform, a website host, and a donor database.

The document to ask for is the vendor's Attestation of Compliance, which a service provider that has been assessed should be willing to share, along with a responsibility matrix that states which requirements it covers and which you must handle. Most major donation platforms publish this material or provide it on request. A vendor that cannot or will not produce a current attestation is a vendor whose compliance you cannot rely on, and a transaction flow that depends on an unvalidated provider does not qualify for SAQ A. Our guide to evaluating AI vendor security claims describes how to read this kind of documentation skeptically, and the same habits apply to payment vendors.

The nonprofit sector learned the cost of vendor dependence from the 2020 Blackbaud incident, in which a ransomware attack on the widely used donor management provider exposed data belonging to thousands of nonprofit customers and millions of their constituents. The fallout took years to resolve: a 2023 settlement of $49.5 million with 49 state attorneys general and the District of Columbia, as reported by The Record, followed by a Federal Trade Commission order in 2024 requiring improved security, deletion of data the company no longer needed, and a data retention schedule. The individual nonprofits whose donors were affected did nothing wrong technically, yet they were the ones writing to their donors. The lesson is not to avoid vendors. It is to know exactly which vendors hold what, to keep their attestations current, and to retain only the data you actually need, a theme that connects to building a sensible records retention schedule.

AI makes vendor management tractable for a small team. It can build and maintain the provider list, draft the annual request for an updated attestation, read a responsibility matrix and translate it into a plain checklist of what remains your job, and flag when a vendor's attestation is about to expire. It can also compare the vendor's stated responsibilities against your SAQ answers to catch requirements that nobody is covering, which is the most common gap in a shared-responsibility arrangement. It cannot verify that the vendor actually does what the attestation says. That verification is the assessor's job, and the attestation is the evidence that an assessor did it.

What Non-Compliance Costs, and Building an Annual Rhythm

The visible cost of ignoring PCI is the processor's non-compliance fee, which for small merchants is typically a modest monthly charge; one payments industry review puts the common range at roughly $20 to over $100 a month depending on the processor. Many nonprofits have paid that fee for years without noticing it on their statements, which is both a waste of donor money and a sign that no one is watching the merchant account closely. Finding and eliminating that fee by completing a valid SAQ is often the quickest financial win of the entire review.

The invisible cost is what happens after a breach. If card data is compromised and your organization was not compliant, the card brands can assess fines against your acquirer, which passes them to you along with the cost of a mandatory forensic investigation, card reissuance charges, and higher processing rates. Industry sources describe card-brand assessments that escalate month by month into tens of thousands of dollars, though the exact schedules are not published by the brands and should be treated as indicative. Your processor can also terminate your merchant account, which for a nonprofit means losing the ability to accept donations online at all. On top of the payments-system consequences sit state breach notification obligations, potential attorney general inquiries, and the donor trust that no settlement restores. A compliant organization that suffers a breach is in a far stronger position on every one of these fronts than a non-compliant one, which is the real return on the readiness review.

Insurance interacts with all of this. Cyber policies increasingly ask whether the applicant is PCI compliant, and some exclude or limit coverage for payment card losses when it is not. The attestation you sign is a representation your carrier may rely on. A review that produces an honest, documented SAQ strengthens your application and your claim position; a casually completed one can undermine both. If you have not looked at how your coverage treats payment data, our article on cyber insurance and AI for nonprofits is a reasonable starting point.

Compliance is annual, not once. The SAQ and attestation are due every year, scans are quarterly where they apply, vendor attestations expire, policies need review, training needs repeating, and staff turn over. The way small organizations sustain this is a short calendar owned by one person, with AI keeping the reminders, drafting the annual vendor requests, refreshing the training, and pre-populating next year's gap analysis from this year's remediation list. The first review is the heavy lift. Each subsequent one should take a fraction of the time, because the inventory, binder, and policies already exist and only need updating for what changed.