Permissions and access on a project platform: who may view, edit and publish
The mechanical trade can open a cost folder it does not need, and a former coordinator's access remains unexplained. The project manager needs to check the actual permissions and authorized purposes. A printed matrix helps only when it matches the platform, its shared links and the accounts still in use.
Give each role the access needed for its actual duties, then verify the platform's applied permissions and shared links. Distinguish viewing, commenting, editing, publishing and administration where the system supports them. Canadian cyber guidance supports least privilege and removing access no longer required. The matrix is a planning record; its existence does not prove that confidential information is protected.
Connect roles with tested permissions
- Define information needs. List relevant records and the roles that must use them, including field, office, owner, consultant and trade users. Identify who may publish an authorized issue and who may administer access. Keep sensitive commercial or personal records appropriately restricted. An outside party may need shared project information beyond its own folder; use the actual authorized need rather than one blanket folder rule.
- Apply access deliberately. Use identifiable individual accounts and appropriate groups where available, avoiding shared accounts that obscure responsibility. Give elevated permissions only where the function requires them. Check inherited permissions, guest access and shared-link settings as well as the named folder role. Record who approves and applies changes, and protect administrator functions through the organization's appropriate security process.
- Test the user's real view. Use an appropriate controlled test or approved access-check method to confirm that representative users can reach the required information and cannot reach restricted records. Check files, registers and links affected by the arrangement. Record gaps and correct them through the responsible administrator. A successful test samples the arrangement; it is not proof that every later permission change will be correct.
- Review changes and remove unnecessary access. Respond promptly when duties, employment or authorized project needs change, following the organization's access process. A person leaving the main work may still need explicitly approved limited access for another purpose; confirm that need rather than leaving old broad permissions active. Review users and elevated roles at a cadence suited to the information and risks, and preserve relevant administrative records.
If unintended access is discovered, limit it through the responsible administrator and follow the organization's incident process to assess what information was exposed and what further response is required. Do not erase access evidence or assume that correcting the folder permission settles the entire issue. Keep record retention and access revocation as separate decisions.
Common mistakes
- Applying a matrix without testing inherited access and links.
- Leaving old broad rights because a former user might need one document.
- Deleting access evidence when correcting an exposed folder.
Checklist
Review one platform role
- Actual authorized information needs.
- Separate view, edit, publish and administrator rights.
- Individual accounts and applicable groups.
- Inherited access and shared links.
- Representative permission checks.
- Role changes, removal and incident records.
Check your understanding
The exposed folder is now restricted. Is the issue finished?
