Skip to content
WorkStudio Help Home
Knowledge Hub

Access Control: Roles and Least Privilege

A simple explanation of access control and how teams can avoid over-sharing inside collaborative platforms.

Open Knowledge Hub ↗

Secure workspace showing role-based access, protected files, and subtle lock symbols.

Information only — not legal advice.

Access control decides who may see, create, change, approve, export, delete or administer information. Least privilege means granting the access needed for a person’s current responsibility and removing it when that responsibility ends.

A role such as “Reviewer” is a useful label, but the permissions behind it determine the risk. Two products can use the same role name for very different powers. Review the actual actions and information scope before assigning it.

Build a small permission matrix

For each role, specify the information area and allowed actions. Keep business authority separate from technical capability: being able to click an approval button does not establish that a person is authorized to approve a contract.

  • Contributor: prepares or edits assigned material, without automatically approving it.
  • Reviewer: reads the relevant issue and records findings; editing the source is a separate decision.
  • Approver: can authorize a defined use within their delegated authority.
  • Administrator: manages the service or access configuration. Administrative power does not make them the business owner of every record.

These are illustrative roles, not a description of any platform’s built-in permission set. Include export, sharing, invitation and deletion rights in the matrix; teams often check editing while overlooking those actions.

Follow access through a person’s work

Joining: identify the person, their sponsor, the required scope and any end date. Use a named account and the organization’s authentication requirements.

Changing roles: compare the old and new responsibilities. Adding a new group without removing an old one gradually accumulates access. Recheck links, inherited memberships and privileged accounts.

Leaving: disable or remove access at the agreed time, transfer record ownership, address active sessions and service credentials where applicable, and verify that scheduled work still has an owner. A former employee’s personal inbox should not be the only recovery route for a business service.

Worked example: an external reviewer

Fictional example: a specialist checks one mechanical package for two weeks. Give access to that package and the relevant issue register, rather than the entire client workspace. Record the sponsor, scope and review end date. If the specialist later needs another discipline’s model, the sponsor evaluates that additional need explicitly.

At completion, retain the review evidence under the project’s retention rules and remove unnecessary access. Document who checked the result. Avoid transferring the account to the next specialist; use a new named identity.

Verify what the rules actually do

Using authorized test accounts, test an allowed action and a denied action for each important role. For example, can a reviewer open the issued drawing, and are unrelated commercial records unavailable? Confirm both the visible interface and the effective access behavior through the service’s supported testing process.

Schedule access reviews according to risk and also trigger them when roles, contracts or projects change. Reviewers need an understandable list of people, access scope and business reason; a long list of unexplained group names is difficult to certify responsibly.

NIST SP 800-53 includes access-control and account-management controls. For day-to-day practice, see secure sharing, MFA and WorkStudio Context.

Important information

This article provides general information and does not constitute legal advice or replace a qualified professional's assessment of your circumstances. Laws, official guidance, standards and product features can change. Check current primary sources and the requirements applicable to your jurisdiction, contract and project before making decisions. Examples illustrate the discussion; they are not official rulings or instructions for a particular case. For legal decisions, consult a qualified lawyer; for technical or other specialist matters, consult the responsible professional.

Enable JavaScript to use reading progress and usefulness ratings.