Dev.to Security 🔐 Cybersecurity 👁 0 📖 5 min read

Nonprofit IT on a Budget: A Developer's Guide to Funder and Compliance Requirements

If you work in tech, someone has probably asked you to “just help with the IT” for a nonprofit. Maybe you volunteer for one, maybe a friend runs a small charity, or maybe you were hired as an office manager and inherited

If you work in tech, someone has probably asked you to “just help with the IT” for a nonprofit. Maybe you volunteer for one, maybe a friend runs a small charity, or maybe you were hired as an office manager and inherited the router. Then a grant arrives with a security clause, or an insurer asks whether the team uses multi-factor authentication, and the honest answer is “we’re working on it.”

This post is a practical plan for that situation. The goal isn’t an enterprise security programme. It’s to cover the fundamentals, spend as little as possible, and keep evidence that you did the work. At ZIA Networks, we think of this as the heart of nonprofit IT on a budget: do the basics, then prove it.

Step 1: Scope your obligations first.

“Compliance” isn’t one thing. What applies depends on the data you hold and where you operate. Answer four questions:

What data do we hold? Donor payments, health information, and children’s records carry very different risks.
Where are our people and funders? Depending on location, GDPR, US state privacy laws, India’s data protection rules, or FCRA (for foreign contributions) may apply.
What do our grant agreements require? Funding contracts often include technology and data clauses nobody reads until reporting time.
Do we accept card payments? Your payment processor usually carries most of the burden, but you still follow its rules.

Write the answers on one page. Treat it like a requirements doc. Every later decision should trace back to it.

Step 2: Build an asset and access inventory.

You can’t secure what you haven’t listed. A spreadsheet is fine:

System Data: It holds who has access to the owner.
Donor CRM names, giving history Fundraising team Development lead
Email platform: Everything All staff admin
Shared drive mixed files Unknown Unknown

The “Unknown” rows are where your risk lives. Expect to find a former volunteer with admin rights, a personal cloud account used “temporarily,” and a shared drive nobody has audited in years. Auditors and funders ask for exactly this.

Step 3: Ship the high-impact, low-cost controls.

MFA. Enable it on email, your CRM, banking, and cloud storage first. Prefer authenticator apps or hardware keys over SMS when possible. It’s usually a free setting and the single most valuable step.

Password manager. Replace shared spreadsheets and sticky notes. It makes offboarding far easier, because you revoke access instead of rotating every shared password and hoping people comply.

Patching. Turn on automatic updates for operating systems, browsers, and apps. Track exceptions, like old machines or unsupported software, in your inventory.

Backups. Follow 3-2-1: three copies, two storage types, one offsite. Then test a restore. An untested backup is an assumption, not a control.

Least privilege. Give each person only what their role needs. An event volunteer doesn’t need donor-giving history. Review permissions twice a year and remove accounts the day someone leaves.

Device encryption. Modern laptops and phones include built-in full-disc encryption. Turning it on takes minutes and can turn a lost device from a reportable breach into an inconvenience.

Step 4: Claim nonprofit discounts.

Check TechSoup and similar regional programmes, Google for Nonprofits, Microsoft’s nonprofit offers, and credits from cloud and security vendors. Volunteer IT networks can sometimes do a one-time review for free. Offers and eligibility change, so confirm current terms with each provider.

Step 5: Write policies people will actually follow.

A one-page policy everyone follows beats a 40-page one nobody reads. Start with four:

Acceptable use: what staff and volunteers may do with devices and accounts
Data handling: what you collect, why, how long you keep it, who sees it
Incident response: who to call and what to do first
Onboarding and offboarding: how access is granted and, more importantly, revoked

Start from free templates, then edit them to describe what your team really does.

Step 6: Train the humans.

Most incidents at small organisations aren’t clever exploits. They’re convincing phishing emails, files sent to the wrong person, and reused passwords. A 30-minute session once or twice a year, using real phishing examples, helps. Culture matters more than content: make it safe to say “I think I clicked something bad.” Early reports limit damage, and training records are good evidence for funders.

Step 7: Keep evidence as you go

Compliance is mostly about showing consistent, reasonable effort. Keep one evidence folder with:

Your requirements summary and inventory
Current policies with review dates
Training dates, topics, and attendees
Access review notes
Backup test results
Step 8: Know when to bring in professionals

Consider paid help if you hold sensitive data (health, immigration, financial, or children’s records), a funder requires a formal assessment, you’re migrating systems, or you’ve outgrown volunteer-only IT. A part-time consultant or managed IT provider, such as ZIA Networks, can take on monitoring, security, and compliance support. Whoever you pick, ask about nonprofit pricing and plain-language reporting you can hand to funders.

Step 9: Make it a routine
Quarterly: review access and run a backup restore test (about 30 minutes).
Twice a year: permissions review
Annually: policy review and training refresher
Every departure: remove accounts the same day.
TL;DR
Scope your obligations before buying anything.
Inventory systems, data, and access.
Start with MFA, a password manager, updates, tested backups, least privilege, and encryption.
Keep policies short and honest, and train without blame.
Collect evidence continuously, not only before audits.

Pick one step this week. Enabling MFA or building the inventory are both great starting points.

Question for you: What’s the hardest IT or compliance problem you’ve run into at a small organisation? Tell me in the comments, and I’ll cover the most common ones in a follow-up.

Disclosure: I work with ZIA Networks, which supports nonprofits with IT and compliance planning. This post is general information, not legal or compliance advice. Confirm your specific obligations with your funders, legal counsel, or a qualified professional.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.