Choosing a donor database, safely.

Write down what you need first

Every donor database looks good in a demonstration. Your list is how you tell them apart.

• Who will use it, and for what. Fundraising, finance, volunteers, the board. Each will need different access and different reports.
• What it must hold. Supporters and organizations, gifts and pledges, recurring gifts, tax receipts where your country requires them, grants, events, volunteers, and each person’s communication preferences and consent.
• What it must connect to. Your online donation form and payment provider, your email tool, your accounting system. Ask how each connection works and who maintains it.
• The reports you cannot do without. The board’s monthly figures, funder reports and year-end statements. Ask to see them built during the trial.
• The real price. Users, records, add-ons, payment fees, implementation and the price after any discount ends. Our before you sign guide has the questions to ask any vendor.

Run the trial with your own scenarios: a recurring gift that fails, a supporter who asks to be forgotten, a gift that needs refunding, a volunteer who becomes a donor.

Data protection, built in

A donor database is a list of people, their money and often their beliefs. Treat it that way.

• Roles and permissions. Can you limit who sees gift amounts, notes and sensitive fields, and who can export?
• Sign-in security. Multi-factor authentication for every user, and single sign-on if you use it elsewhere, in the plan you are buying.
• An audit log. A record of who viewed, changed, exported or deleted what, which you can read yourself.
• Consent and preferences. Fields that record what each person agreed to, when, how, and the wording they saw, and that your email tool respects.
• Requests from individuals. Can you find everything about one person, export it in a usable format, correct it and delete it, without a support ticket?
• Retention. Can you delete or anonymise records you no longer need, in bulk, on a schedule? See records retention.

General information, not legal advice. What you must do depends on the country: see privacy duties, country by country.

Payment card data: PCI DSS in plain words

The safest card number is one your organization never sees.

The Payment Card Industry Data Security Standard (PCI DSS) is set by the PCI Security Standards Council, founded by the major card brands. It applies to every organization that stores, processes or transmits cardholder data, regardless of size or how many payments it takes. The current version is PCI DSS v4.0.1.

• Keep card numbers out of your systems. Take online gifts through your payment provider’s hosted payment page or payment fields, so card details go straight to the provider. Your database should hold the provider’s reference for the gift, never the card number.
• Never keep the security code. The three- or four-digit card verification code must not be stored after the payment is authorized, even encrypted, even for recurring gifts, and even if the donor asks you to. The Council says a customer’s permission makes no difference.
• Encryption is not a way out. Encrypting card numbers you hold protects them, but generally does not take your systems out of the standard’s scope.
• No card numbers on paper, email or chat. A paper form with a card number on it, or an email from a donor quoting one, is cardholder data you now have to protect. Use the provider’s secure page or phone process, and do not write numbers down.
• Ask the provider for proof. The Council suggests asking any payment service provider for its PCI DSS Attestation of Compliance, and checking that the assessment covered the service you are using.
• Ask your bank which questionnaire applies. Merchants that meet the eligibility criteria validate with a Self-Assessment Questionnaire (SAQ). Whether you must validate, and which questionnaire applies, is for your acquirer (the merchant bank that processes your card payments) or the card brands to say. Ask them, in writing.

The fewer places card data can be, the less of the standard applies to you. That is the strongest reason to let a specialist provider handle payments and keep your donor database for everything else.

Exports: your way out, and a risk

You will need a full export one day. You also need to stop one walking out of the door.

• Test a full export during the trial. Every record type, gift history, consent records, notes and attachments, in an open, documented format such as CSV. Open it and check it.
• Know what “machine-readable” means. The ICO describes a good export as structured, commonly used and machine-readable. A PDF of each record is not an export.
• Keep your own copy. A scheduled export, stored securely and access-controlled, protects you if the vendor fails or locks your account.
• Control who can export. A spreadsheet of every donor on a personal laptop is a breach waiting to happen. Limit export rights to a few named people, and check the audit log.

Access: who sees what

Most data leaks from donor databases involve someone who had a login, not a hacker.

• One named login per person. Never shared accounts, including for volunteers and temporary staff.
• Give each role the least it needs. A volunteer entering event sign-ups does not need gift history.
• Remove leavers on their last day. Our joiners and leavers checklist covers it.
• Review the user list on a fixed schedule, for example every quarter, and remove anyone who no longer needs access.
• Turn on multi-factor authentication for everyone before you load any real data.

Moving your data in

Bad data moved into a new system is still bad data, now harder to find.

• Clean first. Merge duplicates, standardise addresses and names, and fix it in the old system or a working copy before the move.
• Leave some behind. Records you have no reason to keep do not need to come with you. Decide using your retention schedule.
• Bring consent with you. Migrate each person’s communication preferences and the record of their consent, not just their address. Without it you may have to ask everyone again.
• Map every field. List old fields, new fields and what happens to each. Gaps found now are cheap.
• Reconcile. After a test load, compare record counts and gift totals by year between the old and new systems. They must match, or you must know why.

Our moving off a failing system playbook covers the move in detail.

The first weeks: a set-up checklist

Most of what makes a donor database safe is decided in its first weeks.

1. Multi-factor authentication on for every userBefore any real data is loaded.
2. Roles definedWritten down, with the least access each role needs, and export rights limited to a few named people.
3. Payments through the providerOnline and phone gifts use the provider’s secure page; no card numbers or security codes in the database, email or paper.
4. Consent fields in useWhat each person agreed to, when and how, connected to your email tool.
5. A tested exportA full export opened and checked, and a scheduled copy stored securely.
6. An ownerOne named person responsible for users, settings and the vendor relationship, with a deputy.