Access Control Policy: How to Establish Verifiable Access Rights—With a Template and Sample

What is an access control policy?

An access control policy is a documented, binding set of rules that specifies which individuals, roles, or technical identities are permitted to access which IT systems, applications, and data; to what extent (read, modify, delete, share); and under what conditions. It also describes the processes through which access rights are requested, approved, granted, modified, revoked, and regularly reviewed.

In short: The access control policy answers four questions—Who is allowed to do what, where, and why? The fourth question is the most critical. An access right without a documented business justification is worthless in an audit, even if it was technically granted correctly.

In day-to-day business operations, an access control policy typically comprises three levels:

• The policy level: Principles such as the need-to-know principle, least privilege, and separation of duties, as well as responsibilities and approval workflows.

• The structural level: the role model—that is, the grouping of individual rights into business roles—as well as the authorization matrix, which maps roles to systems.

• The process level: the lifecycle of each authorization, from request through assignment to revocation—closely integrated with the HR department’s “Joiner-Mover-Leaver” process.

Distinctions: Authorization Concept, Role Concept, Authorization Matrix, and Authorization Management

In projects, these terms are often used interchangeably. This leads to misunderstandings between IT, business units, and the audit department. The following overview provides clarity:

The authorization concept, then, is the “what” and “why”; authorization management is the “how” in day-to-day operations; and Identity and Access Management is the “with what.” You can find a detailed overview of Identity Management, IAM, IGA, and PAM in our article “Identity Management: Definition, Delimitation, and Best Practices.”

The Five Fundamental Principles of Every Authorization Concept

Regardless of industry or company size, a robust authorization concept is based on five principles. These principles originate in information security and are reflected almost verbatim in standards and regulatory requirements.

1. Need-to-know principle

Each person is granted access only to the information they need to know to perform their specific task. The need-to-know principle applies primarily to information and data. An employee in payroll accounting must be able to view salary data, whereas a sales employee does not.

2. Least Privilege (Principle of Minimal Rights)

Each identity is granted only the minimum privileges necessary to perform its function. The U.S. National Institute of Standards and Technology (NIST) defines least privilege as the principle whereby each entity is granted only the minimum system resources and authorizations it needs to perform its function. The principle was first formulated in 1975 by Jerome Saltzer and Michael Schroeder in their seminal paper on information security.

While “need-to-know” limits the “what,” “least privilege” limits the “how much”: read permissions instead of write permissions, temporary admin rights instead of permanent ones.

3. Segregation of Duties (SoD)

Critical tasks are distributed among several people so that no single person controls a process from start to finish. A classic example: The person who creates a vendor account must not be authorized to approve a payment to that vendor. Segregation of duties is established as a separate control in ISO/IEC 27001:2022 (Annex A 5.3).

4. Dual Control Principle and Approval Processes

Critical authorizations—such as administrator rights or access to particularly sensitive personal data—are granted only after approval by a second, technically competent person.

5. Traceability and Accountability

Every assignment, change, and revocation is documented: who, when, at whose request, and for what reason. The GDPR refers to this as accountability. Without this documentation, even the best authorization concept cannot be defended during an audit.

Key principle for management: The “need-to-know” principle determines what someone is allowed to see. The “least privilege” principle determines how much someone is allowed to do with that information. The separation of duties principle determines what no one is allowed to do alone.

Why Is an Access Control Policy Important? Five Key Metrics Every CISO Should Know

The discussion about access rights is often framed as a compliance requirement. The numbers show that it is a tangible business risk.

62% of all data breaches involve human error.
The 2026 Verizon Data Breach Investigations Report analyzes more than 22,000 confirmed data breaches from 145 countries. The human factor—operational errors, social engineering, and misuse of credentials—was involved in 62% of cases, up from 60% the previous year. Compromised credentials were the initial point of entry in 13% of cases. Every unnecessary permission increases the damage that a compromised account can cause.

On average, a data breach costs a German company 4.25 million euros.
This is shown by the IBM Cost of a Data Breach Report 2026. In the previous year, the figure was 3.87 million euros. Globally, the average cost rose to approximately 4.99 million U.S. dollars.

Only 1% of granted permissions are actually used.
For its 2023 State of Cloud Permissions Risks Report, Microsoft analyzed permissions in multi-cloud environments. The result: identities use only about 1% of the permissions granted to them; half of all identities had so-called “super-identity” permissions with access to all resources. This figure refers to cloud infrastructures but illustrates a pattern familiar to CISOs from on-premises environments: permissions are granted generously and rarely revoked.

Insiders account for a significant portion of the perpetrators.
The Bitkom study “Economic Protection 2026” estimates the total damage to the German economy at at least 211 billion euros per year (with a range of up to 270.8 billion euros). Among the affected companies, 23% cite current or former employees acting unintentionally and 19% cite those acting intentionally as the perpetrators. Former employees with accounts that are still active represent exactly the scenario that a functioning leaver management process is designed to prevent.

92% of organizations that experienced AI-related security incidents lacked adequate AI access controls.
This, too, is a finding of the IBM 2026 Report. AI assistants and agents are creating new, non-human identities that access corporate data. An authorization model that recognizes only humans will be incomplete by 2026.

Regulatory Pressure: What the GDPR, NIS2, DORA, and ISO 27001 Require

In addition to economic risk, regulatory pressure is increasing. The following overview shows the requirements for an authorization framework derived from the most important regulatory frameworks for companies in the DACH region:

Note: This overview is intended for guidance only and does not constitute legal advice. The regulations that apply to your company depend on your industry, size, and activities.

It is worth noting the precision with which DORA formulates its requirements. The Delegated Regulation on ICT Risk Management explicitly requires that access rights be granted in accordance with the principles of “need-to-know, need-to-use, and least privilege,” that generic and shared user accounts be avoided as much as possible, and that rights for ICT systems supporting critical or important functions be reviewed at least every six months. For banks and insurers, the authorization framework is thus no longer merely a matter of best practice, but a verifiable obligation with a fixed schedule.

Our guide, “Navigating the Complex EU Regulatory Landscape,” provides an overview of how these regulatory frameworks interact strategically.

What Should Be Included in an Access Control Policy? A Template for Your Outline

An access control policy doesn’t have to be a hundred pages long. However, it must be comprehensive. The following access control policy template outlines the structure that has proven effective in practice and that auditors expect.

Access Control Policy Template – Recommended Outline:

1. Purpose, Scope, and Objectives – Which organizational units, locations, systems, and identity types (employees, external parties, service accounts, AI agents) are covered?

2. Legal and Regulatory Framework – GDPR, NIS2 or national implementation, DORA, industry-specific requirements, internal policies.

3. Definitions and Fundamental Principles – Need-to-know principle, least privilege, separation of duties, dual-control principle, accountability.

4. Roles and Responsibilities – Conceptual responsibility (usually the CISO), system and data owners, executives as requesters and recertifiers, IT as implementers, audit as verifiers.

5. Identity Types and Account Types – personal accounts, privileged accounts, emergency accounts, technical and non-human identities, external identities.

6. Role Model – Role classification system (basic roles, functional roles, project roles, special roles), naming conventions, role descriptions.

7. Authorization Matrix – Assignment of roles to systems, data objects, and permission levels.

8. Separation of Duties Rules (SoD Matrix) – incompatible combinations of roles and permissions.

9. Processes in the Permission Lifecycle – request, approval, assignment, modification, temporary permissions, revocation; integration with the Joiner-Mover-Leaver process.

10. Privileged Access and Emergency Access – Granting, Time Limits, Logging, “Break-Glass” Procedures.

11. Recertification and Controls – Frequency, Responsible Parties, Handling Deviations, Key Metrics.

12. Logging, Documentation, and Archiving – What is retained and for how long? How are historical authorization statuses reconstructed?

13. Exceptions and Escalation – Who is authorized to approve exceptions, how long do they remain valid, and how are they documented?

14. Maintenance and Versioning of the Policy – Review cycle, change procedures, approval by senior management.

The outline makes one thing clear: About half of the chapters do not concern IT technology, but rather organization, responsibility, and processes. This is precisely where it is decided whether an authorization policy is actively implemented or left to gather dust in the document management system.

The Four Root Causes of Failure in Authorization Policies

Does this sentence sound familiar? “We have an authorization policy. It’s just not accurate anymore.” The document exists, but the reality in the systems looks different. The reasons can be traced back to four root causes.

Cause: Accumulation of Rights: Permissions Grow, but Never Shrink

An employee starts out in purchasing, moves to controlling after three years, and later takes on a project management role. With each change, she is granted new permissions. The old ones remain because no one actively revokes them—after all, she might “still need” the data.

In the literature, this phenomenon is known as “privilege creep” or “accumulation of privileges.” After a few years, long-tenured employees end up with a privilege profile that no longer corresponds to their current role and undermines the principle of separation of duties. Our blog post on the topic of privilege creep describes this phenomenon in more detail.

Cause: Role Proliferation—The Role Model Does Not Reflect the Organization

Many role models are created bottom-up: IT copies the permission profile of an existing employee (“Please give me the same permissions as Mr. Müller”). After a few years, there are hundreds of roles, many of which are assigned to just a single person. The opposite is equally problematic: a few, very broad roles that bundle too many permissions. In both cases, there is no alignment with the actual organizational structure—with positions, functions, and responsibilities.

Cause: Lack of a Data Foundation: No One Knows for Certain Who Holds Which Function

An authorization concept requires that the following information be known for each identity: What is this person’s position? To which organizational unit do they belong? Who is their manager? Is their contract temporary? Is the person an external employee?

This information is scattered across the HR system, Active Directory, project tools, and departmental Excel spreadsheets—and is often inconsistent. Without a consolidated, up-to-date data record for each identity, every role assignment remains an estimate.

The cause: manual processes—granting and revoking access depend on emails and tickets

If an employee’s departure isn’t reported to IT until days later, accounts remain active. When permissions are requested via email and set manually, there is no audit-proof documentation. Recertifications are sent as Excel lists, checked off, and filed away—often without any real verification. Manual processes do not scale and create precisely the gaps that become apparent during an audit.

Interim conclusion: None of these four causes is primarily a technology problem. The accumulation of permissions, uncontrolled proliferation of roles, and manual processes are symptoms. The actual cause runs deeper.

Your authorization policy is not a document, but a data model

Most companies treat the authorization policy as a document: it is created, approved, filed away, and updated every two years. This perspective is at the heart of the problem.

An authorization concept describes a mapping: Organization → Roles → Permissions. The organization changes every day—due to new hires, departures, transfers, restructuring, new projects, and acquisitions. A document cannot capture this dynamic. A data model can.

The shift in perspective is therefore this: You don’t have an authorization problem; you have a master data problem. If identity and organizational data are clean, up-to-date, and unambiguous, roles can be derived based on rules, and permissions can be automatically granted and revoked. If this data is flawed, even the most sophisticated role model won’t help.

What this means in concrete terms:

• Instead of “Role X is manually assigned to Person Y,” the rule is “Every person with the position ‘Accounts Payable’ in the organizational unit ‘Finance DE’ automatically receives the role ‘FI Accounts Payable Processing.’”

• Instead of “IT is notified of the departure via email,” the rule is “The departure date in the HR master record triggers the revocation of all permissions as of the effective date.”

• Instead of “recertification via an Excel list,” the rule is “Discrepancies between target permissions (from the model) and actual permissions (in the target systems) become visible daily.”

This logic corresponds to the Golden Record principle: a unique, consolidated, and historical data record for each identity, from which all downstream systems derive their information. Only on this basis does the authorization concept become a set of rules that enforces itself.

For CISOs, this shift in perspective has an important implication: the authorization concept is not solely the responsibility of IT security. It requires HR as the source of identity data, the business units as the owners of the roles, and organizational development as the owner of the structural data. Anyone who anchors the project solely in IT is building on sand.

Creating an Authorization Strategy: Eight Steps to a Robust Framework

The following eight steps provide a proven approach for creating an authorization strategy or fundamentally revising an existing one. The order has been deliberately chosen: first, clarity regarding data and responsibilities; then roles; and finally, technology.

Step 1: Define the Scope, Objectives, and Responsible Parties

Start by defining which systems, organizational units, and identity types the access control policy covers. Don’t start with all 300 applications; instead, begin with the systems that pose the highest risk: ERP, HR systems, financial accounting, central directory services, and systems containing particularly sensitive personal data.

At the same time, designate the responsible parties:

• Concept responsibility: typically the CISO or the information security officer.

• System and data owners: one person per application who is responsible for the business domain and decides on roles and permissions.

• Managers: request permissions for their teams and confirm them during recertification.

• IT operations: implements permissions technically.

• Data Protection and Audit: verify compliance and effectiveness.

Have the mandate approved by senior management. NIS2 explicitly holds management bodies accountable for risk management measures; without this mandate, the project will lack the clout to enforce its requirements with the business units.

Step 2: Current Status Assessment of Identities, Accounts, and Permissions

Assess the current state: Which identities exist, which accounts do they have in which systems, and what permissions have been granted? This assessment is time-consuming but essential. It typically reveals three unpleasant findings:

• Orphaned accounts: Accounts without an associated active user, such as those belonging to former employees or completed projects.

• Excessive permissions: Permissions that extend beyond the user’s current role.

• Unknown identities: Service accounts, test accounts, and technical users without a documented point of contact.

Reconcile the accounts with HR master data. Every account needs a clearly assigned, responsible person—including technical accounts.

Step 3: Consolidate Identity and Organizational Data

This step is often skipped in most projects—and it’s the most important one. Before you define roles, you need a reliable data set for each person: position, function, organizational unit, cost center, location, manager, employment type, and contract start and end dates.

Combine the data from HR systems, directory services, project management, and departmental lists into a consolidated identity dataset. Remove duplicates, resolve discrepancies, and document the primary source for each attribute. Supplement the organizational structure with its hierarchies and validity periods. Our article “Organizational Management: The 360° View of Your Organizational Structure” shows how organizational data can be used as the foundation for HR processes.

The result is a database from which roles can later be automatically derived.

Step 4: Determine Protection Requirements and Data Classes

Not all information requires the same level of protection. Classify systems and data objects according to their protection needs—for example, into the categories public, internal, confidential, and strictly confidential. Label data sets containing personal data, particularly those involving special categories of personal data as defined in Article 9 of the GDPR.

The assessment of protection needs determines how strict the rules for a system will be: For strictly confidential data, for example, dual-control approvals, shorter recertification cycles, and comprehensive logging apply.

Step 5: Design a Role Model

Now the actual role and authorization concept is developed. A multi-level role system has proven effective:

• Basic roles: Permissions granted to every employee in the company (email, intranet, time tracking).

• Organizational roles: Permissions resulting from membership in an organizational unit (e.g., department’s shared drive).

• Functional roles: Permissions resulting from a specific position or function (e.g., accounts payable, HR specialist).

• Project roles: Temporary permissions for the duration of a project.

• Special roles: Privileged or rare permissions that are granted only after separate approval and are usually temporary.

Define roles top-down based on positions and functions, and reconcile them bottom-up with the permissions actually used (role mining). The concept of role-based access control (RBAC) was formalized at NIST in the early 1990s and later published as the ANSI INCITS 359 standard. Where roles alone are insufficient, supplement them with attribute-based rules (ABAC)—such as “access only to customers in one’s own country.”

Keep the role model lean. A good rule of thumb from practice: A role assigned to only a single person is usually not a role at all, but an exception.

Step 6: Define the Authorization Matrix and Segregation of Duties Rules

Translate the role model into an authorization matrix: Which role receives which permission level in which system? You’ll find a sample in the next section.

At the same time, define the segregation of duties rules as an SoD matrix: Which roles or permissions must never be held by the same person? Typical incompatible combinations include:

• Creating vendors and approving payments

• Creating user accounts and approving permissions

• Entering transactions and reviewing or approving transactions

• Modifying master data and deleting change logs

Every exception to an SoD rule must be justified, time-limited, safeguarded by compensating controls, and documented.

Step 7: Define Processes for the Authorization Lifecycle

Describe how authorizations are managed throughout their entire lifecycle—from onboarding to offboarding. The focus is on the Joiner-Mover-Leaver process:

• Joiner (Hire): When the HR master record is created, basic, organizational, and functional roles are automatically assigned—ideally on the first day of employment.

• Mover (Transfer): In the event of a transfer or change in position, new roles are assigned and roles no longer needed are revoked, with a defined transition period if necessary.

• Leaver (Departure): On the departure date, all rights are revoked and accounts are deactivated. For special cases such as parental leave or sabbaticals, the concept provides for temporary deactivation.

Supplement the process with procedures for individual requests outside the role model, for temporary rights, for privileged access, and for emergencies.

Step 8: Establish Recertification, Audits, and Metrics

An access control policy is only as good as its monitoring. Determine the frequency at which access rights are reviewed—based on risk, such as every six months for critical systems and annually for all others. For financial institutions, DORA mandates precisely this frequency.

Define key performance indicators (KPIs) to measure effectiveness:

• Percentage of access rights assigned via roles rather than individual assignments

• Number of orphaned accounts

• Average time to revocation of access rights after an employee leaves

• Number of open SoD conflicts and approved exceptions

• Recertification completion rate and deviation rate

Report these metrics regularly to senior management and the information security committee. This transforms the authorization concept from a document into a management tool.

Roles and Authorization Concept Template: What an Authorization Matrix Looks Like

The authorization matrix is the heart of every role and authorization concept. It shows at a glance which role has which rights in which system. The following example shows a simplified authorization matrix for a medium-sized company. It has been intentionally simplified and serves as a starting point for your own template.

Legend: R = Read · M = Modify/Create · A = Approve · AD = Administer · – = No Access

Associated Segregation of Duties Rules (Excerpt from the SoD Matrix)

Practical Tips for the Authorization Matrix:

• Describe rights rather than transactions: In the matrix for management and business units, functional authorization levels are sufficient. The technical representation (transaction codes, groups, profiles) belongs in a system-specific detailed matrix.

• Limit the scope of data: Specify which data a right applies to—for example, “own customers” or “assigned organizational unit.” This implements the need-to-know principle.

• Indicate time limits: Privileged rights should be marked as temporary in the matrix.

• Identify owners: Each column (system) needs a responsible system owner; each row (role) needs a role owner.

• Version control: Document which matrix was valid at what point in time. Audits often do not ask about the current status but rather the status as of a specific date.

RBAC, ABAC, or Both? Access Models in Role- and Permission-Based Concepts

A permission concept must define the logic used to determine access. In practice, three models have become established; these are not mutually exclusive but rather complementary.

Role-Based Access Control (RBAC) groups permissions into roles and assigns individuals to these roles. The model is easy to understand, easy to audit, and therefore forms the basis of most role- and authorization concepts. Its weakness: Fine distinctions—such as by country, client, or customer segment—quickly lead to a multitude of similar roles.

Attribute-Based Access Control (ABAC) makes decisions based on attributes of the person (e.g., organizational unit, location, employment type), the resource (e.g., data class, client), and the context (e.g., time, device). This allows rules such as “HR specialists can only view employees in their assigned organizational units” to be elegantly implemented. The prerequisite: The attributes must be accurate and up-to-date.

Policy-Based Access Control (PBAC) formulates access decisions as centrally managed policies that combine roles and attributes. It is suitable for complex, highly regulated environments but requires a high level of maturity in data quality and governance.

For most companies, a hybrid approach makes sense: RBAC as a stable foundation, supplemented by a few, clearly documented attribute rules. The key is the common prerequisite for all three models—accurate identity and organizational attributes. An ABAC rule set based on outdated cost centers or incorrect organizational assignments grants permissions with high precision to the wrong people.

Privileged Access and Emergency Accounts: The Most Sensitive Part of the Authorization Strategy

Privileged accounts—domain administrators, database superusers, root accounts, cloud administrators—are the most valuable targets for attackers. Whoever controls them controls the infrastructure. An authorization policy therefore regulates privileged access separately and more strictly than any other type of access.

Separation of everyday and administrative accounts.
Administrators work with a normal user account on a day-to-day basis and use a separate privileged account only for administrative tasks.

Time-limited access instead of permanent authorization.
Privileged rights are granted, whenever possible, only for the duration of a specific task (just-in-time principle) and are automatically revoked.

Dual-control approval and justification.
Every assignment of privileged rights requires a documented justification and approval by a second person.

Comprehensive logging.
Activities performed by privileged accounts are logged and regularly reviewed. The logs are protected against tampering by the administrators themselves—a direct application of the separation of duties principle.

Emergency access (“Break-Glass”).
Separately secured accounts exist for emergencies; their use triggers an immediate notification and is subsequently justified and reviewed. DORA explicitly identifies emergency access as a case to which the principles of need-to-know, need-to-use, and least privilege also apply.

Multi-factor authentication.
NIS2 identifies the use of multi-factor authentication solutions as a separate risk management measure. MFA should apply to privileged accounts without exception.

Joiner-Mover-Leaver: Where the Access Control Policy Is Put to the Test in Everyday Operations

Even the most carefully designed role model is useless if the assignment of individuals to roles does not keep pace with reality. The Joiner-Mover-Leaver (JML) process is the interface between human resources and access management—and thus the place where the quality of an access control policy is demonstrated on a daily basis.

Three principles make all the difference:

• HR data as the primary source: Hires, transfers, and separations are recorded in the HR system and trigger changes in access rights. IT responds not to emails, but to data changes.

• Reference date: Every change has an effective date. Rights are granted on the date of entry and revoked on the date of exit—not “sometime afterward.”

• A “mover” is the most critical case: The direction is clear upon entry and exit. When a user moves, rights must be granted and revoked simultaneously. This is precisely where rights accumulation occurs if the revocation is omitted.

Our article “Identity Management: Definition, Delimitation, and Best Practices” describes the detailed structure of the identity lifecycle. The article “Identity and Access Management: How to Automate Your User Management” shows how user management can be automated within this lifecycle.

Authorization Framework and the GDPR: What Data Protection Specifically Requires

The GDPR does not use the term “authorization framework.” Nevertheless, in practice, a documented authorization framework is the central technical and organizational measure through which companies can simultaneously fulfill and demonstrate compliance with several GDPR obligations.

Art. 5(1)(f) GDPR – Integrity and Confidentiality: Personal data must be processed in a manner that ensures appropriate security, including protection against unauthorized processing. Unauthorized access by the company’s own employees constitutes unauthorized processing.

Art. 5(2) GDPR – Accountability: The controller must be able to demonstrate compliance with these principles. Without a documented authorization policy and logs, this proof is virtually impossible to provide.

Art. 25(2) GDPR – Data Protection by Default: By default, only personal data whose processing is necessary for the specific purpose may be processed. This explicitly applies to the accessibility of the data as well. This is the “need-to-know” principle enshrined in law.

Art. 32 GDPR – Security of Processing: Controllers must ensure the confidentiality, integrity, availability, and resilience of their systems on an ongoing basis and take steps to ensure that persons under their authority who have access to personal data process it only on instructions.

Art. 30 GDPR – Record of Processing Activities: The record includes, where possible, a general description of the technical and organizational measures. The authorization concept serves as the obvious reference here.

Checklist: Designing a GDPR-Compliant Access Control Policy

• Personal data and special categories of data (Art. 9 GDPR) are identified in the data classification.

• For each role, it is documented which personal data is required and for what purpose.

• Access to personal data is limited to the necessary scope (record, field, or client level).

• Read access for analyses is, where possible, pseudonymized or anonymized.

• The granting, modification, and revocation of access rights are logged and traceable.

• Access rights are regularly recertified; the results are documented.

• The data protection officer is involved in the approval of the concept.

• Processors and external service providers are registered with their own, time-limited identities.

Our article “Data Minimization in Accordance with the GDPR” describes how central master data helps implement the principle of data minimization.

Authorization Concept for AI Agents and Non-Human Identities

Until a few years ago, an authorization concept was essentially designed for humans. Technical users of interfaces and batch jobs were considered a secondary concern. That is currently changing fundamentally. AI assistants, copilot functions in Office and ERP systems, and autonomous AI agents access corporate data, read documents, summarize customer data, and are increasingly initiating actions on their own.

This raises three new questions that a modern authorization model must address:

Whose rights does the AI act upon?
An AI assistant working on behalf of a person must, in principle, not have access to more information than that person does. If the authorization framework is flawed, the AI exposes those flaws: A search query to the assistant suddenly brings to light payroll lists, board meeting minutes, or personnel files that individual employees technically had access to but would never have found on their own. Excessive permissions, which were previously concealed by “security by obscurity,” become immediately effective through AI.

What rights does an autonomous agent have?
Agents that perform tasks independently—such as creating orders, processing tickets, or maintaining master data—are distinct identities. They require their own role profile based on the principle of least privilege, a responsible person designated as the owner, a time limit, and regular recertification.

How can AI actions be made traceable?
Every action taken by an agent must be traceable to an identifiable identity and, ultimately, to a responsible person. DORA already explicitly states the requirement to ensure that users can be identified at all times for their actions in ICT systems.

The figures underscore the urgency: According to IBM, 92% of organizations that experienced AI-related security incidents lacked adequate AI access controls. Microsoft noted as early as 2023 that workload identities outnumber human identities by a ratio of 10 to 1.

Implications for your authorization strategy: Expand the scope to include non-human identities, create separate role types for service accounts and AI agents, and ensure that AI functions adhere to the authorization strategy of the underlying systems. A well-defined authorization strategy is therefore not only a prerequisite for compliance but also for the secure deployment of AI. Our article “Why AI Fails Without Trustworthy Data” explains why AI fails without trustworthy data.

Best Practices: What Really Works in Authorization Projects

From master data and identity projects in regulated industries, we can identify seven practices that make the difference between a concept on paper and a set of rules put into practice.

Start with the data, not the roles.
A role model is only as good as the identity and organizational data on which it is based. Invest the first few weeks of the project in creating a consolidated identity dataset. Every hour you save here will save you many times that amount later on in role maintenance.

Derive roles from the organization.
Link roles to positions, functions, and organizational units rather than to individuals. Then permissions automatically follow the organization: When someone changes positions, their role changes.

Make business units the owners.
IT cannot determine whether a controller needs write access to cost centers. That decision belongs to the business unit. Designate a business owner for each role who is responsible for its content and assignment.

Treat privileged access separately.
Administrator rights, emergency accounts, and database access are prime targets for attackers. Grant them only for a limited time, following dual-review approval and with comprehensive logging. ISO/IEC 27001 lists privileged access rights as a separate control (Annex A 8.2).

Include non-human identities.
Service accounts, interface users, bots, and AI agents access the same data as humans. They require a designated responsible person, a documented purpose, and recertification. IBM's finding that 92% of organizations experiencing AI-related incidents lacked adequate AI access controls underscores the urgency of this issue.

Design recertification to be risk-based and context-aware.
A manager tasked with confirming 400 individual permissions is likely to click “Confirm All.” Group recertification by role, highlight discrepancies and critical permissions, and recertify high-risk systems more frequently.

Maintain an audit-proof history.
Auditors rarely ask, “Who has access today?” They ask, “Who had access to the payment system on June 30—and on what basis?” An authorization strategy therefore requires a complete, time-stamped history of all identities, roles, and permissions. Our article “The Six Benefits of Fully Automated Version Management in Identity & Access Management” describes the advantages of fully automated version management.

Maturity Model: Where Does Your Access Management Stand?

Not every company needs to reach the highest level of maturity right away. The key is to honestly assess your current position and plan the next logical step. The following four-level maturity model helps with this assessment.

In our assessment, most companies dealing with NIS2 or DORA are at Level 2 or 3 (industry benchmark). The leap to Level 4 is rarely achieved by adding another tool, but rather by consolidating the data foundation. This is precisely where a master data approach comes into play: Our guide to improving data quality shows how companies can systematically enhance their data quality.

RACI Matrix: Who Does What in the Access Control Policy?

Clear responsibilities are essential for ensuring that an access control policy is effectively implemented. The following RACI matrix illustrates a proven division of roles (R = Responsible, A = Accountable, C = Consulted, I = Informed).

Comparison: Three Ways to Implement an Access Control Policy

Companies implement their access control policies in very different ways. The following comparison table contrasts the three most common approaches.

The table makes it clear: The difference between the approaches lies less in the software than in the data foundation. An IAM tool without clean identity and organizational data will, in the worst case, simply automate errors. A data-centric approach anchors the authorization model where the truth about the organization lies.

Access Control Models by Industry: What Matters in Regulated Sectors

The basic principles of an access control policy apply across all industries. However, the key focus areas differ significantly depending on which regulatory frameworks apply and which data requires special protection.

Banks and Insurance Companies.
For financial institutions, DORA has been the central benchmark since January 2025. The authorization framework must implement the “need-to-know,” “need-to-use,” and “least privilege” principles, ensure segregation of duties, limit generic accounts, and adhere to fixed recertification intervals. In addition, there are banking-specific separations of duties between front office and back office, as well as between trading and settlement. Our article “Why Good Data Management Is Essential for Banks” explains why data management is indispensable for banks.

Energy providers and critical infrastructure.
NIS2 and national implementation laws are shifting the focus to the protection of operational systems. The authorization concept must cover not only office IT but also control systems and remote maintenance access by external service providers. Third-party access is particularly critical: According to the Verizon DBIR 2026, a third-party provider is involved in 48% of data breaches.

Manufacturing industry.
In production, office IT, ERP, production planning systems, and machine control all converge. Common vulnerabilities include shared shift accounts on machine terminals and access by maintenance service providers. The authorization concept should personalize these accounts or, where this is not possible, secure them through compensating controls.

Companies with corporate group structures.
In corporate groups with many subsidiaries, an additional dimension comes into play: Employees work across subsidiaries, organizational structures change due to acquisitions and restructurings, and permissions must be assigned on a per-client basis. Without a clear mapping of the corporate and organizational structure, a consistent authorization concept is not possible here.

Real-World Scenario: From a Concept on Paper to a Role Model in Practice

Note: The following scenario has been anonymized and summarizes typical situations encountered in identity management projects. It deliberately does not include any metrics specific to a single client.

Initial Situation

A financial services provider with multiple subsidiaries in Germany and Austria has an access control policy dating back to the year of its last ISO 27001 certification. The document describes principles and a role model; the authorization matrix is maintained as an Excel file. HR notifies IT via email of new hires and departures. Annual recertification is conducted using lists sent to managers.

Trigger

Under DORA, the regulatory authority requires a semi-annual review of access rights for systems with critical functions and proof that rights are revoked without undue delay upon an employee’s departure. The current state assessment reveals that some active accounts cannot be assigned to any active employee, several long-term employees retain rights from previous roles, and the role model contains numerous roles with only a single member.

Approach

Instead of revising the document, the project begins with the data. Identity and organizational data from the HR system, directory service, and departmental lists are consolidated into a single, unique data record per person. The organizational structure is mapped out, including positions and validity periods.

Building on this, business units and IT jointly derive functional roles from the positions; roles with individual members are dissolved or marked as exceptions. Permissions are automatically provisioned via interfaces and revoked on the termination date. Recertification takes place at the role level using a target-actual comparison.

Result

The authorization concept is no longer a separate document but is mapped within the data model. The written policy describes principles and responsibilities; roles, the matrix, and history are stored in the system. Audit inquiries regarding the authorization status as of a specific date can be answered using the history, rather than having to be reconstructed from logs across multiple systems.

Lessons Learned from the Scenario

The greatest leverage did not lie in role design, but in the consolidation of identity and organizational data. Only once it was clear who held which position could roles be meaningfully derived—and only then did automation become reliable.

The Audit Test: Ten Questions Your Authorization Concept Must Answer

Whether it’s ISO 27001 recertification, a NIS 2 audit, DORA oversight, or an annual financial statement audit: auditors ask surprisingly similar questions about the access control policy. Use the following list as a self-assessment. Any question you cannot answer within a few minutes with solid evidence indicates a gap.

1. Who currently has access to the payment system—and on what business basis?

2. Who had access to this system on a specific date in the past?

3. How many active accounts belong to individuals who have already left the company?

4. On average, how long does it take for access rights to be revoked after an employee leaves?

5. Which employees still have access rights from a previous role?

6. What conflicts regarding the separation of duties exist, and who approved which exceptions and on what grounds?

7. Who holds privileged access rights, since when, and when were these last reviewed?

8. What service accounts and technical identities exist, and who is responsible for each?

9. When did the last recertification take place, which permissions were revoked during that process, and how was this documented?

10. When was the access control policy last revised and approved by senior management?

It is striking that at least four of these ten questions require a look back into the past. This is where many companies falter, even if their current status is in order: logs are scattered across multiple systems, Excel spreadsheets have been overwritten, and the organizational assignments at that time are no longer known.

An authorization framework based on a time-stamped history of identity, organizational, and authorization data answers these questions with a single query rather than a reconstruction process lasting several weeks. The difference is not just a matter of effort; it determines whether an auditor issues a finding or not.

Tip for CISOs: Run the audit test internally once a year—ideally with someone from the audit department who asks the questions unannounced. Response times are a meaningful metric for the maturity of your access control management.

Pitfalls: What to Avoid in Your Access Control Framework

Treating the framework as a one-time project.
An access control policy that is never revisited after approval will become outdated within a few months. Plan for regular review cycles and clearly define who is responsible for making changes.

Start with the technology.
If you choose an IAM tool first and then write the concept, you’ll end up adapting the concept to the tool instead of the other way around. First, clarify the data model, role logic, and responsibilities.

Copying roles instead of deriving them.
“Same rights as colleague X” is the fastest way to accumulate rights. Every role needs a business justification and an owner.

Neglecting the “mover” process.
Hiring and termination are usually regulated, but internal transfers rarely are. Long-term employees, in particular, end up accumulating permissions from multiple roles this way.

Treating recertification as a formality.
When managers are asked to approve hundreds of individual permissions without context, the result is a checkmark on a list—but no actual control. Recertify roles, not individual permissions, and highlight discrepancies.

Ignoring technical and external identities.
Service accounts, third-party providers, and AI agents don’t even appear in many concepts—even though they often have far-reaching permissions. According to the Verizon DBIR 2026, a third-party provider is involved in 48% of data breaches.

Forgetting the history.
A policy that only reflects the current state cannot answer audit questions about past dates. Plan for versioning and retention from the very beginning.

Conclusion: An access control policy is only as good as the data it is based on

An access control policy is far more than just a compliance requirement. It is the answer to one of the most economically significant questions in information security: Who is authorized to do what in your company—and can you prove it at any time? With an average loss of 4.25 million euros per data breach in Germany, a human factor involved in 62% of all data breaches, and regulations such as the GDPR, NIS2, and DORA that explicitly require access controls, this question has reached the executive level.

The good news: The basic principles have been known for decades. The need-to-know principle, least privilege, and separation of duties form a solid foundation. The challenge lies in implementation. Authorization concepts rarely fail due to a lack of rules, but rather because they are treated as static documents, while the organization changes on a daily basis.

Anyone who wants to create an authorization concept that stands the test of time should therefore start with the data: a consolidated, up-to-date dataset for each identity and a clearly mapped organizational structure. Building on this, roles can be derived from positions and functions, rights can be automatically granted and revoked via the Joiner-Mover-Leaver process, and authorization statuses can be audited in an audit-proof manner for every reporting date.

This transforms the access control framework into what it should be: not just a folder for the next audit, but a management tool that combines security, compliance, and efficiency. Our Data Governance Framework 2026 describes how identity management and data governance work together in this context.

Sources

Verizon: 2026 Data Breach Investigations Report

IBM: Cost of a Data Breach Report 2026. German numbers via Silicon Saxony, · globale Zahlen via eSecurity Planet

Bitkom e. V.: Wirtschaftsschutz 2026

Microsoft: 2023 State of Cloud Permissions Risks Report

Regulation (EU) 2016/679 (DSGVO): Art. 5, Art. 25, Art. 30, Art. 32, Art. 83

Guideline (EU) 2022/2555 (NIS2): EUR-Lex

Heuking: Ab jetzt gilt’s: NIS2-Umsetzungsgesetz in Kraft

KPMG Austria: NISG 2026

Verordnung (EU) 2022/2554 (DORA): EUR-Lex

Delegated Regulation (EU) 2024/1774 (RTS IKT-Riskmanagement), Art. 21: Full Text

ISO/IEC 27001:2022: iso.org/standard/27001

BSI: IT-Grundschutz-Kompendium, Baustein ORP.4 Identitäts- und Berechtigungsmanagement

NIST Computer Security Resource Center: Glossary – Least Privilege

NIST: Role Based Access Control – FAQ

Saltzer, J. H.; Schroeder, M. D.: The Protection of Information in Computer Systems. Proceedings of the IEEE 63(9)