An event team might include ten people or a hundred.
Some sell tickets. Some manage customers. Some handle payments. Some work at the entrance. Others manage the event itself. They all need access to the same system.
But they do not need access to the same things.
Giving everyone full access may seem convenient at first. In practice, it creates unnecessary risk, makes mistakes harder to trace and can expose customer information to people who do not need it.
The smarter approach is to design access around what each person actually needs to do. Employee roles are not about restricting your team. They are about giving each person the right level of control.
Build Roles Around What People Actually Do
Job titles are a poor starting point for designing permissions. “Event Manager” does not tell you exactly what that person should be able to access.
A better question is: What actions does this person need to perform?
A customer-service employee may need to find orders, help with ticket transfers and update customer information. A finance employee may need to process refunds and view payment information. An entrance supervisor may need to validate tickets and monitor attendance. An event manager may need to manage ticket categories, capacity and event settings. These are different responsibilities, even if everyone works on the same event.
Start with the work. Then build the role around it.
Give Employees Only the Access They Need
This is the principle of least privilege: a user should have only the access necessary to perform their role.
The NCSC recommends applying least privilege to limit the data and functionality available to different users.
Consider an entrance employee. They may need to know whether a ticket is valid and whether it has already been used. They probably do not need to change ticket prices, issue refunds or export the customer database. Giving them those permissions does not improve their ability to check tickets. It simply creates additional ways for something to go wrong.
The same logic applies everywhere. Access should follow responsibility, not seniority.
Separate Normal Work From High-Risk Actions
Not all permissions are equally important.
Viewing an order is one thing. Changing an order is another. Issuing a large refund is more consequential. Changing an event's capacity or ticket price can affect hundreds or thousands of customers. Exporting a customer database can expose a large amount of personal information. These actions deserve more careful control.
For particularly sensitive functions, consider limiting access to specific roles and, where appropriate, requiring additional approval or stronger authentication.
The NCSC specifically recommends stronger controls for privileged users and notes that full system-wide administrator access should be the exception rather than the norm.
The more damage an action could cause, the fewer people should be able to perform it.
Use Individual Accounts
One account called “Event Team” may seem convenient. It is also a problem.
If five employees use the same login and a ticket is deleted, a refund is issued or a setting is changed, you may not know who performed the action.
Individual accounts create accountability. They also make it possible to remove one person's access without disrupting everyone else.
The NCSC recommends assigning accounts to individual users and avoiding shared or generic accounts where possible because individual identities improve logging and accountability.
This becomes particularly important when employees have elevated permissions. If everyone shares an account, the system knows what happened but may not know who did it.
Keep the Number of Roles Manageable
There is another mistake at the opposite extreme.
An organisation can create so many roles that nobody understands what each one means.
You do not need a different role for every employee. Instead, group people according to genuinely different responsibilities.
For example, an event organisation might have roles such as: Event Operations. Customer Support. Finance. Entrance Team. Marketing. Administrator. The exact structure will depend on the organisation.
The important thing is that each role should have a clear purpose and a clearly defined set of permissions.
Role-based access control is specifically designed around this idea: access is assigned according to the user's role rather than being manually configured from scratch for every individual.
A good role structure should be simple enough that a manager can explain it without opening the software.
Be Careful With Administrator Access
“Make them an admin” is often the fastest solution to a permissions problem. It is rarely the smartest.
Administrator access can allow someone to change settings, manage users, access sensitive data or alter critical parts of the system. Most employees do not need all of those abilities. Even managers may need only a subset.
The NCSC recommends minimising the number of privileged users and removing administrative access when a person's responsibilities change.
A useful test is: What specifically requires this person to be an administrator? If there is no clear answer, they probably need a narrower role.
Treat Customer Data as a Separate Concern
Ticketing systems can contain much more than names and email addresses.
Depending on the event and system, employees may be able to see purchase history, contact information, attendance records and other customer information.
That does not mean everyone should see everything.
A scanner operator might need only enough information to validate entry. A customer-service employee may need access to order details. A marketing employee may work with audience segments rather than individual customer records. This is not just good security practice.
For organisations subject to UK data-protection requirements, the ICO recommends assessing the requirements of each role and creating role-based access profiles, while restricting sensitive information to roles that genuinely require it.
The question should not be “Can this employee access the database?” but “What part of the database does this employee actually need?”
Review Access When People Move
One of the easiest ways to create excessive access is to change someone's job without changing their permissions.
An employee starts in customer support. Later, they move into event operations. Then they help finance for a few weeks. Each time, another permission is added. Nothing is removed. Eventually, the employee has accumulated access to far more systems than their current role requires. This is permission creep.The solution is straightforward: review access whenever responsibilities change.
The ICO specifically recommends reviewing access rights regularly and adjusting them when staff change roles or responsibilities. An employee's permissions should reflect their current job, not every job they have ever performed.
Keep a Record of Important Actions
Permissions tell you what someone could do. Audit records tell you what they did. That distinction becomes valuable when something unexpected happens.
Suppose a ticket price changes unexpectedly. A large refund appears. An employee's permissions are altered. A customer record is deleted. If important actions are logged against individual accounts, the organisation has a much better starting point for investigating the problem.
Logging is especially valuable for privileged actions, where the consequences of misuse can be greater. The NCSC recommends logging and monitoring privileged access to support detection and response.
The purpose is not to watch employees constantly. It is to make important changes traceable. Good access control limits what people can do. Good logging shows what actually happened.
Frequently Asked Questions
Q: How many employee roles should an event organisation have?
A: There is no ideal number. Create separate roles where responsibilities and required permissions are genuinely different, but avoid creating dozens of nearly identical roles. The structure should remain understandable and easy to review.
Q: Should managers have access to everything?
A: Not automatically. A manager may require broader access than a frontline employee, but permissions should still be based on actual responsibilities. Seniority alone does not create a need for unrestricted system access.
Q: Is it safe for employees to share an account?
A: Individual accounts are generally preferable because they provide clearer accountability, simplify access removal and make audit records more useful. The NCSC recommends individual accounts rather than shared or generic accounts where possible.
Q: How often should permissions be reviewed?
A: Review them whenever an employee changes responsibilities and periodically as part of normal access management. Temporary and privileged access deserve particular attention.
Q: Should temporary staff receive administrator access?
A: Only if their duties genuinely require it. In most cases, temporary staff should receive the specific permissions necessary for their work rather than broad administrative access.
If you need additional advice or support, the TicketCRM team is always ready to help with your questions!