SaaS user deprovisioning evidence for offshore IT support

Decision and boundary. Buyers often ask a remote technical-support team to remove access after departures, role changes, vendor endings, or suspected compromise. The research question is whether a Philippines-based administrator can turn an authorized trigger into a complete and reviewable deprovisioning record across the approved application estate. The lane includes request registration, identity matching, task execution, evidence capture, and exception routing. It excludes deciding that a person should lose access, interpreting employment status, investigating suspected misconduct, preserving legal evidence, or accepting residual risk. Those decisions remain with people, security, legal, and system owners. The study evaluates execution against a frozen instruction set; it does not certify that every undiscovered account has been found or that an organization satisfies a particular security framework.

Population and unit. Freeze every authorized removal or restriction trigger received during complete operating weeks, including employees, contractors, temporary workers, service accounts, shared credentials, test identities, administrators, and third-party guests. Retain cancelled requests, mistaken identities, future-dated departures, urgent security holds, incomplete inventories, returned workers, transfers, and requests that arrived through an unapproved channel. The primary unit is one identity-role relationship across the declared system inventory, not one help-desk ticket or one application click. State the timezone, coverage hours, system inventory version, identity source, trigger authorities, deadline classes, and exclusion rules before reading outcomes. Sampling only closed tickets would hide triggers that were missed, rejected without ownership, or marked complete while residual sessions remained active.

Evidence model. For each unit, preserve a pseudonymous person or entity reference, authoritative trigger identifier, request source, authorizer, effective time, employment or contract state as supplied by its owner, expected applications, assigned groups, elevated roles, active tokens, managed devices, mailbox or file ownership, automation dependencies, actions, actor, timestamps, returned system events, exceptions, receiving owners, closure basis, and subsequent access signal. Do not reproduce secrets, private employee narratives, or full mailbox contents in the research extract. Keep the source decision separate from the administrator's work. A ticket marked resolved is an administrative claim; a directory event is stronger execution evidence; an application-specific session test answers a different question. Corrections should append history instead of silently replacing the first record.

Method. Select units from the authoritative trigger stream before outcomes are known, then stratify by worker type, departure type, notice interval, privilege, system class, location, shift, and whether an exception occurred. Trace each trigger forward through directory, application, device, token, ownership-transfer, and closure events. Draw a second backward sample from disabled accounts and sensitive-role removals to locate their source authorization. Two reviewers independently score a de-identified subset for valid authority, identity match, correct effective time, complete inventory, least-privilege execution, evidence quality, exception ownership, and accurate closure. Preserve reviewer disagreements and missing telemetry. Test the workflow only with approved synthetic identities; never terminate a real user's access merely to demonstrate the control.

Sequence analysis. Reconstruct authorization, scheduling, session protection, directory action, downstream propagation, token revocation, device step, data or mailbox transfer, application confirmation, exception escalation, and final attestation. Measure early removals separately from late removals because both can cause harm. A directory disable may precede a SaaS application's synchronization, while a local application account can survive entirely outside single sign-on. A transferred worker may need one role removed and another granted without a period of excessive access. Look for tasks closed at the bulk-job submission time, future-dated jobs that never ran, reused checklists that name retired systems, and ownership transfers made to an unverified recipient. The safe pending state needs a named owner and next review time.

Measures and interpretation. Report denominators for authorized triggers, matched identities, inventory-complete units, on-time effective actions, verified downstream removals, revoked sessions, transferred business data, owner-accepted exceptions, unexplained reopenings, and observed post-effective access. Show receipt-to-ready, ready-to-effective, and effective-to-verified distributions, separating administrator time from owner, platform, and synchronization waiting. Do not collapse all applications into an average that hides a sensitive outlier. A fast median does not excuse one privileged account left active; a slow case may reflect a lawful evidence hold or an owner-approved transition. Zero observed access is not proof that no shadow account exists. Interpret completeness, authority, timing, and residual evidence together.

Failure analysis and safeguards. Common defects include matching by display name, removing a primary directory identity while leaving personal tokens, forgetting vendor portals, transferring files after the recipient changed, disabling an account before preservation instructions arrive, and allowing the same worker to authorize and attest an exceptional retention. Review API failures, rate limits, offline devices, local administrators, forwarding rules, recovery methods, group nesting, delegated mailboxes, scheduled automations, and privileged vault access. The coordinator may execute only preauthorized changes through least-privilege tooling, record returned evidence, and route exceptions. They must not infer termination, search personal content, destroy records, choose a successor, extend access for convenience, or describe a security incident externally.

Sources and analytical boundary. CISA's Cross-Sector Cybersecurity Performance Goals describe identity and access practices, including prompt account revocation, while NIST Cybersecurity Framework 2.0 supplies governance and access-control outcomes. NIST SP 800-53 includes account-management control concepts such as disabling accounts under defined conditions. These sources support explicit authority, lifecycle management, logging, and review, but they do not prescribe one commercial staffing workflow or one universal deadline. Our unit definition, evidence fields, and sampling design are operational inferences. Applicable employment law, contracts, litigation holds, privacy obligations, sector rules, collective agreements, and incident procedures require qualified review. A support record cannot decide whether access should legally end or whether retained data may be deleted.

Limitations and decision rule. Application inventories decay, identity aliases can break linkage, and vendor logs vary in retention and meaning. A disabled login does not prove that exported data or an unmanaged device is inaccessible. Synthetic tests may not reproduce production federation, and a post-effective event may be a background process rather than human access. The study cannot estimate malicious intent or discover every unregistered service. Delegate execution only when trigger authorities, identity sources, inventory ownership, time semantics, preservation gates, permissions, backup owners, exception paths, and closure evidence are explicit. Pause expansion after unowned triggers, wrong-person actions, premature deletion, unverifiable privileged removal, or repeated inventory gaps. The reader outcome is a bounded account-administration role, not outsourced termination authority.

Worked scenario and retest. A contractor's engagement ends at 18:00 UTC, but the request lists a common name and omits a design workspace. The administrator uses the authoritative worker identifier, confirms the effective time and system inventory version, schedules the directory action, and flags the missing workspace owner before closure. At 18:00 the directory disables successfully, existing sessions are revoked, the source repository removes team membership, and the design account remains visibly open with a security owner and deadline. The ticket cannot claim complete removal until that exception is resolved or formally accepted. Retest after adding applications, changing federation, revising offboarding ownership, or observing residual access. Include transfers, cancelled departures, service-account dependencies, offline devices, and primary-owner absence in the test set.

Primary and authoritative sources. “Cross-Sector Cybersecurity Performance Goals,” Cybersecurity and Infrastructure Security Agency, cisa.gov “The NIST Cybersecurity Framework 2.0,” National Institute of Standards and Technology, nist.gov “Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5,” National Institute of Standards and Technology, csrc.nist.gov Checked October 11, 2026. Source concepts frame governance and account lifecycle; they do not validate a particular vendor, removal event, deadline, or legal decision.