Two moments decide how orderly access is in a company: the first working day and the last. On the first day, a new colleague sits in front of a computer for which no account exists yet, waits for a mailbox and receives the sign-in details for the business software by word of mouth from the next desk. On the last day, the laptop comes back, the mailbox is redirected - and six months later someone notices by chance that access to the supplier portal is still active, because that portal appears on no list. Both cases share one cause: accounts and rights hang on a personnel event that starts in the HR department and ought to end in IT, but falls apart along the way in emails, hallway conversations and memory. This article shows how joining and leaving can be mapped as one continuous, triggered workflow across all systems - and what you have in hand when an auditor asks who held which rights and when. How we support such a review is described under process analysis.
Key takeaways
- Joining corrects itself, leaving does not: if access is missing on the first day, the person affected reports it within minutes. If an account stays open after the last day, no one reports it - the mistake remains unnoticed until somebody deliberately looks for it.
- Every automation starts with a list: which systems, mailboxes, distribution lists, devices, keys and external portals hang on a position. Experience shows that the first draft misses access held with third parties, because it is not tied to any central sign-in.
- Rights are granted through roles, not individually. A role describes what a position needs; it is approved once and assigned repeatably afterwards. When someone changes department, the old role is removed instead of the new one being layered on top.
- The trigger belongs in the HR system. Joining, moving and leaving are recorded there anyway as a record with a date and a position - that record can start the technical workflow instead of announcing it by email.
- Locking, retaining and deleting are three separate steps with three separate deadlines. Mixing them means either deleting too early and losing evidence, or deleting too late and keeping personal data without a purpose.
Why access is missing on day one and still open after the last day
In many companies the sequence looks the same. The HR department writes an email saying that someone starts on the first of the month. IT reads it, sets up what it knows about and asks about the rest. The department adds whatever comes to mind as soon as something turns out to be missing. No single step is wrong, but the workflow has no fixed beginning, no complete list and no defined end. Afterwards, no single place has a full view of what was created - and precisely that missing overview comes back to bite when someone leaves.
There is an asymmetry between joining and leaving that explains the whole difference. If access is missing on the first working day, the person affected reports it within minutes; the mistake therefore corrects itself. If an account stays open after the last working day, nobody reports it, because an open account bothers no one. Leaving is thus the quiet part of the workflow, and quiet mistakes accumulate. After a few years, almost every directory service that has grown organically contains a set of accounts whose holders have long since moved on. Stolen credentials were the initial attack vector in 22 percent (Verizon DBIR 2025) of the breaches examined most recently - which makes open accounts a rewarding target, entirely without any ill intent from the former colleague.
The scale of the topic can be quantified. 87 percent (Bitkom) of companies in Germany were affected by data theft, espionage or sabotage within twelve months; a year earlier the figure was 81 percent (Bitkom). The quantified total damage came to 289.2 billion euros (Bitkom). These numbers do not describe the individual case of a mid-sized business, but they explain why auditors, insurers and clients increasingly ask how the removal of rights is organised. A cleanly run joiner and leaver workflow is the least spectacular and at the same time the most effective answer: it removes access that should no longer exist at all.
The quiet part costs more than the loud one
Taking stock: everything that hangs on one person
Before anything is automated, a list is needed. It answers a simple question: what comes into existence when somebody starts, and what has to disappear when somebody leaves? In almost every company the answer turns out longer than expected, because access has been created in different places over the years. The German IT baseline protection standard treats identity and access management as a building block of its own (BSI) and puts taking stock at the very beginning - for good reason: what is not on the list will not be revoked either.
A useful structure has five areas. First, system accounts: computer sign-in, business software, inventory management, time tracking, accounting. Second, mailboxes and distribution lists, including shared mailboxes and calendar sharing. Third, devices: computer, mobile phone, badge card, fuel card. Fourth, physical access: keys, transponders, alarm codes, lockers. Fifth, access held with third parties - supplier portals, public authority portals, certificate authorities, carrier portals. The fifth area is the one that experience shows is missing, because such access is not tied to any central sign-in and was often set up directly by the department. How a list of this kind can be maintained over time is covered under process documentation; the underlying data is sorted out in the article on getting master data in order.
Area | Access | create | revoke | Evidence
--------------+----------------------------+---------+-----------+-------------
Directory | Sign-in account, role | Day -3 | Day 0 | Log entry
Mailbox | Address, calendar | Day -3 | Day 0 | Log entry
Business sw. | Role Sales | Day 1 | Day 0 | Log entry
Time tracking | Master record, badge no. | Day -1 | Day 0 | Log entry
Devices | Laptop, mobile phone | Day -1 | Day 0 | Signature
Keys | Transponder gate 2 | Day 1 | Day 0 | Signature
Ext. portal | Supplier portal, plant S | Day 5 | Day 0 | Confirmation
Distribution | Sales, Quotes | Day 1 | Day 0 | Log entry
The "Evidence" column decides whether this list later turns into a report
that holds up. A log entry is created by the system itself, a signature is
given by a person with a date, a confirmation comes back from the third
party. Without that third column, a leaver record is merely a claim.The list is created once per type of position, not per person. A field service technician needs different access from an order processing clerk, but two field service technicians need the same. Taking stock is therefore also the entry point into the role model, and the effort arises only once. Anyone drawing up the list for the first time should check it against the actual inventory: which accounts exist today, and which person does each one belong to? This comparison regularly brings to light accounts that can no longer be assigned to any active person.
Granting roles instead of individual rights
Individual rights arise from ad-hoc requests. Somebody needs a quick look at the order list, gets it, and the right stays. After three years and two department changes, that person holds a combination of rights that matches no job description any more and that no manager has a full view of either. The technical term is privilege accumulation; the result is an account that may do more than the task requires.
A role turns the logic around. It describes what a position needs, is formulated once and approved by the responsible manager. After that, granting is a single assignment instead of a collection of check marks - and therefore repeatable, auditable and, if in doubt, reversible. The international standard for information security explicitly requires access rights to be adjusted or removed upon a change of employment or termination (ISO/IEC 27001). The European NIS2 Directive names access control policies and the use of multi-factor authentication among the minimum requirements for the entities in scope (NIS2 Directive).
The most important moment in a role model is the department change, not the departure. When someone leaves, everything falls away, which is simple. When someone moves, the old role has to be removed before the new one takes effect - and precisely this step gets skipped, because the person still needs the old rights in the first few weeks to answer questions. The clean solution is a time-limited transitional authorisation with an expiry date, not a permanent coexistence of both. Where machine access, keys and certificates between systems are concerned, different rules apply; those are covered in the article on security for interfaces.
One base role for everyone
Sign-in, mailbox, time tracking, intranet: what every person needs sits in a single base role. It is assigned on joining and does not have to be discussed afresh each time.
One role per position
Sales, purchasing, workshop, accounting: each position gets a role with the rights the task requires. Two people in the same position receive the same role.
Extra rights with an expiry date
Cover, project, special case: anything beyond the position role gets an end date. Once it expires, the right lapses without further action and without a reminder.
A move revokes first
When someone changes department, the old role is removed and the new one granted afterwards. This order prevents rights from quietly adding up over the years.
Two approvals for critical roles
Payment release, master data maintenance, user administration: the group allowed to grant such roles is kept narrow, and each grant is confirmed by two people.
Every role is described
Each role comes with a sentence in plain language stating what it permits and who approves it. Without that description, the later evidence is hard to produce.
The triggered workflow: the HR system gives the signal
Joining, moving and leaving are recorded in the HR system anyway as a record: name, position, department, start date and, where applicable, leaving date. That record is the natural trigger. Instead of writing an email that has to be read, the HR system reports the change to the directory service, and the dependent systems follow from there. Technically this is an interface with a clearly described record and a set of rules; organisationally it is the decision that the HR department is the leading source for personal data. How a dependable workflow is built from that is described under process automation.
Step 1: The trigger arises in the HR system
As soon as a joiner, a move or a leaver is recorded, a record with a date and a position is available. It is the only permitted starting point; word of mouth and emails do not replace it, but at most supplement it for special cases.
Step 2: The directory service creates or locks
The role follows from the position and department, the rights follow from the role. The account is created a few days before the first working day but becomes active only on that date. On departure it is locked at the end of the last working day, not deleted.
Step 3: The dependent systems follow
Mailbox, business software, time tracking and file storage take their state from the directory service. Systems without an interface receive a task with a deadline instead, so that they do not slip through the cracks.
Step 4: Manual work becomes a signed-off task
Devices, keys and access held with third parties cannot be triggered, but they can be managed. Each item becomes a task with an owner and a deadline; it counts as done with a signature, not with good intentions.
Step 5: The closure is checked
On the day after the departure, someone reads back over it: which tasks are still open, which accounts are still active? Open points go to the manager, not onto a list that no one reads. Only then does the case count as closed.
As soon as a joiner, a move or a leaver is recorded, a record with a date and a position is available. It is the only permitted starting point; word of mouth and emails do not replace it, but at most supplement it for special cases.
The role follows from the position and department, the rights follow from the role. The account is created a few days before the first working day but becomes active only on that date. On departure it is locked at the end of the last working day, not deleted.
Mailbox, business software, time tracking and file storage take their state from the directory service. Systems without an interface receive a task with a deadline instead, so that they do not slip through the cracks.
Devices, keys and access held with third parties cannot be triggered, but they can be managed. Each item becomes a task with an owner and a deadline; it counts as done with a signature, not with good intentions.
On the day after the departure, someone reads back over it: which tasks are still open, which accounts are still active? Open points go to the manager, not onto a list that no one reads. Only then does the case count as closed.
The benefit shows in both directions. On the first working day a fully prepared workstation is ready, which noticeably shortens the onboarding and gives the new colleague the feeling of having been expected. On the last working day, access ends at the agreed moment without anyone having to remember it. If new business software is on the agenda anyway, the questions of roles, interfaces and revoking rights belong straight into the requirements document - what that looks like is shown in the article on choosing business software.
Arranging cover and mailbox handover
A locked account is half the job; the other half is the question of what happens to the work in progress. A mailbox holds open quotes, confirmed appointments, complaints and customer questions, and none of them know about the lock. The common improvisation is to simply hand a colleague the password. That solves the problem for a day and creates a new one: the access cannot be traced, and personal content is passed on without a proper basis. The General Data Protection Regulation requires appropriate technical and organisational measures for processing (GDPR); a shared password is not among them. Which obligations apply in day-to-day project work is set out in the article on data protection when digitising processes.
| Situation | Arranged handover | Improvised stopgap |
|---|---|---|
| Access to the mailbox | Sharing for a named person, logged and time-limited | The password is passed on verbally |
| Incoming messages | Automatic reply with a new contact, forwarding with a deadline | Messages go nowhere or are found by chance |
| Open cases | Handover list with status and owner before the last day | Reconstruction from the mailbox after the departure |
| Calendar and appointments | Appointments are transferred, recurring ones reassigned | Appointments lapse with the account |
| Traceability | Who accessed what and when is in the log | The access cannot be attributed to any person afterwards |
| End of the arrangement | The sharing ends on the defined date | The sharing persists until it is noticed by chance |
The difference lies less in the effort than in the timing. A handover list drawn up two weeks before the last working day costs an hour. Reconstructing the same list from a locked mailbox after the departure costs days and stays incomplete. This is particularly visible in sales, where open quotes hang on individual people: how quotes and follow-up can be organised independently of a single mailbox is covered in the article on quotes and consistent follow-up. The same pattern applies to approvals - a stored deputy prevents a case from stalling on an absent person; the implementation is described in the article on digitising approval workflows.
Lock, retain, delete: three steps, three deadlines
These three words are often used interchangeably but mean different things. Locking means: the sign-in fails, the data stays. This happens at the end of the last working day, immediately and without discussion. Retaining means: content remains accessible, but not to the person who has left - business transactions, receipts and correspondence are subject to commercial and tax retention periods that have nothing to do with the employment relationship. Deleting means: the account and the personal data disappear as soon as neither a purpose nor a deadline stands in the way.
The General Data Protection Regulation requires personal data to be kept in an identifiable form only for as long as is necessary for the purpose (GDPR), and grants data subjects a right to erasure under certain conditions (GDPR). Both stand in tension with retention obligations, and that tension can be resolved only with a written concept: one deadline, one trigger and one responsible unit per type of data. Which periods apply to which documents and what a deletion run looks like technically is covered in the article on retention periods and deletion runs. For the joiner and leaver workflow, a simple rule is enough to start with: lock on day zero, review after thirty days, delete once the respective period has elapsed.
Employee data: settle co-determination early
A second, often overlooked point concerns the order of events in short-notice separations. If an employment relationship is terminated without notice, the lock should happen at the same time as the conversation, not afterwards. That presupposes that a named person can trigger the lock without waiting for the regular workflow - a special route that should be described, kept narrow and logged. Without it, a gap opens up in exactly the situation where it is least helpful.
The annual access review that auditors want to see
Granting roles cleanly is half the work. The other half is the evidence that it has stayed that way. Once a year - more often for critical roles - each manager receives a list of their staff with the assigned roles and either confirms or strikes out entries. This review is unspectacular and takes half an hour per department, but it is the document that gets asked for in an audit. The IT baseline protection standard treats regular checks of authorisations as a fixed part of access management (BSI), and the international standard requires a regular review of access rights (ISO/IEC 27001).
- The basis is a reconciliation, not a gut feeling: the list of active accounts against the list of active employment relationships. Every line without a counterpart is a finding that needs an explanation.
- Confirmation comes from the responsible manager, not from IT. IT supplies the list and implements the outcome; the professional judgement sits where the task is known.
- Critical roles are shown separately: user administration, payment release, master data maintenance, access to HR data. For these, a shorter cycle is appropriate.
- Time-limited extra rights appear with their expiry date. Anything expired should no longer be on the list at all - if it still appears, the time limit is not technically effective.
- Every deletion creates a task with a deadline and a log entry. Without that return path, the review remains an exercise without effect.
- The outcome is filed as a document: reference date, scope, findings, changes initiated. This is precisely the document presented in an audit.
The review is worthwhile even without audit pressure, because it keeps the workflow alive. A role model ages quietly: departments are renamed, tasks shift, new systems arrive. The annual round is the appointment at which this becomes visible. Anyone who would rather not tie up the maintenance in-house on a permanent basis can assign it as part of operations and maintenance. And because the same details are needed for the process documentation required by auditors, it pays to do both in one go - how that is structured is shown in the article on process documentation for audits. For entities in scope of the NIS2 Directive there is the additional point that a significant incident must be reported as an early warning within 24 hours (NIS2 Directive) and as a notification within 72 hours (NIS2 Directive) - anyone who has to work out who held which rights in that situation loses the decisive hours.
One reconciliation is enough to start
Where a company starts
The path from today's state to a triggered workflow can be split into manageable steps. The order matters: first know what exists, then put it in order, then automate. Anyone who starts with the technology automates the existing disorder and is surprised that the report comes out longer than before.
- Set a reference date and pull two lists: active accounts from the directory service, active employment relationships from the HR system. The discrepancy is the initial finding.
- Draw up the access list per type of position: systems, mailboxes, distribution lists, devices, keys, external portals. Five to ten types of position cover the greater part in mid-sized businesses.
- Form roles from the most common types of position and define who approves each role. One base role for everyone plus one role per task is enough to begin with.
- Settle the trigger: which system leads on personal data, which fields are handed over, at what interval? Without that decision the workflow stays email-driven.
- Automate the leaver first, not the joiner. It is the quiet part and therefore the one where automation makes the biggest difference.
- Schedule the first access review before the workflow is finished. A fixed date in the calendar makes sure the maintenance happens even after the project has long been closed.
An account that can no longer be assigned to any person is one of the few risks that can be found in a morning and removed in a week. The effort is small, the effect lasts - and the evidence for it is then within easy reach.
The joiner and leaver workflow is one of those processes that rarely appear on a priority list and still cost time and nerves on a regular basis. It touches the HR department, IT and the operating departments alike, and precisely for that reason it falls between the areas of responsibility. A review of the existing state - as described in how a process analysis works - creates the basis for deciding what gets automated and what deliberately stays manual.
Sources and Studies
Related Articles
Interface security: accounts, keys and permissions
Sign-in, key handling, encryption in transit, minimal permissions, separate test accounts and key rotation: what to settle for every interface you run.
Cyber Resilience Act: a reporting process in 24 hours
From 11 September 2026 the reporting duty in Article 14 applies. Who reports to whom, what happens in the first 24 hours and which records remain at the end.
AI in back-office work: the routine it takes off your desk
Concrete, not hype: which back-office routines AI reliably prepares in 2026 - sorting mail, classifying enquiries, reading receipts - and where people decide.