It is the last week of a grant reporting period. The executive director of a community services organization is working through a backlog of approvals when an email arrives from a familiar supplier, on a thread that has been running for weeks, advising that their banking details have changed and asking that the outstanding invoice be redirected. She approves it, because it is Thursday, the report is due Monday, and the supplier is legitimate.
The money is gone within two hours. It was restricted grant funding, which means the organization now owes the funder an explanation, the program that money was allocated to is short, and the board has to be told at the next meeting.
We have seen versions of this at Canadian nonprofits more than once. It is not a technology failure in the usual sense. Nothing was hacked. The supplier’s mailbox was compromised, an attacker inserted a message into a real conversation, and an under-resourced organization operating under deadline pressure did what it does dozens of times a month.
Canadian nonprofits and charities occupy an uncomfortable position. They hold data as sensitive as anything a bank or a clinic holds, they operate with a fraction of the budget, and they run on a workforce that mixes permanent staff, volunteers, board members, and contract program workers with varying levels of technical literacy and very different access needs. Attackers understand this combination well.
Imagine Canada’s analysis has found that Canadian nonprofits are about as likely as businesses to experience a cybersecurity incident while spending roughly 62% less on prevention, an average in the range of $21,000 per year against roughly $55,000 for comparable businesses. The figure that should concentrate a board’s attention, though, is a different one: 27% of nonprofits that experienced an incident reported that it prevented them from delivering services to their community.
That is the distinction that makes this sector different. For a business, downtime is revenue. For a food bank, a shelter, a settlement agency, or a community health organization, it is people who did not get served that week.
GAM Tech has supported Canadian organizations with 20 to 200 users since 2012 across nine markets. What follows is the framework we use with nonprofit clients: what data you are actually responsible for, how to stretch a constrained budget using grants that most organizations under-use, how to manage access for a volunteer workforce, and how to sequence improvements when you cannot do everything at once.
The data mix is unusually sensitive. A nonprofit’s donor database contains names, contact details, giving history, and often payment information. That alone makes it a target. But many organizations also hold beneficiary information, which can include health details, case notes, immigration status, family circumstances, or records relating to minors. A single database compromise can expose both a major donor’s financial relationship and a vulnerable client’s case history.
Funds are restricted and reporting is external. A commercial business absorbing a fraud loss reports it to its own leadership. A nonprofit that loses restricted funds has to report to the funder, and in some cases to the CRA, and the incident becomes a factor in future grant applications.
The workforce is fluid by design. Volunteers turn over constantly, seasonal program staff arrive in cohorts, board members need access to governance material, and contract workers come and go with project funding. Every one of those transitions is an access provisioning or deprovisioning event, and most nonprofits have no HR system driving them.
Reputational damage is financial damage, directly. Giving is a trust transaction. Research on donor behaviour consistently shows that publicized breaches reduce giving, and the effect persists well past the incident. A commercial business that loses reputation loses sales it can win back with a better offer. A charity that loses donor trust loses the mechanism by which it exists.
The board is accountable but frequently not equipped. Nonprofit boards carry governance responsibility for organizational risk, including technology risk, and are typically composed of volunteers with expertise in the mission rather than in information security. That is not a criticism; it is a design feature of the sector. It does mean that risk has to be presented in terms a non-technical board can act on.
Nonprofit leaders frequently assume that privacy legislation applies to businesses rather than to charities. That assumption is wrong often enough to be dangerous.
PIPEDA. The federal Personal Information Protection and Electronic Documents Act applies to the collection, use, and disclosure of personal information in the course of commercial activity. Charities are not automatically exempt. Fundraising activity, selling or renting donor lists, running a social enterprise, and processing payments are all capable of constituting commercial activity, and the Office of the Privacy Commissioner has taken that position in relation to fundraising practices. Employee data at federally regulated organizations is separately covered. In practice, the safe planning assumption for a Canadian nonprofit of any size is that PIPEDA-equivalent obligations apply to donor and employee data, including the requirement to safeguard it and to report breaches that create a real risk of significant harm.
Provincial private-sector law. Alberta, British Columbia, and Quebec have their own private-sector privacy statutes that apply to organizations, and the Alberta and BC statutes explicitly capture non-profit organizations in relation to commercial activities. Quebec’s Law 25 is the strictest privacy regime in Canada, and it applies to any organization holding personal information about Quebec residents regardless of where the organization is located. A national charity with Quebec donors is subject to Law 25, including its privacy officer designation, consent, and breach notification requirements.
Health information law. Organizations delivering health-adjacent services may fall under provincial health privacy legislation for the information they collect in that capacity, which imposes materially stricter handling and retention obligations than general privacy law.
CRA record retention. Registered charities have record-keeping obligations under the Income Tax Act, including retaining donation receipt records and governing documents for prescribed periods. Retention is a security question as well as a compliance one, because data you are required to keep is data you are required to protect, and data you are not required to keep is risk you can retire.
The practical implication of all of this: a nonprofit needs to know what personal information it holds, where it is stored, who can reach it, and how long it is kept. That inventory is the foundation of everything else, and most organizations have never built one.
Here is the most common misconception we correct in nonprofit engagements. Leaders assume that the security capability they need is out of financial reach. In most cases it is already sitting unused in licensing they qualify for.
Microsoft nonprofit programs. Microsoft offers grants and deep discounts on Microsoft 365 for eligible nonprofit organizations, including donated licences for a defined number of users and discounted pricing above that threshold. For many organizations, this puts business-grade identity management, email security, device management, and information protection capability within reach at a fraction of commercial cost.
What the grant covers and what it does not. Two things to understand clearly. First, eligibility is specific and needs to be confirmed for your organization type; registered charity status is generally the pathway. Second, and more importantly, the higher-tier security features that matter most, meaning advanced threat protection, information protection labelling, and full device management, generally sit in the paid tiers rather than the fully donated ones. The good news is that nonprofit pricing on those tiers is substantially discounted.
The real gap is configuration, not licensing. This is the point worth emphasizing to a board. We routinely inherit nonprofit tenants where the organization is paying for, or has been granted, licences that include multi-factor authentication enforcement, conditional access, data loss prevention, and audit logging, none of which are switched on. The capability was funded. It was never configured. For an organization with a genuinely constrained budget, the highest-return technology project available is usually not a purchase; it is turning on what is already owned.
Other funding pathways. Discounted and donated software is available through nonprofit technology programs for a range of products beyond Microsoft. Some funders will support technology and capacity building as a line item if it is framed in terms of program continuity and data stewardship rather than as overhead. That framing matters, and it is worth the effort in a grant application.
This is the operational challenge that distinguishes nonprofit IT from small business IT, and it is rarely addressed well.
Shared logins. The single most common finding in a nonprofit environment is a shared account, usually for a volunteer-facing system or a front-desk workstation, with a password that has not changed in years and is known to former volunteers. Shared credentials make accountability impossible and offboarding meaningless.
Onboarding at volume. A seasonal program that brings in 30 volunteers in a week needs a provisioning process that is faster than manual account creation and more controlled than sharing a login. Group-based access assignment, tied to a defined role rather than to an individual, solves most of this.
Offboarding that never happens. Volunteers stop volunteering without resigning. There is no exit interview and no HR trigger. The practical solution is time-bound access: volunteer accounts provisioned with an expiry date matched to the program period, requiring an affirmative action to extend rather than an affirmative action to remove. This single change eliminates the majority of orphaned access in nonprofit environments.
Personal devices. Volunteers use their own phones and laptops. A blanket prohibition will be ignored. The workable approach is to define what volunteers can access from a personal device, keep organizational data inside managed applications rather than on the device itself, and be explicit about what the organization can and cannot see on a personal phone, because uncertainty on that point drives most resistance.
Board access. Board members need governance documents, frequently on personal devices, often without technical support. A dedicated, properly permissioned board portal or document library is a better answer than email attachments circulating indefinitely.
The scenario that opened this article is the most financially damaging attack pattern aimed at Canadian nonprofits, and it is entirely preventable with a procedural control rather than a technical one.
Supplier and banking change fraud. The defence is a written, mandatory verification step: any change to payment details for any payee is verified by telephone, to a number already held on file, with a person known to the organization, and the verification is documented. No exceptions for urgency, and specifically no exceptions for the executive director. The people who can move money need to practise this out loud, not read it in a policy.
Executive impersonation. A request that appears to come from the executive director or board chair, asking for an urgent transfer or a gift card purchase, arriving at a moment when that person is known to be travelling or at a conference. The control is the same second-channel verification, and it needs explicit permission from leadership so that staff are not afraid of causing offence by calling to check.
Donation page and payment processing risk. If donations are processed through your own website, the security of that payment path matters, as does the scope of what your platform stores. Wherever possible, use a hosted payment provider so that card data never touches your infrastructure, which reduces both risk and compliance burden substantially.
Insider and volunteer access risk. Uncomfortable but necessary to address. Access to donor financial information should be limited to the roles that need it, with logging in place. This is not distrust; it is protection for the volunteers and staff themselves, because a documented access trail is what clears people when something goes wrong.
For a nonprofit, the right way to frame recovery planning is not around revenue loss but around program delivery.
Set recovery targets against services, not systems. The question is not how long you can be without a file server. It is how long you can be without the client management system before a program stops, how long without the donor database during a campaign, and how long without payroll before staff are not paid. Those answers give you a recovery time objective that a board can understand and approve.
Immutable backups, and a tested restore. Backups that an attacker can encrypt or delete are not backups. Immutable or offline copies, verified regularly, with a restore that has actually been performed and dated. The last point matters disproportionately: in our experience, the gap between organizations that have backups and organizations that have demonstrated a restore is very wide, and it is only ever discovered at the worst possible moment.
A documented incident response plan the board has seen. Who decides to take systems offline. Who contacts the funder. Who contacts affected donors or clients. Who notifies the privacy commissioner and within what window. Who speaks publicly. Four or five decisions, written down, before they are needed.
Cyber insurance. Not legally required for most Canadian organizations, but frequently required by funders, lenders, or larger partners. If you carry it, be aware that underwriters now expect specific controls, including multi-factor authentication, endpoint detection and response, tested backups, and documented security awareness training, and that a control described on an application but absent at the time of loss is grounds for denial.
Organizations with constrained budgets need a defensible sequence rather than a wish list. This is the order we recommend, and the reasoning matters as much as the order because a board has to approve it.
First, identity. Multi-factor authentication on every account with no exceptions, legacy authentication disabled, shared logins eliminated, and administrative access limited to named individuals. Rationale: account compromise is the entry point for the majority of incidents, and this work is largely configuration of licensing you already hold.
Second, payment verification. The written banking-change verification procedure, practised with the people who can move money. Rationale: it is free, it takes an afternoon, and it addresses the attack with the highest direct financial cost.
Third, backup and restore verification. Confirm immutability, run a restore, document the result and the recovery time. Rationale: this is your floor. Everything else reduces the probability of an incident; this determines whether an incident is a bad week or an existential event.
Fourth, endpoint protection coverage. Modern endpoint detection and response on every device, staff and volunteer-facing, at full coverage rather than partial. Rationale: partial coverage is the gap attackers find, and funders and insurers both read partial coverage as none.
Fifth, access lifecycle. Time-bound volunteer accounts, role-based provisioning, and a quarterly access review. Rationale: it converts an ongoing manual burden into a process, and it eliminates orphaned access permanently rather than repeatedly.
Sixth, data inventory and retention. Know what personal information you hold, where, and for how long, and retire what you are not required to keep. Rationale: this reduces the scope of every future incident and every future compliance obligation.
Seventh, training and awareness. Quarterly, including volunteers, with a specific module for the finance function. Rationale: it sustains the value of everything above it.
Most organizations can complete the first three within a quarter, largely with existing resources.
Boards do not need a technical briefing. They need to be able to answer five questions, and the role of management is to make sure they can.
What personal information does the organization hold, and about whom. What would stop if our systems were unavailable for a week, and for how long could we tolerate that. What is our single largest unaddressed risk, and what does closing it cost. If we suffered a breach of donor data tomorrow, who does what in the first 24 hours. Are we carrying insurance, and do we currently satisfy the conditions of that policy.
An annual one-page report answering those five questions, with a status against the roadmap above, is more governance value than a fifty-page assessment nobody reads.
GAM Tech is B Corp certified, which means we are held to a verified standard on how we treat our people, our community, and our environmental impact. For mission-driven organizations evaluating a technology partner, that is a relevant signal rather than a marketing line.
We are also SOC2 certified and Great Place to Work certified, we run on EOS with fully documented core processes, and our support team is internal and never outsourced, with a 5-minute response commitment delivered on 99%+ of tickets. We operate from nine markets across Alberta, British Columbia, Ontario, and Quebec, with bilingual English and French support in Ottawa and Montreal, which matters for national organizations and for any charity with Quebec operations subject to Law 25.
For nonprofit clients specifically, our engagement covers confirming and applying Microsoft nonprofit licensing entitlements so you are not paying commercial rates for capability you qualify to receive at a discount, configuring the security features already included in that licensing, building the volunteer access lifecycle so provisioning and offboarding are processes rather than favours, donor data inventory and retention work, and the board-ready annual risk summary described above.
Project packs are included in our managed services agreement, so policy development, roadmap work, and documentation are not separately invoiced. Silver plans start at $110 per managed device per month with a $1,000 monthly minimum, and most nonprofits find the device-based model favourable because volunteer-heavy organizations typically have far fewer managed devices than people.
Does PIPEDA apply to our donor database? Assume yes for planning purposes. PIPEDA applies to personal information handled in the course of commercial activity, and fundraising, payment processing, social enterprise operations, and list rental have all been treated as capable of meeting that threshold. Organizations in Alberta, British Columbia, and Quebec also face provincial private-sector legislation, and any organization holding information about Quebec residents is subject to Quebec Law 25 regardless of where it is based.
What does a Microsoft nonprofit grant actually cover? Eligible nonprofits can receive donated licences for a defined number of users plus discounted pricing above that, which puts business-grade identity, email security, and device management within reach. The advanced security tiers generally sit in the discounted paid plans rather than the donated ones. Eligibility needs to be confirmed for your organization type, and registered charity status is normally the pathway.
How do we manage IT access for volunteers? Provision accounts against defined roles rather than individuals, assign access through groups, and set an expiry date matched to the program period so that access lapses by default and has to be actively extended. Eliminate shared logins entirely. This one change addresses the majority of orphaned access we find in nonprofit environments.
How much should a Canadian nonprofit spend on IT and security? Sector data suggests nonprofits spend far less on prevention than comparable businesses, roughly 62% less by Imagine Canada’s analysis, and the resulting exposure is real. Rather than a percentage, we recommend costing the prioritized roadmap in this article and funding it in sequence. The first three items are achievable within a quarter and largely involve configuration rather than new spend.
What do we do if donor data is breached? Contain first, then assess whether the breach creates a real risk of significant harm, which is the PIPEDA threshold for notification to the Privacy Commissioner and to affected individuals. Keep a record of the breach regardless of whether it is reportable, because record-keeping is itself an obligation. Notify your insurer early, and follow your incident response plan rather than improvising, which is the argument for writing one in advance.
How do we stop fraudulent banking change requests? A mandatory written verification step: every payment detail change is confirmed by telephone to a number already on file, with a known contact, and documented. No urgency exception, and explicit permission from leadership for staff to call and verify without fear of causing offence. Practise it out loud with the people who can move money.
Are we required to have cyber insurance? Not by general law. It is frequently required by funders, lenders, landlords, or larger partner organizations under contract. If you carry it, verify that you actually satisfy the control conditions in the policy, because a control claimed on the application and absent at the time of loss is a common basis for denial.
How long do we need to keep records? Registered charities have record-retention obligations under the Income Tax Act covering donation receipts, governing documents, and financial records for prescribed periods, and program records may carry separate obligations under provincial legislation. Confirm the specific periods for your organization, then retire data you are not required to keep, because unnecessary retained data is pure risk.
What is the single highest-value security control for a small charity? Multi-factor authentication on every account, with no exceptions. It is included in licensing you likely already hold, it takes a configuration project rather than a purchase, and it prevents the account compromise that begins most incidents.
How do we present technology risk to our board? Answer five questions annually in one page: what personal information we hold, what would stop if systems were unavailable for a week, our largest unaddressed risk and the cost to close it, who does what in the first 24 hours of a breach, and whether we satisfy our insurance conditions. That is more useful governance than a long technical assessment.
What should we look for in an IT provider that has not worked with nonprofits before? Ask three questions. Can you confirm and apply our nonprofit licensing entitlements. How would you handle provisioning and offboarding for 30 seasonal volunteers. What is your plan for the first 24 hours if our donor database is compromised. A provider that answers those three well understands the sector; a provider that answers only the first is a reseller.
Nonprofits are asked to do more each year with funding that does not grow at the same rate, and technology spending competes directly with program delivery. That tension is real, and it is why the sequence matters more than the total. The first three steps in the roadmap above are largely configuration of capability you already have, and together they address the incidents most likely to stop your programs.
GAM Tech supports Canadian nonprofits and charities from nine markets across Alberta, British Columbia, Ontario, and Quebec. If you would like a straightforward assessment of where your organization stands, including a review of the nonprofit licensing you may be entitled to and are not using, contact us for a conversation.