Creating an Access Control Concept: Roles, Permissions, and Approval Workflow

Why you need an access control concept

At a company with 80 employees, the CEO made an unpleasant discovery one day: a working student from the marketing department had full access to the financial accounting system in the ERP. Not because someone had deliberately set it up that way, but because when his account was created, the profile of a colleague who happened to also work in accounting was simply copied. The student had never used the permissions, but they were there — for three years.

Situations like these are not isolated incidents. They are the default state in organizations that lack an access control concept. Permissions are granted because someone requests them. They are copied because it is faster than assembling them from scratch. And they are virtually never revoked because no one feels responsible.

An access control concept solves this problem systematically. It defines who may access which systems, applications, and data, on what basis the decision is made, and who approves it. It is not a technical document for the IT department but an organizational governance instrument that clarifies responsibilities and creates traceability.

Regulatory requirements

In case you are wondering whether an access control concept is truly necessary: the answer depends not only on good practice but also on concrete regulatory requirements.

ISO 27001 requires systematic access control in Annex A.5.15 through A.5.18. Access to information and information processing facilities must be restricted, formalized, and regularly reviewed.

NIS2 explicitly requires personnel security and access control in Article 21 as one of the ten minimum measures. This includes an access concept based on the least privilege principle.

DSGVO (GDPR) Article 32 requires that technical and organizational measures ensure the confidentiality of personal data. Uncontrolled access to personnel or customer data is a clear violation.

BSI IT-Grundschutz dedicates an entire module to the topic (ORP.4 Identity and Access Management) with detailed requirements for granting, documenting, and reviewing access rights.

In short: regardless of which framework you use, there is no way around an access control concept.

The least privilege principle as foundation

Before you start defining roles and assigning permissions, you need a clear guiding principle. The least privilege principle (also known as the principle of minimal privilege) is this foundation, and it can be summarized in one sentence: every employee receives exactly the permissions they need for their current tasks. No more, no less.

This sounds obvious but is surprisingly rarely implemented consistently in practice. The reasons are understandable: when an employee requests a new permission, the fastest path is to simply grant it. No one wants the effort of checking whether it is truly needed. And when the employee completes the task, no one thinks about revoking the permission.

The result is a phenomenon known in the literature as privilege creep: over time, employees accumulate more and more permissions without old ones being removed. After a few years, a long-tenured employee who has moved through various departments has access to practically everything.

Why least privilege matters so much

The benefits of least privilege go well beyond compliance:

Damage limitation in case of compromise. If an account is hacked, the attacker can only access what the account is authorized for. With an account that has minimal permissions, the damage is limited. With an account that has full access to all systems, the damage is potentially catastrophic.

Reduced insider risk. Not every threat comes from outside. Employees who have access to data they do not need represent an unnecessary risk. This does not have to be malicious — an accidental deletion or a careless forwarding is enough.

Traceability. When everyone only has the permissions belonging to their role, it is much faster to narrow down who could have done what during an incident.

Simplified administration. Paradoxically, a strict least privilege model is easier to manage in the long run than a system that has grown without rules. With clearly defined roles, you do not need to assemble each permission individually for a new employee — you simply assign the appropriate role.

Building role-based access control (RBAC)

The practical implementation of least privilege uses a role-based access control model, or RBAC (Role-Based Access Control). The principle: permissions are not assigned to individual people but to roles. Employees receive roles, and through the role they automatically receive the associated permissions.

Deriving roles from functions

The first step is identifying the roles in your organization. Roles are not derived from the org chart but from the actual functions and tasks employees perform.

Take as an example a mid-market company with 100 employees. There might be the following functional areas: executive management, sales, procurement, accounting, human resources, production, quality assurance, IT administration, marketing, and support. That already gives ten base roles.

But one role is often not enough. Within sales, there may be inside sales — who create quotes and enter orders — and field sales — who can only view customer data but not change prices. Those are two different roles, even though both work in sales.

A proven approach is to work with two levels of roles.

Base roles represent the basic permissions every employee in a department needs. Access to the intranet, email, shared departmental drives, and relevant standard applications.

Functional roles add specific permissions for certain tasks. The sales employee with price-change authorization, the accountant with access to payment processing, the team lead with visibility into their employees' time tracking.

Documenting roles

Every role needs clean documentation. Without it, in six months you will not remember why a role contains certain permissions — and the auditor will ask exactly that. With ISMS Lite, you can find the relevant controls for access management and identity management and use AI to generate a documented access control policy — with versioning and approval workflow included.

A role documentation should contain at least the following information:

The role matrix

A central document in every access control concept is the role matrix. It shows at a glance which role may access which system with which permission level.

R = Read, RW = Read/Write, Admin = Full access, - = No access

This matrix is the heart of your access control concept. It makes visible at a glance where access exists and where it does not. And it immediately reveals when something is wrong: why does accounting have write access to production control? That cannot be an intended state.

Avoiding typical mistakes in role modeling

Too many roles. If you create a separate role for every employee, you do not have RBAC — you have individual permission assignment with extra steps. The target is 15 to 30 roles for a company with 100 employees, not 100.

Too few roles. A single "Employee" role with access to everything is not an access control concept. Roles must be granular enough to actually represent different permission profiles.

Naming roles after people. "Max-Mueller-Role" is not a role but a workaround. Roles describe functions, not individuals.

No separation of duties (Segregation of Duties). Certain combinations of permissions are critical. The employee who creates invoices should not also be able to approve payments. The role matrix must make such conflicts visible and prevent them.

Defining permission profiles

Permission profiles are the link between the abstract role definition and the technical implementation in each system. While the role describes what an employee is functionally allowed to do, the permission profile defines how this is implemented in each individual system.

From profile to technical implementation

Let us take the role "Accounting-Clerk" as an example. This role needs access to three systems: the ERP, the DMS, and the banking software.

ERP system (SAP Business One):

• Financial Accounting module: create postings, view accounts, run dunning
• Controlling module: read-only access to cost center reports
• Procurement module: no access
• Sales module: no access

Document management system:

• "Accounting" folder: read and write
• "Contracts" folder: read only
• "Personnel" folder: no access
• "General" folder: read

Banking software:

• View account balances: yes
• Prepare transfers: yes
• Approve transfers: no (department management only)

This level of detail is necessary because the IT department needs to know exactly which permissions to configure in which system during technical implementation. A specification like "access to the ERP" is too vague — it inevitably leads to excessive permissions being granted.

Treating privileged accounts separately

Administrator accounts deserve special attention. An IT administrator with domain admin privileges can, in the worst case, compromise the entire network. Privileged Access Management addresses exactly this risk. Stricter rules apply to privileged accounts:

Separate accounts. Every administrator has a normal user account for daily work (email, intranet, document storage) and a separate admin account for administrative tasks. Admin accounts are only used when administrative tasks are pending.

Four-eyes principle for critical actions. Changes to firewall configuration, creating new admin accounts, or modifying security policies should be confirmed by a second person.

Logging. All activities of privileged accounts are comprehensively logged. Ideally, logs are sent to a central system to which the administrators themselves have no write access.

Time-limited permissions. For certain administrative tasks (such as server maintenance), temporary permissions are granted that automatically expire after a defined time window.

The approval workflow

One of the most important questions in an access control concept is: who may grant permissions? If the answer is "anyone who sends an email to IT," you have a problem. A defined approval workflow ensures that permissions are granted deliberately and traceably.

Roles in the approval process

Requester. The employee themselves or their supervisor submits the request for a permission. The request must contain at minimum: which system, which permission, and why.

Business approver. The business owner responsible for the relevant system or data approves or rejects the request. This is not the IT department but the business department. Who better than the head of accounting can assess whether an employee needs access to financial data?

IT implementer. After business approval, the IT department implements the permission technically. IT checks whether the requested permission is technically feasible and whether it is consistent with the defined roles.

Information Security Officer (for critical systems). For access to particularly sensitive systems or data, additional approval by the ISO may be required. This applies to admin rights, access to personnel data, or access to production control systems.

The workflow in detail

A clean approval workflow follows these steps:

Step 1: Request submission. The requester fills out a standardized form. It contains: which system, which permission, starting when, limited or unlimited duration, and justification. The justification is important. "I need it for my work" is not sufficient. "I am now handling accounts receivable and need access to the ERP Financial Accounting module for this" is an acceptable justification.

Step 2: Business approval. The designated business approver reviews the request. Does the employee really need this permission? Is there an existing role that fits? Or is an individual permission necessary? The approver confirms or rejects. If rejected, the requester receives an explanation.

Step 3: Conflict check. Before implementation, a check is made whether the new permission creates conflicts. Does the combination with existing permissions create critical permission combinations? Does the new permission violate the principle of separation of duties?

Step 4: Technical implementation. IT implements the permission in the system and documents the change.

Step 5: Confirmation. The requester and the approver are informed about the implementation. The requester confirms that the permission works.

Who approves what?

For the approval workflow to function, it must be clearly defined for each system who the business approver is. This sounds trivial but is a point where many organizations fail because this assignment was never explicitly made.

The escalation level applies when the regular approver is unavailable or when there is disagreement.

Special cases in the approval process

Emergency access. Sometimes someone urgently needs access to a system and the approver is on vacation. For this case, you need an emergency process: a defined deputy can grant temporary access. The regular approval is obtained afterwards. Emergency access is specially documented and by default limited to 48 hours.

Temporary permissions. For projects, substitutions, or temporary tasks, permissions should always be assigned with an expiration date. Nothing is more permanent than a temporary solution, and temporary permissions that never expire are one of the most common causes of privilege creep.

External service providers. For external consultants, auditors, or IT service providers, stricter rules apply: permissions are always time-limited, access is logged, and after completion of the engagement, accounts are immediately deactivated. The associated non-disclosure agreements should be signed before permissions are granted.

Regular recertification

An access control concept is not a document you create once and then file away. Without regular review, it becomes outdated within a few months as responsibilities change, employees switch departments, or new systems are introduced.

Recertification means: at defined intervals, you systematically review whether the granted permissions are still justified. Each business approver confirms (or revokes) the permissions in their area of responsibility.

Recertification cycle

How a recertification works

Preparation. IT creates a list of all permissions in each business approver's area of responsibility. For each permission, it shows: which employee, which role, which specific permissions, since when.

Review. The business approver goes through the list and decides for each permission: confirm (employee still needs the permission) or revoke (permission is no longer required). During the review, the following questions should be answered: Is the employee still in the function for which the permission was granted? Has the employee actually used the permission in recent months? Is there a role that would be a better fit?

Implementation. IT revokes all permissions that were not confirmed. This step must not be optional. If an approver does not actively confirm a permission, it is revoked. The principle is: when in doubt, revoke — not when in doubt, keep.

Documentation. The results of the recertification are documented: who reviewed which permissions when, which were confirmed, and which were revoked.

What recertification regularly uncovers

In practice, the first recertification typically identifies 15 to 25 percent of all permissions as no longer necessary. Typical findings:

• Employees who changed departments but still hold permissions from their old department
• Accounts of former employees that are still active (especially for freelancers and external consultants)
• Test accounts from project phases that were never deactivated
• Individual permissions granted for a long-completed project
• Employees who have permissions they themselves do not know about

Documentation for the auditor

During an ISO 27001 audit or NIS2 review, the auditor will not look into your Active Directory and check the technical configuration. The auditor checks whether you have a documented, traceable access control concept and whether you actually follow it.

Which documents you need

The access control concept itself. An overarching document describing the principles: least privilege, RBAC approach, approval workflow, recertification cycle. This document answers the question: how do you fundamentally handle permissions?

The role matrix. The tabular overview of all roles and their permissions per system. The auditor wants to see that there are defined standard roles and that not every employee has individual permissions.

Permission requests. Evidence that permissions are requested and approved through a defined process. This can be a ticket system, a form in SharePoint, or an email chain with documented approval. What matters is that the request, the approval, and the implementation are traceable.

Recertification records. Evidence that granted permissions are regularly reviewed. Date, reviewer, result, implemented changes.

Change history. When something changes in the access control concept or the roles, it must be documented: what was changed, when, by whom, and why.

Typical auditor questions and how to answer them

Practical example: access control concept for a machine manufacturer

To close, a complete example showing what an access control concept looks like in practice. The sample company: a machine manufacturer with 95 employees, an ERP system (SAP Business One), a DMS, a production control system, a CRM solution, and a standard Office environment with Active Directory.

Step 1: Identify roles

Based on the organizational structure and actual tasks, the following roles are defined:

14 roles for 95 employees. That is a good ratio. The team lead role is designed as an add-on role that supplements the base role of the respective department.

Step 2: Identify critical permission combinations

Before permissions are assigned, the company defines which role combinations are prohibited:

Step 3: Define approvers and plan recertification

The company defines the business approver and the recertification cycle for each system. All permission requests are handled through the existing ticket system, with a workflow requiring mandatory approval by the business owner.

The first full recertification is planned for six months after implementing the concept, then annually. Admin accounts are reviewed every three months.

Step 4: Clean up the existing state

When introducing the access control concept, a one-time comparison is performed: which actual permissions exist, and do they match the target permissions from the role matrix?

In our example, this comparison revealed: 23 employees had permissions exceeding their role. 4 accounts of former employees were still active. 7 test accounts from an ERP implementation two years ago still existed. 12 employees had access to network drives of other departments without an apparent need.

All of this was cleaned up during the implementation phase. The effort: approximately three weeks for IT and business departments working together. Not an excessive effort, but a significant security improvement.

From theory to implementation

Building an access control concept is not a massive project requiring months and external consultants. For a company with 100 employees, the following timeline is realistic:

In total, about eight weeks if you are doing your regular job alongside. The technical implementation in the individual systems (Active Directory, ERP, DMS) comes on top but depends heavily on the specific systems and can run in parallel with the conceptual work.

The result: you know who may access which systems and why. You have a process that prevents uncontrolled permission granting. You regularly review whether permissions are still correct. And when the auditor comes, you present the role matrix, the approval workflow, and the recertification records.

Further reading

• User Lifecycle: Managing Onboarding, Offboarding, and Role Changes
• Zugangs- und Zutrittskontrollrichtlinie: Physisch und logisch
• Die wichtigsten ISMS-Rollen: ISB, CISO, Risikoeigner – wer macht was?
• Passwort-Richtlinie erstellen: Anforderungen, Beispiel und Durchsetzung
• IT Asset Management for the ISMS: Inventory, Criticality, and Classification

This is not bureaucratic overhead. This is professional access management — and it protects your organization from risks you would not even see without this concept.