Registered charity, exposed surface to A+ headers in 6 weeks

The problem

A national registered Canadian charity — annual revenue in the eight figures, donor records in the hundreds of thousands — engaged us after the board flagged a competitor’s recent breach as a strategic risk. The CEO’s framing was direct: “If we were the next headline, what would the gap audit show?”

The leadership team suspected they had several known weaknesses (no formal MFA policy, no incident-response runbook, mixed-tenancy email) but had no current view of the rest of the attack surface.

The constraint

This is the constraint that makes charity work different from SMB security work: the engagement could not interrupt active fundraising. They were six weeks out from a major giving campaign with $4M+ pipeline. Any change that risked downtime, broken email deliverability, or staff confusion during the campaign would be net-negative even if it raised posture.

So the brief reduced to: improve posture meaningfully, ship board-ready documentation, do not interrupt operations.

The approach

We ran the engagement in three parallel tracks.

Track 1 — External attack-surface audit (week 1–2)

A standard external posture sweep: DNS hygiene, exposed services, certificate chain, email authentication (SPF, DKIM, DMARC), public-facing web surface (CSP, HSTS, secure cookies, security headers, JavaScript dependency audit), public mention scrape for leaked credentials or doxxed staff details.

Findings ranked by exploitability × blast radius. We surface this as a single ranked list, not a 200-page PDF. The board needed to be able to read the top ten in five minutes.

Track 2 — Identity & access hardening (week 2–4)

The biggest leverage was identity. MFA coverage was 18% — typical for charities that grew faster than their IT function. We rolled out phishing-resistant MFA in three waves, sequenced by role:

1. Wave 1 (week 2) — Finance, donor-data handlers, and executives. These accounts had the highest blast radius and the smallest population, so rollout could be done with hands-on support for each user.
2. Wave 2 (week 3) — Program staff with access to donor records.
3. Wave 3 (week 4) — All remaining staff.

Each wave included a 10-minute on-camera enrollment session and a written runbook for the IT lead so we weren’t a permanent dependency.

Track 3 — Web posture & PIPEDA documentation (week 4–6)

The public site was migrated to a strict Content Security Policy, HSTS preload, and a strict referrer policy. We added a /.well-known/security.txt and a public security policy page so future researchers had a clear disclosure path.

In parallel we drafted a PIPEDA-aligned privacy posture document for the board: data inventory, lawful basis for each processing activity, retention policy, incident-response runbook, sub-processor list. The deliverable was structured to also satisfy the CyberSecure Canada self-attestation, so the charity could pursue certification without a second round of documentation work.

The outcome

• Mozilla Observatory grade: F → A+
• Staff MFA coverage: 18% → 100%
• At-rest encryption for donor data: partial → full
• Documentation: board-ready PIPEDA + CyberSecure Canada package delivered
• Operational continuity: zero campaign downtime, zero email-deliverability incidents during the rollout window

The campaign that the engagement was scoped around hit its target. The charity is now on a retainer for continuous posture management.

What we’d say to another charity in the same position

Charities consistently underestimate two things: (1) how much identity-layer leverage they have left on the table — phishing-resistant MFA across the staff is usually the single largest posture move available, and (2) how publicly visible their security gaps are. We were able to fingerprint the absence of HSTS and the SPF/DKIM/DMARC configuration from outside their network in under an hour.

The fix is not always a big project. The first version of “good enough” is often six weeks of focused work, not six quarters.