Work Across RiskSensai Organizations and Roles Safely

One account can have several distinct contexts

Signing in identifies your account. It does not settle which organization you are working for or which actions you may take there. A person can belong to several organizations, hold different responsibilities in each and still have a separate owner-private document area.

RiskSensai preserves organization and role boundaries in its workflows. The public security information describes the intended use of scoped access controls, while the application makes the active organization part of protected work.¹

For daily use, the important habit is simple: confirm the context before a substantive action. A familiar dashboard or an old browser tab can make the wrong organization feel correct if you do not check it.

Choose the organization explicitly at entry

The assessment entry asks you to choose the organization before continuing. Read the displayed selection and use the explicit Continue action only when it is correct. This makes the destination clear before you begin answering or linking saved work.

If the intended organization is absent, resolve membership with the authorized owner. Do not choose a different company merely to get past the entry step. Answers about one organization should not become another organization’s saved assessment.²

Use the same principle for review preparation, evidence and handoff work. Confirm the authorized context through the existing interface rather than inventing an organization identifier or assuming a URL grants permission.

Keep four concepts separate

An account category such as business or consultant is not a universal writing grant. Organization responsibilities and trust permissions can further constrain the workflow. A read-only reviewer can be permitted to inspect records without being permitted to change them.

A relationship with a firm or parent organization also should not be treated as automatic access to every client tenant. Each protected scope needs its own legitimate authorization.

Expect role differences across workflows

Read-only access does not become writing access because the same page displays an Add or Create control for another person. If an action is unavailable, confirm whether that is the intended role boundary before reporting a defect.

Similarly, permission to write one kind of record is not permission to perform every administrative action. Team membership changes, engagement work and evidence operations have their own relevant checks. Do not generalize one successful action into “I can do everything in this organization.”

If the interface returns a denial, preserve it and resolve the legitimate permission question. Do not ask a colleague to share credentials or use a different route to evade the boundary.

Recheck forms after switching context

Suppose you open an assessment form for Company A, then switch the active organization to Company B in another tab. The original form is now a potential stale-context problem. Before submitting, re-establish which organization the workflow expects.

Use the supported entry or refresh path and confirm the current destination. An error about changed context is a useful safeguard; it should not be treated as a reason to force the submission.

This matters especially for recovery and review briefs. A saved result or resumed session belongs to its authorized owner and organization. A new active selection does not make an old record transferable by default.

Worked example: a consultant with two clients

Imagine an authorized consultant supports two client organizations. The consultant prepares a risk question for Client A, then opens Client B’s dashboard to inspect an unrelated finding.

A safe working sequence is:

1. Confirm Client A before preparing or saving its work.
2. Keep the working notes clearly associated with that client.
3. Switch through the supported organization controls.
4. Confirm Client B before opening its finding.
5. Reopen Client A’s work through its authorized context when returning.

Do not copy Client A’s records into Client B merely because they illustrate a similar issue. Minimize and generalize examples where appropriate, and obtain any necessary permission for actual disclosure. The privacy policy remains relevant to handling and sharing information.³

Personal files remain a separate boundary

The personal Vault is owner-private. Another member of your organization, including an authorized reviewer, does not automatically receive access to your personal documents. This is distinct from organization evidence that is managed through its own workflow.

If a file needs to support organization work, decide whether an appropriate organization evidence record is required. Do not tell colleagues that membership should let them find it in your private document area, and do not share your session to solve the problem.

Separate recipient or advisor grants are another access path. Their scope, expiry and revocation need their own review. Removing membership does not automatically prove every independently issued sharing link was revoked.

Understand what membership removal changes

When an authorized administrator removes a membership, that membership should no longer authorize organization access, even if the person previously signed in. The authentication account itself can still exist, and memberships elsewhere can remain valid.

Historical organization records are not automatically erased by removing the person. Evidence, assessments and activity context can remain relevant. Account deletion, retention decisions and downloaded copies are separate questions.

Do not test those boundaries by browsing a real unrelated tenant. Use approved synthetic accounts or the organization’s legitimate access-review process when verification is required. A security check needs authority as well as a useful hypothesis.

A short pre-action habit

Before writing, sharing or linking work, ask:

• Am I signed in as the intended person?
• Is the organization the one this work concerns?
• Does my current role permit this action?
• Has the context changed since the form opened?
• Does the action disclose or alter information outside the intended scope?

The workflow is safe when these answers are clear and the saved outcome can be confirmed. Multi-organization access is a useful responsibility, not permission to merge contexts. Keeping identity, membership, role and record ownership distinct prevents a small navigation mistake from becoming an unintended disclosure or write.

Sources and references

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

2. RiskSensai. Free Digital Trust Assessment. Explains self-reported scope and authenticated assessment entry. ↩

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