Philippines staffing research · Published · Updated
Access reviews for outsourced staff: evidence and cadence
A practical protocol for reviewing outsourced staff access, recording the evidence, choosing a cadence, and closing accounts when a role ends.

Research findings
An access review is a comparison between the permissions a person needs and the permissions the systems say they have. The comparison sounds simple until the reviewer tries to find a current list. Accounts are created in one tool, roles are described in another, and the actual permissions may be inherited from a group nobody remembers creating. The reviewer needs a source that reflects the current state, not last quarter's export.
For outsourced staff the review carries an extra question: who is accountable for the access when the provider changes a person? A named client owner should approve the role, and the provider should confirm the person assigned to it. Without both names, a review can approve an account that no longer belongs to the intended worker. Write both names into the review record so the assignment can be checked later.
Start with an inventory rather than a review. List every system the role touches, the account used, the permission level, and the business reason. Include shared mailboxes, file stores, phone systems, and reporting tools that are easy to forget. An inventory that omits the shared mailbox will approve the most sensitive access by default.
Choose a cadence that matches the risk. A quarterly review is common for routine back-office access, while financial, health, or security-sensitive systems may need a monthly check. A new role should be reviewed soon after it starts, because the first weeks are when extra permissions are most often added for convenience. Record the reason for the cadence so a later reviewer does not shorten it without evidence.
The evidence should show what the reviewer saw, not only that a review happened. Keep the exported account list, the date of the export, the reviewer, the decision for each account, and the change ticket for any removal. A signed checklist with no attached list proves only that someone signed. Keep the export with the sign-off so the two cannot be separated.
Discussion
Review by role first and by person second. A role-based view makes it easier to spot outliers, because most people in the same job should have similar access. A person-based view is still needed to catch a temporary grant that was never removed. Use both and record the comparison.
Separate the reviewer from the person who requests access. If the same coordinator can request and approve a permission, the review becomes a formality. A named client owner should approve consequential access, and the provider should supply the worker identity and assignment dates. Note the differences rather than averaging them away.
Removal is part of the review. Every account marked for removal needs a ticket, an owner, and a completion date. Track the time from decision to removal and follow up on accounts that remain active after the due date. An access review that does not close removals is a report, not a control. The count belongs in the review summary, not in a separate tracker.
Implications and limits
Offboarding deserves its own checklist because it is time-sensitive. Confirm the last working day, the systems to disable, the mailbox handling, the device return, and the transfer of any files the role owns. Record who completed each step and when. A final review after thirty days can catch an account that was missed.
The limits are practical. A small business may not have a governance tool that produces a clean entitlement report, so the review may rely on manual exports. That is acceptable if the export date and source are recorded. The finding should describe the evidence that was available, not imply a completeness the tooling cannot support.
Use the review to improve the role, not only to remove access. If the same extra permission is requested every month, the role definition may be wrong. Update the role, then review the change at the next cycle. The goal is a smaller, clearer set of permissions that matches the work.
Building the access inventory
Walk through one full workday with the coordinator and list every system opened, including the ones used once a week. Capture the account name and the permission level rather than the system name alone. Note any shared account, because shared credentials make individual review impossible. Test the inventory against one real workday before the first review.
Give each entry an owner and a business reason. An entry without an owner will not be reviewed and an entry without a reason will not be removed. Keep the inventory in one approved location and date each version. Review the inventory when the role changes, not only at the scheduled cycle. Write the scope at the top of the review sheet.
Choosing a review cadence
Set the cadence by the consequence of misuse and the rate of change in the role. A stable data-entry role can use a quarterly cycle, while a role that handles payments or customer records may need a monthly check. Add an event-based review after a team change, a provider change, or an incident. Write the cadence where the role owner can see it.
Keep the review small enough to finish. A cycle that reviews every account in detail once a year may be less useful than a focused review of the highest-risk systems every month. Document which systems are in scope for each cycle and which are covered by an event trigger. An event review can be short if it names the trigger and the decision.
Closing the loop on removals
Track each removal from decision to confirmation. The record should show the ticket, the owner, the completion date, and the evidence that the account is disabled. Report the number of removals still open past the due date. That count is a direct measure of whether the review changes anything.
Run a thirty-day check after offboarding to confirm the account is still disabled and the mailbox is handled as agreed. Record the result even when it is clean. A clean check is evidence that the process works, and it is useful when a client asks how access is governed. Keep the result with the offboarding record.
Evidence for a small team
A small team can produce credible evidence without a governance platform. Use a dated export from each system and keep the file with the review sheet. Record the source, the export time, and the person who ran it. Manual evidence is acceptable when its limits are stated.
Photograph or export the permission screen for the highest-risk system if no report exists. Store the image with the review and note what it does and does not show. A screenshot of one user does not prove the whole role, so describe the scope. Do not present a partial check as a complete inventory.
Ask the provider for the worker assignment dates in writing. Compare those dates with the account creation and last-login records where available. A mismatch is a question, not a conclusion. Record the answer and the person who gave it.
Keep the review evidence for the period set by the owner and then remove it. Access evidence often contains names and account identifiers, so treat it as sensitive. Share only the summary with anyone outside the review group. The point is a defensible record, not a permanent archive.
Questions
How often should outsourced staff access be reviewed?
Base the cadence on risk and change rate. Quarterly is common for routine access, monthly for sensitive systems, plus an event-based review after a role or provider change.
What evidence should an access review keep?
The dated account export, the reviewer, the decision for each account, and the ticket for any removal. Keep the source list with the sign-off so the review can be reconstructed.
Who should approve access for an outsourced worker?
A named client owner should approve the role, and the provider should confirm the worker assigned to it. The same person should not both request and approve consequential access.
Can a spreadsheet serve as the access inventory?
Yes, if each row has an owner, a system, a permission level, and a review date, and the export is dated. A spreadsheet is weaker than a system report but still supports a review when its limits are stated.
