List the accounts before judging them
A recertification checklist starts with a complete list of accounts, not a sample. Include the named user accounts, the shared mailboxes, the client portals, and the tools that hold client data. Add the accounts that were created for a temporary project and never closed. The list is the foundation for every later decision.
For each account, record the person, the client, the systems, the permission level, and the date access began. Add the business reason in one sentence. An account without a reason is a candidate for removal, even if someone still uses it. The reason should describe the work, not the person's seniority.
Check for accounts that are not tied to a named person. A shared login may be convenient, but it removes accountability and makes removal harder. Replace shared credentials with named accounts where the system allows it. Where it does not, record the owner and the compensating control.
Test the permission level
Compare the permission with the work the person actually performs. A reviewer who only reads a report does not need export or delete rights. An assistant who drafts replies may not need permission to send from the client domain. Record the evidence for the current level rather than assuming the original grant is still right.
Look for administrative, billing, and recovery rights first. Those permissions can change the system, the payment path, or the account owner. Keep them with a limited group and name each holder. A broad administrator role granted for one task often survives long after the task ends.
Check the client's own requirements before removing access. A contract or a security review may require a specific role or a minimum permission. Where the requirement is unclear, ask the client owner in writing. Record the answer with the checklist so the next reviewer does not repeat the question.
Verify the person and the device
Confirm that the person still supports the client and still works for the provider. Check the start date, the current role, and the end date if one is known. An account for a person who has moved to another client should not remain. The review should catch that change before the next invoice or handoff.
Verify that multi-factor authentication is enabled and tied to the person. A factor that points to a former phone or a shared inbox is not a control. Record the method and the date it was last tested. If a factor cannot be verified, treat the account as needing repair rather than assuming it is fine.
Check the device and the network expectations in the role brief. A personal device that is not managed may be acceptable for low-risk work but not for sensitive data. Record the exception and the compensating step. The review should not pretend that every account has the same risk.
Review the shared links and exports
Shared links are access grants even when they are not user accounts. List the folders, documents, dashboards, and calendar links that the client has shared. Check who can open them, whether they are public, and when they expire. A link sent for one meeting can remain open for years.
Remove links that no longer have a purpose and shorten the duration of links that must stay. Prefer a named account or a controlled folder over a public link. Record the owner of each link and the date it was last reviewed. A link without an owner is a quiet exposure.
Check the exports that leave the system. A downloaded spreadsheet on a laptop is a copy outside the access control. Ask whether the export is still needed and where it is stored. Delete the copies that are no longer required and record the deletion. The checklist should cover data at rest as well as data in the tool.
Make the decision and record it
Each account should end the review with one decision: keep, reduce, remove, or repair. Write the decision and the owner who approved it. A keep decision should name the next review date. A reduce decision should say which permission changes. A remove decision should say when the account will be closed.
Do not let the review end with a note to check later. A later check without a date is a deferred decision. If the evidence is missing, mark the account as repair and set a date for the evidence. The account stays visible until the decision is complete.
Send the decisions to the client owner and the provider manager. Ask the client to confirm the changes that affect their systems. Keep the confirmation with the checklist. A review that is not acknowledged by the client is only half complete.
Close the loop on removals
A removal is complete only when the account is disabled and the access is gone. Track the request, the completion, and the verification. Ask the system owner to confirm the change rather than relying on the request ticket. A ticket marked done is not the same as a tested removal.
Check the shared links and the exported files after the account is removed. An account can be disabled while a link or a local copy still provides access. Update the client contact and the recovery method as part of the same step. Removal that breaks a recovery path creates a new problem.
Schedule the next review before the current one closes. A fixed cadence, such as quarterly for sensitive clients and twice a year for others, keeps the checklist from becoming a one-time project. Put the date on the same calendar as the role review. The two reviews should inform each other.
Sources
Open the original publisher and confirm the current version, definition, and scope before using a source for a business decision.
Turn the reading into a role brief
Bring the recurring tasks, tools, schedule, access limits, and owner-only decisions. Start with one work sample and one clear review path.
Plan a Philippines-based role