In this guide
List tasks before permissionsBuild a practical matrixApply supported least privilegeReview when roles changeA small team can document which roles need which records and actions. This helps separate routine support, payment reconciliation and authorised account operations. Use the capabilities of the actual tools in use; do not assume a provider offers granular staff permissions if it has not confirmed them.
List tasks before permissions
Identify who answers questions, reconciles payments, approves purchases and performs account actions. One person can hold several roles, but write them separately. A colleague who needs an order’s confirmed payment state may not need its original financial image. A writer maintaining public help does not need live customer credentials.
Build a practical matrix
The example below is a suggested internal design, not Dream’s staffing or platform model.
| Task | Typical information need | Separate authority |
|---|---|---|
| Answer account question | Order, observation and state | No automatic purchase approval |
| Reconcile payment | Relevant transaction evidence | Defined financial review role |
| Approve recharge | Target, quantity, total and scope | Named approver |
| Maintain help article | Documented non-secret facts | Editorial review |
Apply supported least privilege
OWASP’s access guidance describes granting the minimum permissions needed for a job. Where the tool supports named users and roles, use them according to its documentation. If it only provides one shared interface, do not claim you have separation merely because a spreadsheet lists roles. Review the practical risk and ask the provider what supported options exist.
Review when roles change
Update the matrix after a staff change, new tool or changed responsibility. Remove access no longer needed through the relevant system controls, while preserving legitimate case continuity. Keep approval and record access distinct so the ability to read a receipt is not treated as authority to make an account change.
Questions about this guide
Does writing a matrix enforce permissions automatically?
No. It documents the intended model. The actual tools and their controls must implement the relevant access, and the team should review what is truly available. A written role name alone does not prevent access or establish technical separation.