User Roles and Access Control

Define access around these controls

User roles and permissions guide

Every business system that holds more than one type of user needs a clear model for who can see what and do what. Without it, a junior member of staff can accidentally delete customer records, a contractor can view financial data they were never meant to see, or an admin panel becomes a single point of failure because only one person knows how it works.

A user role is a named collection of permissions assigned to a group of people who perform the same type of work. Rather than setting permissions individually for each person, you define a role once — "Sales Manager", "Finance Viewer", "Support Agent" — and assign users to it. A permission is a specific right: the ability to read a record, create a new entry, approve a workflow step, or export a dataset.

The practical value of roles becomes obvious as soon as a system grows beyond a handful of users. If you have fifteen staff using a CRM and you are adjusting access for each person individually, you will make mistakes. Roles let you change access for an entire job function in one step, and they make it straightforward to answer an auditor's question: "Who in this business can approve refunds?"

When specifying a new system or reviewing an existing one, the starting point is not the technology but the organisational structure. Which job functions exist? Which data does each function need to read, and which data does it need to change? Are there workflow steps that only certain senior staff should authorise? Write these down before you discuss implementation with a supplier, because the answers directly shape the permission model.

How to plan role-based access control

Planning role-based access control (RBAC) means translating your organisational structure into a set of roles and permissions that a system can enforce. The process is straightforward in principle but requires discipline, because the temptation is to create a role for every job title rather than grouping by actual access needs.

Step one: List the data and actions in the system

Before defining roles, catalogue what the system actually contains and what users can do. A customer portal might hold client profiles, invoices, support tickets and uploaded documents. Actions might include viewing, creating, editing, deleting, exporting and approving. This list becomes the permission inventory.

Step two: Group by function, not by name

Map each job function to the permissions it genuinely requires. A "Regional Sales Director" and a "Senior Account Executive" may have different job titles but identical access needs within a particular system. If you create separate roles for each, you add complexity without benefit. Ask: "If this person changed jobs tomorrow but stayed in the same department, would their system access change?" If not, they likely share a role.

Step three: Apply the principle of least privilege

Give each role the minimum permissions needed to do its work. A support agent who needs to view customer details and log ticket notes does not need the ability to delete accounts or run bulk exports. Over-permissioning is common because it avoids short-term friction, but it accumulates risk over time.

Step four: Document exceptions separately

In practice, you will encounter individuals who need a small addition to their role's permissions. Rather than creating a new role for one person, note the exception, approve it formally, and review it periodically. If the same exception appears repeatedly, it probably belongs in the role definition.

Step five: Plan for change

Staff change departments, get promoted, or go on secondment. Your access model needs a clear process for moving someone between roles and removing their previous access at the same time. If this relies on a manual email to an administrator, it will eventually be missed.

Permission models: Role-based vs attribute-based access control

Role-based access control assigns permissions through roles. Attribute-based access control (ABAC) assigns permissions through a combination of attributes — who the user is, what they are trying to access, when and where the request happens, and the context of the action.

In a CRM using RBAC, a "Sales Manager" role might grant read and write access to all accounts in their assigned region. The rule is simple: if you hold the role, you get the access.

In an ABAC model, the same system might apply a policy such as: "A user may edit an account record if their department is Sales, their seniority level is Manager or above, the account's region matches their assigned region, and the request is made during business hours." The decision is evaluated at the point of each action, not pre-assigned through a role.

ABAC is more granular and can handle complex rules that RBAC struggles with — for example, restricting access to records containing sensitive data categories unless the user has completed specific training. However, ABAC is significantly harder to design, test, and audit. When a user is denied access, tracing the reason through a web of attribute conditions is non-trivial.

For most business systems — CRMs, portals, admin panels, document workflows — RBAC provides sufficient control and is far easier to maintain. ABAC becomes worth considering when regulatory requirements demand context-dependent rules, or when a system serves multiple organisations with widely varying policies. If a supplier suggests ABAC for a straightforward internal tool, ask what specific problem it solves that RBAC cannot.

How to audit user access in a business system

An access audit is a systematic check that every user's permissions match their current job requirements. It is not a one-time exercise; it should happen at regular intervals and whenever there is a significant change in staffing or structure.

The practical steps are:

• Export the current state. Most business systems can produce a report showing every user account, the roles assigned, and the last login date. If your system cannot do this, that is a finding in itself.
• Compare against the current org chart. Work through each active user and confirm their role is correct for their current position. Pay particular attention to people who have changed teams or been promoted in the last six months.
• Identify dormant accounts. Accounts that have not logged in for a defined period — the right length depends on your business, but three to six months is a common starting point — should be investigated and typically deactivated.
• Check for privilege creep. Look for accounts that have accumulated permissions over time through exceptions, temporary grants, or role changes that were not fully cleaned up.
• Review admin accounts. Full administrator access should be held by the smallest possible number of people, and each should have a documented business reason for it.
• Record the results. Document what was checked, what was found, what was changed, and what was left as-is with a stated reason. This record is what you produce if an auditor, a client, or a regulator asks.

If you are buying a new system, ask during selection whether it can produce user-access reports without manual effort. If you are building one, include this reporting in the requirements.

Guest and temporary access in business applications

Not everyone who needs access to a business system is a permanent employee. Clients may need to view project progress in a portal. External auditors may need read-only access to financial records for a fixed period. A consultant may need to upload documents for three weeks.

The mistake is to handle these situations by creating a full user account and forgetting about it. Guest and temporary access should be planned with the same rigour as permanent access, but with additional controls:

• Time-limited accounts. Set an explicit expiry date. When the date passes, the account should deactivate automatically or require re-approval.
• Reduced permissions. A guest almost never needs the same permissions as an internal user. Define a specific guest role or set of roles with tightly scoped access.
• Clear sponsorship. Every temporary account should have a named internal sponsor who is responsible for requesting the access and confirming when it is no longer needed.
• Visibility. You should be able to see a list of all active guest accounts in one place, separate from the main user directory.

When specifying a portal or client-facing system, discuss with your supplier how guest access will be managed. Some platforms handle this natively; others require workarounds that are easy to lose track of.

How to handle user account deactivation and data removal

When someone leaves the business, their access needs to be removed promptly and completely. This sounds obvious, but it fails regularly in practice, particularly when leavers are managed through HR processes that do not connect to IT or system administration.

Deactivation should cover every system the person had access to, not just the primary one. A common gap is forgetting about accounts in subsidiary systems, test environments, or third-party services that were set up for a specific project.

The question of what happens to the leaver's data is separate from access removal and depends on the system's purpose and your data-retention obligations:

• Transactional records — orders, support tickets, approval decisions — typically stay in the system because they are part of the business record, but the association with the individual account may be anonymised or marked as inactive.
• Personal files and drafts — uploaded documents, saved reports, incomplete work — need a policy. Are they reassigned to a manager, archived, or deleted?
• Account metadata — login history, session tokens, personal preferences — should be removed or purged as part of deactivation.

For systems subject to UK data-protection regulation, deactivation and data handling should be reviewed with appropriate specialist advice, because the rules depend on the specific data categories and your lawful basis for processing.

When agreeing a support or maintenance contract for a system, check that it includes a defined process for deactivating accounts and that you retain the ability to do this yourself without waiting for the supplier.

Segregation of duties in business systems

Segregation of duties (SoD) is the principle that no single person should control all steps in a critical process. In a financial context, the person who creates a supplier record should not be the same person who approves payments to that supplier. In a CRM, the person who raises a discount should not be the sole person who authorises it.

SoD is not primarily a technical control; it is an organisational one. But a business system can enforce it by preventing a single user account from performing conflicting actions. If the system allows a user to both create and approve the same record without any override, the technical implementation has not supported the policy.

Planning SoD in a new system means identifying which workflows carry financial, compliance, or reputational risk, and then defining which steps in those workflows must be performed by different people. Common areas include:

• Purchase approvals and payment execution
• Customer data amendments and data-export permissions
• User-account creation and role assignment
• Content publication and content approval

The practical difficulty is that small businesses sometimes lack the headcount to separate every duty. In those cases, the system should at least flag when a single user has performed both sides of a controlled process, so that the action can be reviewed. If a supplier tells you that SoD is only relevant to large organisations, ask how the system handles the conflict when a small team needs the same controls.

How to manage access for contractors and third parties

Contractors, freelancers and third-party service providers often need access to internal systems to do their work. The access model for these users should be distinct from employee access, even if the underlying system is the same.

The key differences are accountability and lifecycle. An employee's access is tied to their employment contract and managed through HR processes. A contractor's access is tied to a specific statement of work or service agreement, and it should end when that engagement ends — which may not align with any internal HR trigger.

Practical measures include:

• Separate role definitions. Do not put contractors into internal employee roles. Create contractor-specific roles that grant only the access needed for the stated work.
• Contractual terms. The contractor's agreement should specify which systems they may access, what they may do with the data, and what happens to their access on termination.
• Named individuals. Access should be granted to named people, not to a generic "contractor" or "agency" account. If a staffing supplier rotates personnel, each new person should go through the same access request process.
• Offboarding triggers. Define what event ends the access — contract end date, project completion, or a formal notice from the engaging manager — and ensure the system or process acts on it.
• Monitoring. Contractor activity in business systems should be logged and periodically reviewed, particularly if they have access to sensitive data or high-privilege functions.

When a third party provides a managed service that requires deep system access — for example, an IT support provider who needs admin rights to troubleshoot issues — consider whether a just-in-time access model is appropriate, where elevated permissions are granted for a defined window and then automatically revoked, rather than standing access that persists indefinitely.

Before engaging a supplier who will have access to your business systems, review what access they are requesting, why, and whether your existing permission model can accommodate it without creating exceptions that undermine the controls you have built for your own staff.