Reviewed by TRUST-IT ·
DECISION BRIEF
What you will be able to decide
For: Family office principals, operations leads and authorised representatives coordinating a change of adviser or staff.
Decide whether the agreed responsibilities can transfer with verified successor access, controlled revocation and visible exceptions.
- Establish authority and ownership separately for each entity and private account.
- Test the planned continuity path and verify revocation across the actual services.
- Keep credentials and unnecessary private information out of the acceptance record.
Start with authority, scope and the departure scenario
An adviser, assistant or finance director may have accumulated responsibilities across a family office, holding companies, trusts and personal arrangements. The person paying a subscription is not necessarily the legal account owner, and the ability to administer a system is not authority to disclose everything it contains. Name a transition sponsor and obtain the appropriate approval for each entity, service and dataset. Involve the relevant legal or privacy adviser where ownership, employment obligations or private communications require a decision.
Separate a cooperative, planned handover from an urgent or contested departure. For a planned transition, prepare successor access and recovery arrangements before the agreed cutover. If compromise, misuse or immediate exposure is suspected, authorised containment must proceed promptly alongside continuity and evidence preservation. Do not keep a risky account active merely to complete a checklist. This guide addresses continuity and access transfer; investigating past conduct requires a separately scoped mandate.
Build a responsibility register before changing accounts
Record each critical service, the entity or person that owns it, the business owner, technical administrator, billing contact, recovery contact and successor. Include the domain registrar, DNS, email tenant, password manager, cloud storage, document portals, devices, telecom services, backup platform and external support providers. Distinguish named user identities, privileged accounts, guest access and non-human service identities. Record dependencies such as a backup alert going to the departing adviser’s mailbox.
The working register should identify permissions and where credentials are securely held, not copy passwords, recovery codes or family financial information into a spreadsheet. Give each item a status, owner and evidence reference. An unconfirmed owner is an unresolved dependency, not a completed transfer. Apply a separate approval boundary for each household, legal entity and external adviser.
Secure ownership and recovery before the planned cutover
Confirm that authorised personnel can administer the service and recover it independently of the departing individual. Check recovery email addresses, telephone numbers, registered authentication methods, support contacts and any documented emergency access. Use named successor accounts and appropriate multifactor authentication. Store necessary secrets through the approved credential-management process; do not ask an adviser to share their personal password or impersonate them.
For domain and hosting services, verify registrant details, administrative roles, renewal ownership and the route for recovering access. A changed contact address does not automatically transfer contractual ownership. Identify whether a vendor-managed tenant, proprietary licence or personal subscription requires a provider-assisted transfer. Plan changes carefully where resetting a shared credential could interrupt integrations, automated tasks or access needed by other authorised people.
Transfer operational work without copying every private record
Decide which business information the successor needs and who approves that access. Review shared mailboxes, delegated calendars, cloud folders, external guests, public sharing links and automated forwarding. Transferring a folder’s ownership is different from checking all the people and links that can still reach it. Replace informal personal-account sharing with approved access under the correct entity where practical.
Mailbox reassignment, exports, retention settings and licence removal have different consequences across platforms. Determine the required preservation and continuity arrangements before deleting an account or removing a licence. Avoid unrestricted forwarding of every message to the successor: define purpose, recipients and review date. Record exceptions for personal, privileged or otherwise restricted material, and keep household records separate from company records when authority differs.
A controlled handover with an urgent-risk route
The sequence below describes a planned transition. Active risk requires immediate authorised containment in parallel with continuity and preservation.
- AuthorityEntities, owners and permitted changes
- MapAccounts, recovery and dependencies
- PrepareSuccessor identity and task checks
- Cut overAgreed revocation and continuity
- AcceptEvidence, exceptions and owners
A successor test does not authorise leaving an unsafe account active. Urgent containment takes precedence over completing the planned sequence.
Handle banking authority through the bank’s approved process
Technical access and financial authority are different decisions. Inventory who can view balances, create beneficiaries, prepare payment instructions, approve transfers or amend mandates, without copying account balances or transaction histories into a general handover pack. The authorised finance owner should coordinate changes directly with each bank, custodian or payment provider and obtain confirmation using its established process.
Do not transfer banking passwords, reuse another person’s token or treat email access as payment authorisation. Update signatories, delegated permissions, approval thresholds, registered devices and callback contacts where applicable. Independently verify changed payment instructions through a previously established contact route. Successor testing should use the provider’s approved verification method; the handover itself is not permission to initiate a real transfer.
Test the successor’s tasks and document the cutover
Define a small acceptance set around actual responsibilities: administer the relevant tenant, access an approved document, receive a service alert, recover access through an authorised route and locate the required backup or restoration procedure. Use harmless test records wherever possible. The successor should work through their own identity, with least privilege and visible evidence of what was tested.
Agree a cutover time, responsible operators and an escalation contact. Temporary overlap during a cooperative handover needs an explicit purpose and end time. If a test fails, record the service, dependency and decision; do not silently grant global access as a workaround. In an urgent case, test the replacement route in parallel with containment rather than postponing revocation until every continuity test passes.
Revoke access across identities, applications and devices
At the authorised cutover, disable or remove the departing person’s permissions as appropriate, including external guests and delegated roles. Revoke active sessions and refresh tokens using the supported controls, review application grants and rotate exposed shared secrets or service credentials through a controlled change. Do not disable an automation identity without identifying its business owner and replacement path.
A directory change does not necessarily terminate a session created by a separate application. Check important services individually and record propagation delays or unsupported controls. Previously downloaded files, offline devices and private copies cannot be recalled merely by disabling an account. Coordinate device return, authorised data handling and any preservation requirement before erasure. Record residual exposure honestly rather than declaring universal removal from a single successful sign-out.
Close with evidence, exceptions and a named owner
The acceptance record should show scope, approval, tested successor access, completed revocations, timestamps, supporting references and remaining exceptions with owners and review dates. Preserve relevant audit records and configuration evidence under an agreed retention and access policy. Do not include passwords or unnecessary sensitive content in the report. Review whether alert recipients, recovery routes and supplier contacts still point to the departing person.
TRUST-IT can help map dependencies, coordinate the technical handover and verify the agreed controls alongside the family office’s authorised representatives and providers. A scoped engagement can produce a responsibility register, transition plan, test evidence and exception-led handover record. The first discussion needs the affected services, entities, departure date and known constraints—not credentials or private documents. Timing and effort depend on access, vendor cooperation and the transfer boundaries.
WORKED EXAMPLE
The departing adviser is also the recovery contact
Illustrative scenario, not a client case. A family office plans an orderly change of external adviser. A company domain and a document workspace have authorised successor administrators, but recovery alerts still depend on the outgoing adviser’s personal mailbox.
- Evidence and checks
- The approved register separates contractual owner, administrator and recovery contact. Provider-supported changes establish an appropriate replacement recovery route. The successor verifies the agreed administration and document tasks using their own account. The cutover record separately checks guest permissions, active sessions and shared links.
- Supported conclusion and next action
- Successful sign-in alone would not demonstrate an independent handover. Acceptance requires the agreed recovery route to work, the outgoing permissions to be addressed and any provider restriction to have an owner and follow-up date. If active misuse were suspected, containment would proceed immediately alongside continuity work.
What to request from your provider
Use these criteria to compare the proposed work and review the result. The scope and acceptance checks should be agreed before delivery.
Swipe across the table to see all columns.
| Deliverable | What it includes | Acceptance check |
|---|---|---|
| Responsibility register | Service, owner, administrator, recovery dependency and successor. | Each critical service has an authorised owner and a recorded unresolved-dependency status. |
| Transition and continuity plan | Cutover actions, dependencies, operators and escalation route. | Planned overlap expires; urgent-risk containment and continuity responsibilities are explicit. |
| Access and revocation evidence | Successor task tests, permission changes, session checks and known delays. | Evidence covers agreed services individually; a directory change is not treated as universal revocation. |
| Acceptance record | Scope, approvals, timestamps, references and exceptions with review dates. | The responsible owner can distinguish completed controls from residual exposure without receiving credentials. |
TAKE THIS INTO YOUR NEXT MEETING
Your preparation checklist
- Confirm the authorised sponsor, entities, departure scenario and cutover date.
- Map ownership, administrative access, recovery contacts and non-human dependencies.
- Agree data preservation, successor access and bank or provider transfer procedures.
- Test approved successor tasks with harmless records and a separate identity.
- Execute and verify authorised revocations; contain urgent risk without waiting for every test.
- Sign off evidence, remaining exceptions, accountable owners and review dates.
Use the bilingual workbook for notes or the editable CSV to assign owners and evidence references. These are preparation templates, not a completed assessment.
Put the guidance to work
Strengthen access controls, secure communications, and digital protection for organisations and executives.
Identity & executive security