Meridian Family Services: Closing an Offboarding Gap Before an Audit Found It

A funder compliance question forced a check nobody had run systematically. Four of eleven departed employees still had some access.

At a glance

1. The trigger

Meridian receives funding from several institutional funders, one of which introduced an expanded data governance section in its annual compliance questionnaire. The relevant question asked the organisation to confirm that access to client and case data is fully removed when an employee leaves, and to describe how that removal is verified.

Meridian's honest answer, before this project, was that removal was performed but not independently verified. The admin assigned a profile and permission sets on hire, and removed them on departure, and had reasonable confidence this worked, but had no record confirming it and had not checked systematically.

2. Why verification had not been happening

The organisation's Salesforce access model is more complex than average for its size, because Nonprofit Cloud with Person Accounts enabled means client records are governed by both Account-side and Contact-side permission configurations simultaneously, in addition to the standard profile, permission set, role hierarchy and sharing rule layers.

Confirming one departed employee's full effective access, across all of that, by hand, was estimated by the admin at 45 minutes to an hour per person, given the added complexity of the dual object model. Eleven departures over the relevant period meant roughly eight to eleven hours of investigation to complete the check the funder was asking about, on top of existing programme, IT and finance responsibilities.

Every client record carried two permission models to reconcile, not one.

3. What was checked

The admin installed Who Sees What, a free native permission inspector, and worked through the list of eleven employees who had left the organisation in the previous eighteen months, checking each one's current effective access.

For each departed employee, the check confirmed: whether the user record was deactivated, whether any permission set or permission set group assignment remained active, whether any manual share existed on a client or case record naming that user directly, and whether role hierarchy position, if the account were ever reactivated, would grant any residual visibility.

4. Findings

One employee accounted for both a retained permission set group membership and a manual share, which is why the individual counts sum to more than the total affected.

What the manual shares were

All three manual shares traced to genuine, reasonable original purposes: two were placed during cross-programme collaborations where a staff member from one programme was given visibility into a specific case outside their normal team, and one was placed to allow a departing employee's replacement a transition period of shared visibility before full handover. In all three cases, the manual share was never revisited after its original purpose ended, and departure processing did not include a step to check for or remove manual shares, since manual shares are not touched by profile or permission set removal.

What the permission set group issue was

Two employees had been individually removed from named permission sets as part of offboarding, but remained members of a permission set group that separately granted overlapping access to client records. The offboarding checklist in use referenced removing permission sets by name and did not separately reference permission set group membership, so this step was consistently missed for anyone whose original access included a group assignment.

Seven Setup screens, manually cross-referenced, versus one resolved answer per employee.

5. Remediation

All four affected departed employees had their residual access removed within the same week the findings were identified: permission set group memberships were revoked directly, and the three manual shares were deleted after confirming with the relevant programme leads that the original purpose no longer applied.

The offboarding checklist was updated to include an explicit step to check for and remove permission set group membership separately from named permission sets, and a step to search for and remove manual shares associated with the departing employee, in addition to the existing deactivation and permission set removal steps.

6. Response to the funder

Meridian's response to the compliance questionnaire described the audit performed, the findings, and the remediation, including the updated offboarding checklist as a forward-looking control. The funder's response noted the completed audit and updated process favourably, treating the discovery and correction of a real gap as evidence of an active control environment rather than as a negative finding in itself.

7. Analysis

The gap was not caused by carelessness. Every individual offboarding action taken, deactivation and named permission set removal, was performed correctly according to the checklist that existed at the time. The gap existed because the checklist itself did not cover permission set groups and manual shares as distinct items.

The audit was only practical because the per-user check was fast. At the pre-tool estimate of 45 minutes to an hour per departed employee, checking eleven people was a multi-day undertaking competing against ongoing work, and would very plausibly have been deferred past the funder's response deadline. At a few minutes per employee, it fit inside a single afternoon.

Person Accounts specifically increased the manual cost that made this impractical before. The dual Account and Contact object model underlying every client record meant each manual check involved reconciling two separate sets of object, field and sharing configuration rather than one.

8. What we would do differently

Build the offboarding checklist to reference outcomes, not actions. The original checklist said "remove permission sets," an action, rather than "confirm zero residual access," an outcome. A checklist framed around confirming the outcome would have prompted checking permission set groups and manual shares even without prior knowledge that those specific mechanisms existed.

Schedule a recurring check rather than treating this as a one-time response to the funder. A quarterly recurring check of the past quarter's departures would catch the same class of gap on a predictable schedule rather than depending on an external prompt to surface it. A fuller checklist for onboarding and offboarding verification is covered here.

Who Sees What is built and maintained by TwinStack Solutions, a Salesforce partner. Questions: [email protected]