Plan permissions around actions and records

“Staff” and “admin” may look like enough roles at the start of a project. Then somebody needs to view orders without changing prices, approve a refund without exporting customer records, or work only with one branch.

Write those distinctions into the brief. Permissions are part of the business workflow, not just an account-settings screen.

Separate identity from permission

Authentication establishes who is using the system. Authorization determines what that identity is allowed to do. OWASP's authorization guidance distinguishes these concepts and recommends least privilege, denying access by default, and validating permissions on every request.

In practical terms, a successful sign-in is not a reason to expose every record. Hiding a button also does not replace a server-side permission check.

Ask the technical team to demonstrate how the rules are enforced. This article is a planning guide, not a security assessment of a particular application.

Define the action and its scope

List actions independently: view, create, edit, approve, cancel, export, delete, and administer access. Then specify the records to which each action applies.

The following illustrative matrix is deliberately small.

Your rules may differ. The point is to make the boundary explicit enough to test.

Consider conditions as well as job titles. An action may be permitted on a draft and prohibited after approval. A person may belong to several locations but act within only one at a time.

Avoid using a powerful role as a workaround

If someone needs one additional capability, investigate that need instead of automatically granting broad administration access. Ask what the role can do today and what future features might inherit from it.

Include service accounts and integrations in the conversation. They also need an appropriate scope and an owner. Document why each access grant exists and how it can be withdrawn.

For temporary access, agree an expiry or review process. Do not depend on someone remembering a conversation months later.

Test the cases that should be refused

Use separate test identities and representative records. Ask to see both a successful action and a denied action.

For a customer portal, include one company attempting to access another company's record. For an internal tool, include a former approver or a user whose location assignment has changed. Confirm the intended response without disclosing protected information.

Test direct requests as well as the visible interface through an appropriate technical review. A disabled control is not evidence that the underlying operation is protected.

Make access review part of operation

Define who approves new users, handles role changes, and removes access when someone leaves. Include emergency access if needed, with a controlled process and an activity record.

Ask which important actions are logged and who reviews those records. Avoid collecting more personal information than the operational purpose requires.

Carry the permission matrix and test evidence into the handover. When the business changes, update the rules and their tests together rather than allowing permissions to grow through informal exceptions.