Skip to content

CRM Data Security & PII Handling

[HYPOTHESIS] — planned, not implemented. No CRM is selected or deployed, so none of the controls below exist yet. This page states the bar any chosen tool and configuration must meet before it touches a real person's record. It is a working design, not a verified safeguard, and not legal advice. It needs [EXPERT REVIEWED] sign-off (privacy/nonprofit-data counsel, and a practitioner who works with the relevant populations) before any participant data is entered.

Do not read this page as a claim that BNI's data is protected. It describes intentions. Until the controls are built, tested, and reviewed, treat participant PII as unprotected and avoid collecting it.

Why this bar is higher for BNI

BNI's program participants include people in recovery, reentry, formerly incarcerated individuals, and the elderly. For these populations a data disclosure is not an inconvenience — it can mean re-incarceration risk, loss of housing or benefits, stigma, or physical danger. Under the Epistemic Honesty directive, overclaiming protection about these users is itself a harm. The directive's rule — "protect users of BNI products from epistemic harm" — applies directly: any safeguard described to a participant, partner, or funder must match what is actually built and tested.

This means the participant-data design is the gating concern in CRM selection (criterion 4 of the evaluation), not a feature to bolt on later.

Data minimization — collect the least

[HYPOTHESIS] The first and strongest control is to not hold sensitive data at all.

  • Collect only what a named workflow requires. If no current process uses a field, do not collect it. "Might be useful later" is not a justification.
  • Separate sensitive categories. Recovery status, criminal-justice history, health/disability information, and immigration status should not be stored unless a specific, reviewed program need exists — and then in the most restricted location available, never in a general contact record.
  • Prefer aggregate over individual. Where reporting needs only counts (cohort completion rate, devices awarded), store the aggregate, not per-person detail.
  • Keep participant data out of the public/Access-gated docs site entirely. Per the org CLAUDE.md, docs/ (including docs/vault/) is semi-public; PII does not belong there. A CRM, if adopted, is the system of record — not these pages.

Role-based access control

[HYPOTHESIS] Planned access model, to be verified against the chosen tool:

  • Least privilege by default. A new user sees nothing until a role grants it. Volunteers and partners get the narrowest scope that lets them do their task.
  • Participant records visible only to the staff running that program, not to donor/grant-side users or general volunteers.
  • Field-level restriction, not just record-level: a coordinator may see attendance without seeing recovery status or contact-of-record for safety reasons.
  • Audit logging of who viewed, edited, or exported a participant record — and a tested way to read that log. The evaluation's PII-walkthrough gate exists to confirm the candidate tool can actually do this.

CiviCRM's mature ACL model is one reason the evaluation leans toward it on this criterion; Twenty's controls are generic and unproven for this use. Neither is verified for BNI's case yet.

Retention & deletion

[HYPOTHESIS] Planned policy (needs [EXPERT REVIEWED] — retention may be constrained by grant, tax, or state requirements):

  • Define a retention period per data type up front, before collection — not "keep forever."
  • Schedule deletion / anonymization when the period lapses or a participant leaves the program and follow-up has ended.
  • Support participant data-rights requests (access, correction, deletion) as a real workflow, with the realistic limit that grant/tax obligations may require retaining some records — name that limit honestly rather than promising deletion that cannot occur.
  • Verify backups respect deletion, or document the gap. A "delete" that survives in backups indefinitely is not a deletion; if the tooling can't purge backups, say so.

Operational safeguards

[HYPOTHESIS] Baseline expectations for any deployment:

  • Encryption in transit (TLS) and at rest; verify, don't assume the tool's defaults.
  • No secrets or credentials in git (.env.local, gitignored) — per the shared coding standards.
  • Tested backup and restore (the evaluation's backup/restore drill is the gate).
  • Self-host vs. managed-hosting trade-off named explicitly: self-hosting keeps data under BNI control but puts patching/security burden on a 2-person team; managed hosting shifts that burden to a vendor but adds a third party with access. Undecided.
  • A documented incident response path — who is notified, and how participants are informed — before, not after, an incident.

Known unknowns

  • Whether any candidate CRM's access and audit controls actually satisfy this bar — untested.
  • Applicable legal regime — state breach-notification law, any grant-imposed data terms, HIPAA-adjacency for senior/health-related data — unconfirmed; needs counsel.
  • Whether retention obligations from funders or tax rules conflict with participant deletion rights — unresolved.
  • Who owns CRM data administration and security patching on a 2-person team — open.

Validation status

Every safeguard on this page is [HYPOTHESIS]. None is [EXPERT REVIEWED], [PILOT VALIDATED], or [EMPIRICALLY VALIDATED]. Promote individual items only after the relevant review or test, and update any participant-, partner-, or funder-facing statement to match — never ahead of it.