10 Questions Every Nonprofit Should Ask Before Buying a Cybersecurity Solution

Before you read

You run a nonprofit. You hold donor names, addresses, and payment cards. You may hold constituent records that are just as sensitive as anything a clinic keeps. You run on a tight budget and a smaller team than the work deserves, and now a vendor has emailed you about "cybersecurity," or a grant application asked how you protect data, or your board asked whether the online donation form is safe. Every vendor sounds confident. Every proposal has a number on it. And you're nodding along to words like "PCI DSS," "SAQ," "encryption," and "SOC 2," hoping the person across the table actually understands what they mean for an organization that has to keep every donor's trust to survive.

Here's what most vendors won't lead with. Nonprofits are targets, not exceptions. In a recent survey, 85% of nonprofits said they'd been hit by a cyberattack, and more than half said they don't have enough staff to defend themselves. You hold exactly what attackers want: donor payment cards and personal information, held by a lean team. And the rules already apply to you. If your organization accepts, stores, processes, or transmits card payments, and almost every nonprofit that takes online donations does, you're subject to the Payment Card Industry Data Security Standard (PCI DSS), the same standard as any business. On top of that, comprehensive state privacy and breach-notification laws are now active in roughly 20 states and counting, and they don't exempt you because you're a charity.

And the stakes are real. Payment processors levy monthly non-compliance fines that commonly run from $5,000 to $100,000, on organizations that can least absorb them. State laws require you to notify people when their data is exposed, on a clock. And the damage that's hardest to price is the one that matters most: a breach of donor data is a breach of donor trust, and trust is the entire currency of a nonprofit.

So we wrote this down. Not a teaser, the real thing. First we decode the jargon and lay out what actually applies to a nonprofit, in plain English: PCI DSS for donations, state breach and privacy laws, and the security expectations that increasingly ride along with grants. Then we give you a ten-minute exercise to map where donor and payment data lives. Then the ten questions we'd ask if we were sitting in your chair, each with what a strong answer sounds like, what a weak one sounds like, and a real requirement to hold the vendor to.

Ask these of every vendor you're talking to, including us. The right partner welcomes them and answers straight. The wrong one gets vague. How a vendor handles these ten tells you more than any proposal ever will.

One note on us. We run managed IT and security for organizations that hold sensitive data on lean teams, and we help build and maintain the protections that matter: securing how donations are processed so your PCI scope stays small, protecting donor and constituent information with encryption and multi-factor authentication, standing up the monitoring and documentation that grants and boards ask about, and having a real plan for the day something goes wrong. We deliver that on one agreement, with the labor included rather than billed by the hour. We've built our own PCs and servers on our own line in Wichita since 1997.

Nonprofit data security in plain English

Nonprofits are covered by the same core rules as businesses. There's no charity exemption. If you take card payments, PCI DSS applies. If you hold personal data on residents of states with privacy laws, those laws apply. Being mission-driven doesn't change the obligation; it just means a breach hurts more, because your organization runs on trust.

PCI DSS: the donation rule. The Payment Card Industry Data Security Standard applies to any organization that accepts, stores, processes, or transmits cardholder data. That's essentially every nonprofit taking donations. The current standard (PCI DSS v4.0.1 at the time of research) expects controls like multi-factor authentication, monitoring of the scripts on your donation pages, and, depending on how you take payments, external vulnerability scanning. Even with a hosted payment page, you typically complete an annual Self-Assessment Questionnaire (SAQ) and maintain a written PCI program. The single biggest lever is keeping card data out of your own systems, which shrinks your scope and your risk.

State breach and privacy laws. As of early 2026, comprehensive consumer-privacy laws are active or taking effect in roughly 20 states, including California, Virginia, Colorado, Connecticut, Texas, Oregon, Montana, and more. On top of those, essentially every state has a breach-notification law requiring you to tell affected people when their personal information is exposed. Verify what applies to the states your donors live in.

Grant and funder expectations. More and more funders, government grants especially, ask about your data security posture as a condition of the money. Good security is becoming part of being fundable.

Vendor security matters as much as yours. Your donor CRM, your payment processor, your email and cloud providers all hold or touch your data. A common baseline to ask for is SOC 2 Type II. Your data is only as safe as the weakest vendor holding it.

Where CybertronIT sits. We help you take payments in a way that keeps your PCI scope small, protect donor and constituent data with real controls, stand up the monitoring and documentation funders and boards ask about, vet the security of the vendors holding your data, and build a plan for the day something goes wrong. We're not your attorney and not your auditor or QSA; the organization owns the final accountability.

The jargon, decoded

• PCI DSS. The security rules for anyone who accepts, stores, processes, or transmits payment-card data. If you take donations by card, it applies to you.
• Cardholder data. The card number and related details. The less of it that touches your own systems, the smaller your PCI scope and risk.
• PCI scope. Everything in your environment that touches cardholder data. Keeping scope small (hosted or tokenized payment flow) is the cheapest, most effective PCI move a nonprofit can make.
• SAQ (Self-Assessment Questionnaire). The annual PCI form you complete to attest how you protect card data. Even with a hosted page, you usually still owe an SAQ.
• Tokenization / hosted payment page. Ways to take payment without card data landing in your systems: the processor handles the card and hands you a harmless token.
• Encryption at rest and in transit. Protecting donor data both where it's stored and where it moves. A basic, expected control.
• MFA (Multi-Factor Authentication). Requiring more than a password to reach sensitive systems. PCI v4 pushes MFA broadly.
• Breach notification. State laws requiring you to notify affected people when personal data is exposed, usually on a defined timeline.
• SOC 2 Type II. An independent audit verifying a vendor's security controls actually work over time. A reasonable baseline for the CRM and payment vendors holding your data.
• Vulnerability scan. An automated check for known weaknesses. Depending on how you take payments, PCI may expect quarterly external scans.

The 10 questions

Here are the ten questions, with why each one matters for a real nonprofit. Ask all ten, and watch the reactions as closely as the answers.

1. What actually applies to us: PCI DSS, state breach laws, and what funders ask?

If you take card donations, PCI DSS applies, nearly every state has a breach-notification law, roughly 20 states now have broader privacy laws, and funders increasingly ask about your security. A vendor who can't explain what applies to your organization and your donors' states is selling a product, not protection.

2. How do we take payments so that card data stays out of our systems and our PCI scope stays small?

The cheapest, most effective PCI move is keeping raw card data with the processor (hosted page, tokenization). A weak vendor is fine with card numbers living in a spreadsheet, which is exactly the setup that maximizes your risk and cost.

3. What counts as donor and constituent data for us, and where does it actually live?

Sensitive data isn't just card numbers: it's your CRM, email lists, exports on laptops, shared drives, backups. A vendor who scopes only "the network" has missed the donation form, the spreadsheet, and the CRM, which is where the actual exposure is.

4. Do you provide encryption and MFA across everything that holds donor data, and can you prove it?

Encryption at rest and in transit and MFA on the systems holding donor data are basic, high-value controls, and PCI v4 pushes MFA broadly. Account takeovers are one of the most common ways nonprofits get hit.

5. How do you help us complete our annual PCI Self-Assessment Questionnaire and keep it current?

Even with a hosted payment page, you typically owe an annual SAQ and a written PCI program. A vendor who treats PCI as a one-time setup has skipped the part that keeps you compliant, and processors fine non-compliance monthly.

6. How do you vet the security of the vendors holding our donor and payment data?

Your donor CRM, payment processor, and email tools all hold your data, and your security is only as strong as the weakest one. A strong vendor asks about your other vendors and looks for a baseline like SOC 2 Type II.

7. What monitoring, patching, and backups do you run, and how do we recover from ransomware?

Nonprofits get hit with ransomware like everyone else, but with less margin to recover. A vendor who's vague about monitoring or can't tell you how fast you'd recover is one you don't want when your systems are locked.

8. What is our incident-response and breach-notification plan, and how do we meet the state clocks?

If donor data is exposed, state laws require notifying affected people, on a timeline. A vendor who treats a breach as hypothetical is the one you don't want when it happens.

9. What will this actually cost us, per user, in writing, and what fits a nonprofit budget?

Security for a lean, budget-tight team has to be priced honestly. A vendor who won't give you a clear per-user number, or oversells you enterprise tooling you don't need, isn't respecting the budget you operate on.

10. How do you help us prove our security to a board, an auditor, or a grant application, not just claim it?

Boards ask, auditors ask, and grants increasingly ask you to document your security. A vendor who leaves the documentation to you has left you holding the exact part that funders and boards examine.

Red flags to listen for

• Fine with card data in your systems. That's the setup that maximizes your PCI scope, cost, and risk.
• Never mentions PCI or the SAQ. If you take cards, PCI applies, and the annual SAQ is ongoing.
• Vague on encryption and MFA. They can't tell you exactly where MFA is enforced or that donor data is encrypted at rest and in transit.
• Ignores your other vendors. No interest in the security of your CRM, processor, or email tools, and no baseline like SOC 2.
• Scopes only "the network." They miss the donation form, the spreadsheet, the CRM, and the exports.
• No ransomware or backup story. They're vague on monitoring and can't tell you how fast you'd recover.
• No incident or breach plan. They have no plan for the state notification clocks.
• Enterprise oversell. They push tooling built for a 500-person company at a lean-team organization, with no per-user honesty.

Get the full checklist (free)

Everything above is the map. The full checklist is the tool you bring into the room. The free PDF is built to print and carry. It adds a ten-minute exercise to map your own exposure before you take a single sales call, plus where CybertronIT fits and how to score every vendor you talk to. Give us an email and it is yours.