User Lifecycle: Managing Onboarding, Offboarding, and Role Changes

A problem every organization knows

Monday morning, 8:30 AM. The new colleague in sales is sitting at her desk and cannot do anything. No email access, no password for the CRM, no VPN token for remote work. IT did not know someone was starting today because the information got stuck somewhere between HR and team management. The new employee spends her first day filling out forms and waiting. Not a great start.

Three months later: a developer switches internally from project team A to project team B. He gets new access for his new project, but the old ones remain active. After a year, he has access to four different project environments even though he only works in one. Nobody thought to revoke the old permissions because no process exists for that.

And then the most critical case: an employee leaves the company under contentious circumstances. Their last working day is a Friday. On Monday, they can still log into the VPN because IT only deactivated the account on Tuesday. Over the weekend, the former employee worked on their private laptop and downloaded various customer lists.

All of these scenarios happen regularly. Not because the people involved are negligent, but because there is no defined process covering the entire lifecycle of a user account. That is exactly what user lifecycle management is: the systematic governance of IT permissions from an employee's first day to their last.

Why the user lifecycle is security-relevant

The user lifecycle directly touches several requirements of ISO 27001 and NIS2:

ISO 27001 Annex A.5.15 (Access Control) requires that access to information and systems be formalized and controlled. This explicitly includes the granting, modification, and revocation of access rights.

ISO 27001 Annex A.6.1 through A.6.5 (Personnel Security) addresses the entire employee lifecycle: screening before hiring, security awareness during employment, and measures upon termination or change of employment.

NIS2 Article 21 requires personnel security and access control as a minimum measure, including consideration of hiring and departure of employees.

A non-deactivated account of a former employee is not just a theoretical risk. It is an audit finding that immediately stands out, and it is a gateway for attacks that is regularly exploited in practice.

Phase 1: Onboarding — the first day matters

Onboarding does not begin on the new employee's first working day. It begins the moment the employment contract is signed. Between contract signing and the first day, there are often several weeks — and that is exactly the time you need to prepare everything.

The timeline before day one

At least 10 working days before start HR should inform IT about the new employee. The information must include at minimum: name, department, function/role, supervisor, location/workstation, and planned first working day.

At least 5 working days before start IT creates all accounts based on the defined permission profiles, sets up the workstation, and prepares the hardware. If you work with a role-based access control concept (and you should), this step is largely standardized: new employee in inside sales? Assign the "Sales Inside" role, done.

The day before start IT verifies everything works: can the access credentials be used? Is the workstation set up? Does the VPN connection work? Is the hardware ready?

The onboarding checklist

For every new employee, a standardized checklist is worked through. This checklist has four areas:

Area 1: IT accounts and access

Area 2: Hardware and workspace

Area 3: Training and briefings

Area 4: Policies and acknowledgment

Why policy acknowledgment is so important

The signed acknowledgment of security policies is not bureaucratic busywork. It serves two concrete purposes:

First, it shows the auditor that every employee has been informed about the applicable rules. An access control concept that only sits in a drawer and employees know nothing about is worthless.

Second, it creates a legal basis. If an employee violates the IT security policy, you need to be able to prove they knew about it. Without signed acknowledgment, this proof is difficult.

Special case: External employees

Freelancers, consultants, temporary workers, and interns need an adapted onboarding process. The key differences:

• Permissions are always time-limited (to the contract duration)
• Access is restricted to systems necessary for the assignment
• An enhanced confidentiality agreement is mandatory
• Physical access is limited to necessary areas
• The account receives a special tag in Active Directory (e.g., prefix "EXT-") so external accounts are identifiable at all times

Phase 2: Role change — the underestimated risk

Of the three phases in the user lifecycle, the role change is the most error-prone. During onboarding, something new is built; during offboarding, everything is torn down. Both are conceptually simple. But during a role change, something must be removed and something new added simultaneously. And it is precisely the removal that is regularly forgotten in practice.

What triggers a role change

A role change in terms of permission management occurs when an employee's function changes. This can have various causes:

• Transfer to another department (e.g., from sales to product management)
• Promotion with new responsibilities (e.g., from clerk to team lead)
• Taking on additional tasks (e.g., project management alongside regular duties)
• Return from a temporary function (e.g., after a project phase or parental leave substitution)
• Departmental restructuring

The problem: Privilege creep

Privilege creep is the gradual accumulation of permissions over time. It arises almost exclusively from role changes carried out without a complete permission reconciliation.

An example: Maria has worked at the company for eight years. She started in procurement, spent two years in quality assurance, then led an SAP implementation project, and is now a team lead in sales. At each change, she received new permissions. But no one revoked the old ones. The result: Maria has access to procurement data, QA reports, SAP administration functions, and sales data. She only needs the last one for her current role.

Maria's account is a security risk. Not because Maria has malicious intent, but because if her account is compromised, the blast radius is disproportionately large. And because the auditor will immediately ask during recertification: why does a sales team lead have admin access to the ERP?

The role change process

A clean role change process ensures that old permissions are consistently revoked and new permissions are correctly granted.

Step 1: Trigger and notification. The supervisor or HR informs IT about the upcoming role change. The notification contains: employee, previous function/role, new function/role, date of change.

Step 2: Target vs. actual comparison. IT creates a comparison: what permissions does the employee currently have (actual), and which do they need in the new role (target)? This produces three categories:

Step 3: Approval. The new supervisor approves the permissions for the new role. The previous supervisor confirms that the permissions of the old role can be revoked. If there are uncertainties (e.g., whether the employee needs certain old permissions for a transition period), IT clarifies with both supervisors.

Step 4: Implementation. On the day of the role change, new permissions are activated and old ones deactivated simultaneously. Not sequentially, not "when we get to it," but on the same day.

Step 5: Transition period (only if necessary). In some cases, a transition period is sensible during which the employee holds both old and new permissions. This applies when they still need to close out ongoing matters. This transition period must be explicitly approved, time-limited (maximum 30 days), and documented.

Step 6: Documentation. The entire process is documented: trigger, target vs. actual comparison, approvals, implemented changes, any transition periods.

Promotion as a special role change

Promotions are often handled incorrectly in permission management. The reflex is: the employee gets additional permissions for their new leadership role. The old permissions stay because they "also still do the operational work." Result: the newly promoted team lead has their operational permissions plus management permissions — significantly more than necessary.

The correct approach: a promotion is also a complete role change. The employee receives the team lead role, which contains all necessary permissions. If a team lead actually still performs operational tasks, the team lead role must contain those permissions. The old operational role is still revoked, and the necessary operational permissions are defined in the new role.

Phase 3: Offboarding — no room for mistakes

Offboarding is the phase where mistakes have the most severe consequences. A forgotten account during onboarding is annoying but harmless. A forgotten account during offboarding is an open barn door.

Why timing is critical

The deactivation of all accounts must happen on the last working day. Not the next business day, not when IT gets to it, but on the last working day. In the case of termination without notice, deactivation must happen immediately — ideally while the conversation is still happening or immediately afterward.

This sounds harsh but is the only secure approach. A former employee who can still log into systems after their last day represents a risk that is easily avoidable. This applies regardless of whether the employee left on good or bad terms. IT cannot judge how the separation went, and it does not need to. The process is the same for everyone.

The offboarding checklist

Offboarding has three areas: account deactivation, data handover, and hardware return.

Area 1: Account deactivation

The last point deserves special attention. Shared accounts (a common login for a service, a team password for an access) are generally problematic and should be avoided. But if they exist, the passwords must be changed when an employee who had access leaves.

Area 2: Data handover and backup

Area 3: Hardware return

Special cases during offboarding

Termination without notice or garden leave. In an immediate separation, HR must inform IT without delay. Account deactivation occurs while the employee is still on premises or as soon as the termination is communicated. Ideally, there is a predefined emergency process that can be triggered with a single call.

Long-term absence or parental leave. In this case, the account is not deactivated but permissions are reduced to a minimum. Email access and basic intranet functions remain active; access to business applications is revoked. Upon return, permissions are reactivated through the normal approval process.

Death of an employee. A sensitive case that nonetheless requires a clear process. Accounts are deactivated, the email mailbox is archived and made available to the supervisor, and hardware is collected. HR coordinates; IT executes.

Transfer to a competitor. Some organizations have stricter offboarding rules for employees who move to a direct competitor. This may include immediate lockout upon learning of the move, or a special review of data the employee accessed in recent weeks.

Email handling after departure

A common question: what happens to the email account after departure? An employee's email address is simultaneously a business contact address through which customers, suppliers, and partners communicate.

The recommended approach:

Immediately: Set up an automatic out-of-office notice. Content: "Ms./Mr. [Name] is no longer employed at [Company]. Please contact [alternative contact person] at [email]."

30 to 90 days: Emails to the account are forwarded to the successor or supervisor. The out-of-office notice remains active.

After 90 days: The account is permanently deactivated. Emails to this address receive a non-delivery notification. The mailbox is archived and deleted after the defined retention period (often 6 to 10 years due to commercial and tax retention requirements).

Permission profiles as templates

If you use standardized permission profiles for each phase of the user lifecycle, you significantly reduce manual effort and minimize errors. A permission profile is essentially a template that defines which access and permissions an employee needs in a specific function.

Structure of a permission profile

A complete permission profile contains all the information IT needs to set up or adjust an account:

Profile: Sales Inside

When a new employee starts in inside sales, IT takes this profile and sets up everything accordingly. There is no room for interpretation, no follow-up questions, and no forgotten access.

Maintaining and updating profiles

Permission profiles are not static. When a new system is introduced, all affected profiles must be updated. When a department is restructured, profiles may change. Every change to a profile must be documented: what was changed, when, by whom, and why.

A practical tip: conduct an annual review of all permission profiles, ideally as part of the regular recertification. Invite department heads and review together: are the profiles still accurate? Are any access rights missing? Are permissions included that are no longer needed?

Automation through AD integration

The more steps in the user lifecycle that are performed manually, the higher the error rate. Active Directory (or a comparable directory service system) offers extensive opportunities to automate the process.

What can be automated

Group membership controls permissions. The central idea: an employee is assigned to an AD group, and group membership automatically controls permissions in downstream systems. ERP, CRM, DMS, and other applications read group membership from AD and grant or deny access accordingly.

This makes role changes significantly easier. Instead of manually changing permissions in five different systems, you move the employee in AD from the "Sales Inside" group to the "Product Management" group, and the connected systems automatically adopt the new permissions.

Automatic account deactivation. In Active Directory, an expiration date can be set for accounts. For temporary employees, external consultants, and temporary permissions, this is invaluable. The account is automatically deactivated on the defined date without anyone needing to remember.

Provisioning scripts. For onboarding, PowerShell scripts can be created that set up a complete account at the push of a button: AD account, email, group memberships, home directory. The IT administrator enters the name, department, and role, and the script does the rest.

Monitoring and alerts. Automatic notifications when an account has not been used for 60 days, when a temporary permission is about to expire, or when an employee is simultaneously in groups that represent a segregation of duties conflict.

What cannot be automated

Business approval cannot be meaningfully automated. A human must decide whether an employee needs a specific permission. The same applies to the review during recertification and to the content-level handover during offboarding and role changes.

Automation therefore does not replace the process — it supports it. Decisions are still made by humans, but the execution of those decisions happens faster, more consistently, and with fewer errors.

Cost-benefit analysis

For a company with 100 employees, automation almost always pays off. Expect approximately 10 to 15 personnel changes per year (onboarding, offboarding, internal transfers). If each change requires 2 to 4 hours of manual IT effort, that is 20 to 60 hours per year. A well-configured AD with provisioning scripts reduces this to 30 to 60 minutes per change. Add the reduced error rate, which is hard to quantify in euros but can quickly become expensive when a security incident results from a forgotten account.

The audit trail: complete traceability

Every permission change in the user lifecycle must be traceably documented. This is not optional diligence — it is a core requirement of every ISMS and one of the first checkpoints in an audit.

What must be documented

For every permission change, the audit trail needs the following information:

Where the audit trail is stored

The audit trail can be maintained in various places depending on your infrastructure:

Ticket system. If every permission change is handled through a ticket, the audit trail is essentially created automatically. The ticket contains the request, the approval, the implementation, and the confirmation.

Active Directory logs. Windows Server logs changes to user accounts and group memberships. These logs must be forwarded to a central log management system so they are not lost on the server itself or tampered with.

ISMS tool. An ISMS tool like ISMS Lite documents policy changes with versioning, approval workflows, and an audit trail. This allows you to demonstrate when a specific access control policy was valid and who approved it. ISMS Lite costs 500 Euro pro Jahr for all modules, with no user limits.

What matters is not which system you use, but that the audit trail is complete, tamper-proof, and searchable. The auditor will ask about a specific employee and want to see which permission changes were approved, when, and by whom.

Retention periods

Audit trail data should be retained at least as long as the employment relationship lasts, plus a follow-up period of at least three years. For regulated industries, longer periods may apply. When in doubt, follow the commercial retention periods (6 to 10 years) — that puts you on the safe side.

Anchoring the user lifecycle in practice

A user lifecycle process only works if all involved parties know and follow it. IT alone cannot deliver this because the triggering events (new hire, transfer, termination) occur in HR and the business departments.

Key success factors

Early notification. HR must inform IT about all personnel changes in a timely manner. This sounds self-evident but surprisingly often fails in practice. A simple solution: a standardized form that HR completes and sends to IT for every personnel change. Even better: an automatic notification from the HR system.

Clear responsibilities. For every step in the process, it must be clear who is responsible. Not "IT" but a specific role or person. Not "the supervisor" but the direct supervisor of the new (not the old) department.

Accountability. The process must be binding. If a supervisor hires a new employee without informing IT, there must be consequences. Not as punishment, but as a signal: this process is not optional.

Regular review. At least once a year, you should check whether the process works: are all new hires reported in time? Are old permissions consistently revoked during role changes? Are all accounts deactivated on the last working day during offboarding? Permission recertification provides valuable data here.

KPIs for user lifecycle management

To make the quality of your user lifecycle process measurable, the following KPIs are useful:

These KPIs can be measured quarterly and show you where the process works well and where improvements are needed. With an ISMS tool like ISMS Lite, you can manage, version, and submit the associated controls and policies for review — the operational measurement of KPIs happens in your IT systems (ticket system, AD logs, HR tool). For the auditor, such figures send a strong signal: here, a process is not just defined on paper — it is measured and improved.

Further reading

• Creating an Access Control Concept: Roles, Permissions, and Approval Workflow
• Die wichtigsten ISMS-Rollen: ISB, CISO, Risikoeigner – wer macht was?
• Zugangs- und Zutrittskontrollrichtlinie: Physisch und logisch
• Building a Security Awareness Program: What Employees Really Need to Know
• Training Records in the ISMS: What Must Be Documented

The user lifecycle is not a glamorous topic. But it is one of the areas where professional information security management most clearly distinguishes itself from improvisation. Every permission change follows a defined process, every decision is traceable, and no former employee has access to your systems after their last working day. That is the standard — and with the right processes, templates, and a bit of automation, it is achievable even for a company with 100 employees.