School Account Offboarding: Protect Access When the Roster Changes

A roster change can disable a central account while leaving access in a classroom application, shared resource, or supplier-managed system. School offboarding needs to follow the person through those connected services. Reconcile the authoritative roster with the application owner and test the approved removal route. Include active sessions and any local accounts. Schedule the check so it protects student information and does not interrupt learning.

Define who is leaving what

Separate a complete departure from a role change. A student moving to another school may need records retained while losing access to the previous campus. A teacher finishing a contract may also own a shared classroom site. Record the effective time, the systems involved, the person who authorizes the change, and any continuing relationship. Treat identity matching as a control: similar names and reused identifiers can produce a perfectly executed change to the wrong account. Use the established personnel or student identifier and resolve conflicting records before disabling access.

Follow the access paths

List the sign-in account, application-local accounts, active sessions, shared folders, forwarding rules, device enrollment, and any administrative delegation. Include services outside central single sign-on. For each one, identify whether access ends automatically, requires a separate action, or is deliberately retained. NIST SP 800-53 provides a broad account-management and access-control reference; the school-specific workflow proposed here turns those control concerns into a manageable operating record. Keep the investigation bounded to authorized administrative views rather than asking staff to share passwords.

Preserve the work without preserving the privilege

Before removing an owner, arrange the transfer of teaching materials, operational files, calendars, or service administration to an authorized successor. Record retention and privacy decisions with the responsible school function. Keeping a departed account active because it owns a folder creates a hidden exception; deleting its material immediately can interrupt teaching or remove records that should be preserved. A controlled transfer separates those decisions. Check links and automation that depend on the old account, and provide a contact route for staff who discover a missed dependency.

Verify the boundary and close the exception

Use an authorized test identity or an approved administrative verification to confirm that a removed role no longer reaches the selected service. Check existing sessions and application-local access, not only the directory flag. Also verify that the successor can perform the necessary work. Log failed removals, ambiguous ownership, and deliberately retained permissions as separate outcomes. Give each exception an accountable owner, a reason, a review date, and a practical expiry action. Start with a small departure batch before expanding across the full school estate.

Put the plan into practice

1. Reconcile the roster Match the approved departure list to actual account identifiers and resolve discrepancies.
2. Transfer ownership Confirm a successor can use necessary shared resources without the former account.
3. Remove and retest Apply the approved changes, then verify both denied access and continuing authorized work.

Worked example

What a useful outcome looks like

Close the batch when the identities reconcile, required work has a new owner, the selected denied-access tests succeed, and every remaining exception has a decision and review date. Retain the actual test records with the roster change.

Use the next approved leaver case to verify the complete route. Keep failures attached to the application owner until removal has been confirmed where the data is actually accessed.

References

• NIST SP 800-53: Security and Privacy Controls
• NIST SP 800-53A: Assessing Controls