Massachusetts Nonprofit Technology: What a Central MA Nonprofit Should Get Right on a Small Budget

TL;DR: A small budget for Massachusetts nonprofit technology goes furthest on six things: who can see donor data, a donation page that never touches card numbers, one login per person, email that reaches inboxes, backups it has actually restored, and a written rule for AI. Most of that is setup, not spending.

Massachusetts nonprofit technology runs on smaller budgets than the work deserves. Most organizations here are small, as the numbers below show, and few have anyone whose job is technology. Even so, they hold the kind of information a regulator cares about: donor payment details, volunteer background checks, client records.

When I look at how a small organization's Massachusetts nonprofit technology came together, every tool was usually the right call when someone picked it. Nobody has looked at all of them together since.

What does Massachusetts nonprofit technology have to cover?

Any plan for Massachusetts nonprofit technology starts with how small most of these organizations are. The IRS publishes a file of every tax-exempt organization it knows about, by filing address. (IRS, Exempt Organizations Business Master File, data posted October 13, 2026) I counted the Massachusetts file myself. By mailing address, Worcester County has about 4,340 tax-exempt organizations, and about 3,590 of them are 501(c)(3) charities.

That is roughly one tax-exempt organization for every 200 people in a county of 888,502. (U.S. Census Bureau, Vintage 2025 population estimates)

Most of them are small. Of the county's 501(c)(3)s that have a revenue figure on file with the IRS, about two in three reported $50,000 or less, and fewer than 300 reported more than $1 million. Many organizations, churches among them, have no revenue figure on file at all.

Small doesn't mean simple. A food pantry in Spencer might keep client records, run volunteer background checks, take card donations, send a newsletter and store grant reports in a shared drive: five systems, five sets of logins. The useful Massachusetts nonprofit technology question isn't which software to buy. It is which few decisions protect the people who trust you.

Who should be able to see donor and member data?

Fewer people than can see it today, in most organizations. The state's data security regulation, 201 CMR 17.00, applies to every "person" that owns or licenses personal information about a Massachusetts resident. It defines a person as "a natural person, corporation, association, partnership or other legal entity," with exceptions only for state and local government bodies. A nonprofit corporation or association is a person under that definition. (201 CMR 17.02, via Cornell LII)

Personal information has a narrow meaning in that rule: a resident's name together with a Social Security number, a driver's license or state ID number, or a financial account, credit card or debit card number. Donor records with card or bank details count. So do volunteer records that hold a license number from an ID check.

Any organization holding that information must "develop, implement, and maintain a comprehensive information security program" in writing, scaled to its size and resources. (201 CMR 17.03) The technical side asks for access limited "to those who need such information to perform their job duties," and "unique identifications plus passwords" for each user. (201 CMR 17.04)

I wrote a longer guide to Massachusetts WISP requirements under 201 CMR 17.00 (opens in a new tab). For a small nonprofit, the practical Massachusetts nonprofit technology checklist is short:

• Map where the sensitive data lives, including the spreadsheet someone exported last spring.
• Give access by role. A volunteer who sorts donations does not need to see giving history. A board member does not need the donor export.
• Delete the copies. Old exports and email attachments add exposure and no value.
• Write it down. One plain document: who has access, how it is reviewed, what happens when someone leaves.

Donor privacy also has a federal angle worth knowing. The IRS says tax-exempt organizations are "generally not required to disclose publicly the names or addresses of its contributors," with private foundations as the exception. (IRS, contributors' identities not subject to disclosure) Treat the donor list with the same care as the card data.

Volunteer background checks carry their own rule. Massachusetts requires that electronically stored criminal record information (CORI) be "password protected and encrypted," with access limited to approved employees, and it cannot be kept longer than seven years after the volunteer's service ends or the decision is made, whichever is later. Cloud storage is allowed only with a written agreement that includes the state's minimum security requirements. (803 CMR 2.14)

What does a donation page need to be safe?

The best donation page is one where your website never touches a card number.

The card industry's security standard, PCI DSS, applies to "entities that store, process, or transmit cardholder data," and to anything that "could impact the security of the cardholder data environment." (PCI Security Standards Council) A nonprofit that accepts cards is a merchant under that standard.

The simplest path is a form hosted or embedded by your processor, so card numbers go straight to them. Your own page still matters. In January 2025 the PCI Security Standards Council said merchants using the simplest self-assessment must "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." (PCI SSC, January 30, 2025)

The Council's FAQ gives two ways to do that: protect the page yourself, or get confirmation from your processor, itself validated against PCI DSS, that its embedded form, set up per its instructions, protects against script attacks. (PCI SSC FAQ 1588) For Massachusetts nonprofit technology on a small budget, the second is usually the realistic one. Ask your processor for it in writing.

One more risk deserves a sentence. Donation forms that accept any amount are a favorite target for card testing, which OWASP defines as "multiple payment authorisation attempts to verify the validity of bulk stolen payment card data." (OWASP OAT-001, Carding) A bot check on the payment step and an alert on unusual failed payments are the basics. Your processor's settings are the place to start.

The website itself needs an owner, like every other piece of Massachusetts nonprofit technology. The domain and hosting often sit in a former volunteer's personal account. Our explainer on who owns the website and the login covers how to get them back.

How should volunteers and shared accounts work?

In Massachusetts nonprofit technology, the rule is one person, one login, and nobody keeps access after they leave.

Shared accounts feel practical, but a shared account can't be shut off for one person, and nobody can tell who changed what.

Massachusetts asks for the opposite: unique IDs per user, access restricted to "active users and active user accounts only," and steps "preventing terminated employees from accessing records containing personal information." (201 CMR 17.04; 201 CMR 17.03) In my experience volunteer rosters change more often than staff lists, so this matters more for Massachusetts nonprofit technology, not less. Brian keeps an offboarding checklist for cutting off a departing person's access (opens in a new tab), and it works for volunteers too.

People are the most common path in. Verizon's 2026 Data Breach Investigations Report found the human element "was present in 62% of breaches." (Verizon DBIR 2026, executive summary) The Massachusetts nonprofit technology fixes are unglamorous and cheap:

1. Give each volunteer their own account in the systems they need, with the smallest role that does the job.
2. Turn on multifactor authentication everywhere it exists. CISA says "any MFA is better than no MFA," and that phishing-resistant methods are the standard to work toward. (CISA, Multifactor Authentication)
3. Use a password manager with shared vaults for the few logins that truly can't be split, such as a vendor portal that allows one user.
4. Keep a roster of who has access to what, and walk it whenever someone leaves.

Why does nonprofit email land in spam?

Often because the domain was never set up to prove the mail is really from you.

Since February 1, 2024, Google has required every sender to Gmail to set up "SPF or DKIM email authentication" and keep reported spam rates below 0.3%. Senders of more than 5,000 messages a day must also set up DMARC and offer one-click unsubscribe on marketing mail. (Google, Email sender guidelines) Yahoo publishes the same core rules, including "Implement SPF or DKIM at a minimum" for all senders. (Yahoo Sender Hub) Microsoft announced similar requirements for high-volume senders to Outlook.com in 2025. (Microsoft, April 2025)

A small newsletter is well under 5,000 a day, but Massachusetts nonprofit technology sends mail from several places at once: the office mailbox, the newsletter tool, donation receipts, the event platform. Set SPF and DKIM for every service that sends as your domain, publish a DMARC record starting with a monitoring policy, and honor unsubscribes quickly.

You can see what your domain publishes today with a free DNS lookup tool (opens in a new tab) on kief.dev. Look for TXT records that start with v=spf1 and v=DMARC1.

What should a nonprofit back up, and how?

Everything you could not rebuild by Monday: the donor database, financial records, grant files and the website. And a backup only counts once you have restored from it.

CISA's ransomware guidance is direct: "Maintain offline, encrypted backups of critical data" and "regularly test the availability and integrity of backups in a disaster recovery scenario." For data that lives in cloud services, it suggests a separate provider for backups "in case all accounts under the same vendor are impacted." (CISA #StopRansomware Guide)

A cloud donor system is not a backup of itself. If the one admin account is lost, or a sync deletes a folder everywhere, the copy has to sit somewhere else. Two numbers help a board decide how much of the Massachusetts nonprofit technology budget goes to backups: how much data you could afford to lose, and how long you could afford to be down. Our short guide to recovery time and recovery point explains both in plain terms.

Once a year, restore one piece of your Massachusetts nonprofit technology to a test location and time it.

Can staff use AI with donor data?

Yes, with rules written down first.

In April 2024 the Massachusetts Attorney General issued an advisory saying AI developers, suppliers and users "must take the necessary and appropriate steps to safeguard personal information used by those systems," citing 201 CMR 17.03 and 17.04. (Massachusetts AGO, AI advisory, April 2024) Press coverage summarized it as existing consumer protection, anti-discrimination and data security laws still applying to the new tools. (WBUR, April 17, 2024)

The same regulation asks you to choose service providers "capable of maintaining appropriate security measures" and to require those measures by contract. (201 CMR 17.03(2)(f)) An AI tool that receives donor records is a service provider in practice. I'd add three AI rules to your Massachusetts nonprofit technology policy before anyone pastes a donor list into a chat window:

• Which tools are approved, on accounts the organization controls, not personal ones.
• What never goes in: card or bank numbers, ID numbers, CORI results and anything a client shared in confidence.
• Who reviews the output before it reaches a donor, a grantor or the public.

AI helps with the work nonprofits have too much of: grant narrative drafts, thank-you letters, program summaries with names removed. I wrote a guide to building an AI policy for your team (opens in a new tab) that works at nonprofit scale. Brian looked at whether staff can put customer data into AI tools (opens in a new tab), and the same questions apply to donor data.

What should a board ask about Massachusetts nonprofit technology?

Boards already sign off on money in Massachusetts. Every public charity must register with the Attorney General's Non-Profit Organizations/Public Charities Division before it raises funds here and file an annual report. Above $500,000 in gross support and revenue, the report needs a CPA's financial statement: a review report up to $1 million, a full audit above that. (M.G.L. c. 12, s. 8E; M.G.L. c. 12, s. 8F; AGO Non-Profit Organizations/Public Charities Division)

Massachusetts nonprofit technology deserves the same attention. CISA's Cyber Essentials, written for leaders of small organizations, starts with the leader: "Drive cybersecurity strategy, investment, and culture." (CISA, Cyber Essentials) Six questions cover most of Massachusetts nonprofit technology:

1. Where does our donor, client and volunteer data live, and who can see each piece?
2. Do we have a written information security program, and when was it last reviewed?
3. Does every person have their own login, with multifactor turned on?
4. When did we last restore something from backup, and how long did it take?
5. Which vendors hold our data, and do our contracts require them to protect it?
6. If we had a breach tomorrow, who would we call, and who notifies the state?

The sixth has a legal answer: Massachusetts requires notice to the Attorney General, the Director of Consumer Affairs and Business Regulation and the affected residents "as soon as practicable and without unreasonable delay." (M.G.L. c. 93H, s. 3)

For the rules themselves, MyRHC keeps an index of Massachusetts compliance sources (opens in a new tab) with links to the official documents.

Where should a Massachusetts nonprofit technology plan start?

With a spreadsheet. A youth arts program in Clinton with two staff and forty volunteers, for example, might spend its first month on Massachusetts nonprofit technology like this:

1. Week one: inventory. Every system, its admin login and its data, including the domain and website host.
2. Week two: accounts. Replace shared logins with personal ones, turn on multifactor and remove anyone who has left.
3. Week three: money and mail. Confirm the processor hosts the donation form, get its script-protection confirmation in writing, and set up SPF, DKIM and DMARC.
4. Week four: backups and policy. Restore one thing from backup, write the AI rules on one page and bring the six questions to the next board meeting.

None of that requires new software. Good Massachusetts nonprofit technology requires someone to own it.

This article is general information, not legal advice. Kief Studio is not a law firm, and reading it does not create an attorney-client relationship. Laws and regulations change, so check the current text and talk with a licensed Massachusetts attorney about your situation.