Remove a Team Member’s RiskSensai Access Without Claiming Data Erasure

Separate access removal from record deletion

Offboarding is easier to manage when each action has a clear purpose. Removing a person from an organization in RiskSensai changes that organization membership. It is not the same as deleting the person’s authentication account or erasing every record they helped create.

The distinction matters because a departing member may have created evidence, owned remediation tasks or contributed to a saved assessment. Those organization records can remain relevant after their access ends. Treating removal as automatic erasure would give colleagues a misleading picture of what happened.¹

Begin with the organization and access decision. Then consider ownership, separate grants and retained copies as distinct follow-up questions.

Review the correct membership

Open the Team workspace in the intended organization using your existing authorized role. Identify the member carefully. A person who belongs to two organizations has two separate membership contexts; removal from one does not automatically remove the other.

Check the account description and organization before acting. If the interface does not establish enough information to identify the member confidently, stop and ask the organization owner to resolve the ambiguity. Do not remove the closest-looking name simply to complete an offboarding checklist.

Owner and administrator boundaries still apply. The route does not grant authority to someone who lacks it. Do not share credentials or use a person’s signed-in session to make a membership change you cannot legitimately perform yourself.

Resolve ongoing ownership first

Before removing access, identify work that still needs an accountable person. Use the relevant workspaces to inspect the records you are authorized to see; do not assume the Team page lists every operational responsibility.

These are human handoff questions, not a promise of automatic reassignment. Where a supported reassignment action exists, use it deliberately. Where it does not, record the new accountable person through the organization’s approved process.

Make the membership decision explicitly

Once the organization and member are confirmed, use the existing removal action and review any confirmation shown. Follow the interface’s legitimate restrictions, including safeguards affecting roles or continued administration.

Do not infer that every role can remove every other role. If the action is unavailable or denied, resolve the role and continuity requirement with an authorized administrator. An access safeguard is not a problem to bypass.

Submit the permitted action once and wait for its response. Inspect the saved membership list or state before treating the change as complete. If the result is uncertain, preserve the error and determine what was saved before taking another action.

Check the access boundary

The intended boundary is that the removed membership no longer authorizes organization access, including when the person had an existing application session. A browser session is not supposed to preserve tenant permission after the underlying membership ends.

Use a proportionate, authorized verification process. For a controlled test, a separate synthetic account can confirm that the former organization access is denied. For an actual member, coordinate any verification through the legitimate offboarding process rather than requesting their credentials.

Do not probe unrelated organizations or records as a shortcut. The conclusion you need is about the removed membership, not a claim that the person has no access anywhere in the platform.

What removal does not do

This table prevents a common mistake: announcing “the user and all data are deleted” after a membership action. Say what actually changed and what remains to be handled.

Worked example: a control owner leaves

Suppose a control owner is leaving the company after contributing evidence to an access-review finding. Before removal, the administrator identifies a new owner for the open work and confirms who can explain the evidence’s period and limitations.

The administrator then removes the membership and verifies the saved state. A useful handoff note might say:

Organization membership removed. Open remediation ownership has been handed to the designated colleague. Historical evidence remains in the organization. Separate review grants and any previously downloaded copies require their own handling decisions.

The note is operationally useful because it distinguishes access, continuity and retained information. It does not invent a platform-wide account deletion or promise that every local copy has vanished.

Handle retained information under the actual policy

The platform privacy policy explains the published data-handling position, while your organization’s rules determine how its records should be managed in the particular situation.² Do not choose a retention or deletion action simply because it sounds like a complete offboarding outcome.

FTC guidance provides general context for limiting sensitive-data access to people who need it and addressing access when staff depart.³ It does not supply a single retention period or legal answer for every organization. Where duties, holds or privacy requests matter, use the appropriate qualified process.

Review separate sharing paths as needed. Revoking a grant can end future link access, but it still cannot recall information already downloaded. Keep that follow-up explicit rather than implying membership removal accomplished it.

Finish with a bounded confirmation

Document the organization, the member reviewed, the action taken and the observed saved result. Keep credentials and unnecessary personal information out of the record. Note any unresolved ownership or sharing question and who will address it.

Offboarding is complete for this workflow when the intended membership is removed and the organization understands the consequences. Broader account deletion, retention decisions and recipient-copy handling remain separate tasks with their own authority and evidence.

Sources and references

1. RiskSensai. RiskSensai Security. Describes current evidence and access-control limits. ↩

2. RiskSensai. RiskSensai Privacy Policy. Provides the published data-handling policy. ↩

3. Federal Trade Commission. Protecting Personal Information: A Guide for Business (2016-10). Supports limiting sensitive-data access and retention. ↩