A software proposal may list administrators, supervisors, and users without explaining what those people can actually do. That leaves expensive decisions until the demonstration: can a supervisor reopen a completed order, can a temporary employee download customer records, and who may change another person's access?
Before approving a build, turn those questions into a short operational agreement. The following workshop is a starting point for a business commissioning a portal or internal tool, not a security certification or a substitute for a technical assessment.
Describe the work before naming the roles
Bring a person who performs the work and someone accountable for its outcome. Choose one process, such as handling a maintenance request, and describe its steps from arrival to completion. Write the actions as verbs: create, assign, edit, approve, close, reopen, export.
In a hypothetical maintenance business, a technician might record work on assigned jobs while a coordinator assigns appointments. A manager might approve exceptions. Those descriptions are more useful than three account labels whose meaning changes between screens.
Give each action an owner. If nobody can explain why a permission is needed, leave it unresolved for discussion rather than silently including it.
Define the boundaries around each action
For each action, ask which records it covers and under what circumstances. “Can edit a job” is incomplete. “Can edit technical notes on an assigned, open job” is a decision the team can demonstrate.
Consider these business questions:
- Does the permission apply to one location or every location?
- Can someone see a customer's other requests?
- Which information remains editable after approval?
- Does an export contain more data than the screen?
- Who handles an exception while the usual approver is absent?
Avoid solving every exception by making someone an administrator. Record the actual exception, its duration, and who accepts responsibility for it.
Ask how the rules are enforced
Signing in establishes identity; it does not by itself grant access to every operation. OWASP recommends limiting access to what is needed, denying unspecified access, and checking permissions on the server for each request. Hiding a button alone is insufficient. Its authorization guidance also explains why access can depend on the specific record, not just a role name.
Ask the supplier to explain the boundary in plain language. You do not need to choose the authorization library yourself, but you should understand what protects an attachment, an export, and a record belonging to another team.
Make the demonstration include refusals
An acceptance meeting should show more than the administrator completing every task. Prepare fictional records and named test accounts in an authorized test environment. Do not use a real customer's information to make the demonstration look realistic.
For the maintenance example, request three demonstrations: a technician updates an assigned job, the same account is refused access to an unassigned job, and a closed job follows the agreed reopening process. Include a download because documents may have a different delivery path from the main screen.
Write the expected outcome beside each scenario before the meeting. Otherwise, the team may accept whatever the current implementation happens to do.
Plan for people changing responsibilities
Decide who approves a new account, who handles transfers, and who removes access when an assignment ends. Include the supplier's support accounts and any automated connection to another system.
A useful handover record names the business owner, the account owner, the access granted, and the review trigger. The trigger might be a location transfer, a contract ending, or a change to the workflow. It need not be a complicated recurring committee meeting.
Ask what happens to open assignments when someone leaves. Removing access should not leave urgent work without a responsible person.
Agree on evidence and recovery
Choose which operational changes need a history: assignment changes, approval decisions, permission changes, or reopening completed work. Ask who can review that history and how the business will request an investigation. Do not put passwords or unnecessary customer details into a log.
Also agree on how a mistaken change is corrected. Restoring access, correcting a job, and restoring a backup are different operations with different consequences.
Before signing off, keep one document containing the actions, boundaries, exception owners, and demonstration results. Our custom software service can use that agreement to scope an internal system. If a proposal currently says only “three user roles,” bring it to a discovery conversation and turn those labels into decisions you can verify.