Creating an access control policy: who can do what, and who checks?

An employee moves from sales to purchasing. Her new access works. So do her old CRM export permissions. Transitions like these reveal whether your access control policy works in practice.

A useful policy describes three things: which tasks require which permissions, who approves those permissions and how you check actual assignments. A list of groups is only one part. This guide provides a role matrix and a process you can test in one application.

Start with tasks, not existing groups

Choose an application with clear owners. First describe the activities: reading customer data, editing quotations, changing master data or granting permissions. Assign the minimum suitable permissions to each.

The BSI IT-Grundschutz module ORP.4 addresses needs-based assignment and removal of permissions no longer required after personnel changes in A2. A3 covers comparing documented permissions with actual access; A4 covers separating incompatible duties. The templates below are our practical implementation aids, not BSI forms.

Do not simply copy every existing permission into the target model. That would turn inherited problems into the standard.

A role matrix that supports decisions

Fictional CRM example: the exact assignments depend on your tasks and application.

For each role, add permissions explicitly excluded. Exporting data, for example, can have a different effect from reading individual records. Check conflicts too: may the same person initiate a critical transaction and approve it?

Exceptions need a reason, a deciding role and a next review trigger. “We might need it later” is not a meaningful task description.

Coordinate joiners, movers and leavers

For a joiner, the process starts with a confirmed task. The responsible business role requests the appropriate role, an authorised person decides, and IT operations implements it. The record connects the request, approval and access actually provisioned.

For a mover, check both sides: add new permissions and remove old ones. Explicitly record whether transitional permissions are needed and when they end. A completed onboarding ticket does not demonstrate removal of previous access.

For a leaver, those involved must know when access is to be blocked. Include local accounts, external services and administrative access alongside the central user account. Review technical accounts separately: they may still be needed, but require an owner and, where appropriate, changed credentials.

Check the actual state, not just the last approval

Recertification is another substantive review of existing permissions. Define its scope and frequency based on your risks. A fixed interval alone does not replace a review after a role change or another material change.

Obtain the actual permission assignments from the application. Compare them with tasks, the role matrix and approved exceptions. Direct grants and nested groups may also matter.

A review is traceably complete only when the decision has been implemented or an unresolved exception has been consciously continued. Sending a request to revoke access is not sufficient.

Separate governance from technical enforcement

An identity or access management system enforces access technically. Your ISMS connects policies, responsibilities, reviews and outstanding measures. The two need to align.

One application is enough for an initial test: take a real role change, compare intended and actual access, and follow a necessary change through to technical evidence. You can then see whether the gap lies in the role description, handover or implementation.

If you want to discuss this process in Kopexa, bring that specific case. What matters is keeping responsibility, the measure and evidence connected; granting permissions in the target system remains a separate technical task.