Case study · Energy & industrial
One directory for a European operation spread across countries
The European arm of an international energy group ran offices in several countries and departments on a hybrid identity: a local directory synchronised to the cloud. Every arrival or departure crossed half a dozen tools. We designed the structure, wrote the procedures, built the asset inventory and ran support, so the operation kept working while it changed underneath.
In numbers
9
steps in one departure procedure, from directory to backup to endpoint
3
memberships every user carries at minimum: country, department, VPN
4
workstreams under one team: applications, infrastructure, services, migration
Who this is for
Directors and IT leads of multi-country operations running hybrid identity, where every arrival and departure crosses half a dozen systems and depends on who remembers the order. You will get the structure we documented, the nine-step lifecycle procedure, and the reason we wrote the organisation down before touching a single tool.
Key takeaways
- The tools were not the problem; the absence of a written model of how they related was.
- Structure first, policy second. Once the organisation appears in the directory, policies attach to it and are inherited instead of applied by hand.
- Written down, each step is a control. Before, it was a memory.
- Three memberships minimum: country, department, VPN. A rule that simple is what makes exceptions visible.
- The company now holds documentation of its own identity model. A new administrator can read it and act. So can an auditor.
Why does hybrid identity break when a company grows across countries?
Each piece was fine; together they were the problem
An energy and infrastructure group had built a European organisation quickly: offices in several countries, teams organised by country and department, people who travel between them. Its technology was what a fast-growing corporate operation usually has: an on-premises directory synchronised to the cloud, Microsoft 365 for mail and files, VPN for remote access, endpoint protection, a backup of mail and files, and a digital business-card service. Each was fine. Together they were the problem.
What a single new hire actually cost
A new hire meant creating the person in the directory, placing them in the right country, department and access groups, waiting for the synchronisation, licensing mail and files, enrolling the laptop, protecting it, adding VPN, and issuing the business card. A departure meant undoing all of it, in the right order, without losing the data the company had to keep. With no written model of how the pieces related, every one of those steps depended on who did it and what they remembered.
No reliable view of assets, and a website with no owner
There was no reliable view of assets: which laptops existed, who held them, which applications mattered and who owned them. And the corporate website had to leave its hosting provider, with no clear owner for what would come after.
We did not start with a tool
We didn't start with a tool. We started by writing down how the organisation is structured: the countries, cities and departments, the people who move between them, and how each of that half-dozen tools touched the others.
How should an organisation appear inside its own directory?
Then we decided how that structure should appear in the directory: the units for countries, cities and departments, the groups that grant access, the naming convention that makes a group's purpose readable at a glance, and the exceptions. Once that model existed, policies could be attached to it and inherited instead of applied by hand.
- A documented directory structure: organisational units, global, departmental and geographic groups, and the rule that every user belongs at minimum to a country, a department and a VPN group.
- Group policy design with inheritance, filtering and explicit exceptions, so a rule applies where it should and is visible where it doesn't.
- One lifecycle procedure for people and devices, from directory to cloud to backup to endpoint, in nine steps, each with a check.
The website migration was planned as a project with an owner rather than a ticket.
What does a nine-step departure procedure look like?
The departure procedure, as it runs: disable the account, move it, strip its groups, re-home the device, force the synchronisation, confirm the cloud block, confirm the last backup of mail and files, retire the business card, keep the device protected until reuse. Written down, each step is a control. Before, it was a memory.
- Disable the account
- Move it
- Strip its groups
- Re-home the device
- Force the synchronisation
- Confirm the cloud block
- Confirm the last backup of mail and files
- Retire the business card
- Keep the device protected until reuse
An asset and service inventory in the service desk's own asset module: device types, serials, models, relationships and owners, imported from spreadsheets and kept to one naming convention.
Four workstreams (applications, infrastructure, services and migration) under one team and one way of documenting, so the operation kept working while it changed underneath.
What has held?
Arrivals and departures became a procedure anyone on the team can run and audit.
| Before | After | |
|---|---|---|
| Who knew the steps | Whoever did them, from memory | Anyone on the team, from the written procedure |
| The order | Depended on the person | Nine steps, each with a check |
| The assets | No reliable view of laptops, holders or owners | An inventory with owners and one naming convention |
The company holds documentation of its own identity model for the first time: how it's structured, why, and how to change it. A new administrator can read it and act. So can an auditor.
Support ran through one service desk, with request states, priorities and escalation written down, so a VPN access ticket and a new-laptop request follow the same path and leave the same record.
Questions readers ask
Customer Success Team
Itaca Technologies
Your question isn't here?
Ask it as you'd ask it across the table. The team that does the work reads it and answers with a concrete next step.