Two problems that turned out to be one
The group arrived with what looked like two separate programmes on the table.
One was SAP: the critical system, whose authorisation model had become impossible to describe and whose segregation-of-duties conflicts the auditors kept raising. The other was identity data: employees in one system, contractors in another, supplier engineers in a third, and a long tail of accounts belonging to nobody in particular.
They were treated as one piece of work, because they are. A role model rebuilt on top of identity data nobody trusts is a spreadsheet exercise that drifts back within a year, and clean identity data that ends where the important system begins answers none of the questions being asked.
The system that mattered most
SAP was the critical resource: purchasing, payments, production planning, the master data the plants run on. It was also the system where an access question took longest to answer, and where the consequences of getting it wrong were measured in money rather than in inconvenience.
It had been in place for years, and its authorisation model had grown the way these models always grow — one request at a time.
How the role model had drifted
Nobody designed the situation the programme found. It accumulated.
A new person joined and needed to do roughly what a colleague did, so their profile was copied. A project needed a narrow permission that no existing role carried, so a role was created for it, named after the project, and never retired when the project ended. A plant needed a local variation, so a derived role appeared. Multiply that by a decade and several sites, and you arrive at the state the review documented:
- Roles that described a person rather than a job. Several carried the name of the employee they had originally been built for, including people who had since left.
- Roles nobody could describe. Understanding what one actually granted meant reading its authorisation objects, which meant asking the two people who could.
- Roles that overlapped almost entirely. Near-duplicates differing by a single transaction, maintained separately, drifting further apart with every change.
- Growth that only went one way. Roles were added constantly and removed almost never, because removing one risked breaking somebody and nobody could prove it would not.
The practical effect was that the access request process had stopped being a decision. An approver presented with a request for a role they cannot describe approves it, because refusing means blocking a colleague on a suspicion.
The other half: nobody could say who the people were
Rebuilding roles around jobs requires knowing who does which job. That turned out to be the harder question.
Employees were in the HR system and reasonably well described. Everyone else was not. Contractors lived in a procurement register that IT did not read. Supplier engineers with site access existed in the plant access system and nowhere else. Service accounts created during projects that had ended years earlier had no owner at all, and several of them held SAP authorisations.
So the same person could exist three times, under three spellings, with no way to know it was one person — and an account in SAP could not reliably be traced back to a human being with a manager and an end date.
Collecting and reconciling
The identity layer was built first, from the systems that actually held the data rather than from the ones that were supposed to.
Connectors were configured against HR, the contractor register, the plant access system and the supplier portal, alongside SAP and the other target systems. Matching rules resolved the same person appearing under different spellings into one identity, with an owner and a lifecycle.
Reconciliation is the part that makes this durable. Rather than a picture that was accurate once, at go-live, the platform reads back what exists in the target systems and compares it with what should exist: accounts that appeared outside the process, accounts whose owner has left, entitlements granted directly rather than through a role. Scheduled alignment turns those from discoveries into a worklist.
Rebuilding the role model
Only then did the role work begin, and it started from what people actually held rather than from a diagram of what they should hold. Entitlements were collected from SAP alongside the other connected systems, and the picture was analysed for the patterns already present: which combinations recurred across a job, which were genuinely unique, and which existed only because somebody had once been copied.
From that, roles were rebuilt around jobs. Business roles express what a person does — buyer, plant maintenance planner, accounts payable clerk — and carry the technical entitlements underneath, in SAP and in everything else the job touches. The distinction matters: the person requesting access, and the manager approving it, now read a role name that means something in their language rather than one that means something in SAP’s.
Roles created for a project or a person were retired rather than inherited into the new model. Where a plant-specific variation was genuine it stayed, declared as such; where it existed because of a copy made years earlier, it did not survive the exercise.
Segregation of duties, enforced rather than reported
Rebuilding the roles made the second problem visible, and it was the one the auditors had been raising.
Segregation of duties is the rule that the same person must not hold two capabilities whose combination lets them act unchecked. In an SAP estate the classic pairs are well known and expensive:
- Create or modify a vendor, and release a payment to it.
- Raise a purchase order, and approve it.
- Change bank details on a master record, and authorise the transfer.
- Post a journal entry, and approve the posting.
Conflicts like these had been detected before, in periodic reviews, weeks or months after the combination had been granted. Detection after the fact is evidence of a control failure, not a control.
The ruleset was defined explicitly and applied in two places. Preventively, at the moment of request: a combination that would create a conflict is caught before it is granted, and the requester and approver are told which existing entitlement it clashes with — not merely that the request was refused. Detectively, across what people already held, so conflicts predating the programme were surfaced, ranked and worked through rather than rediscovered at each audit.
Where a conflict cannot be avoided — small teams and remote sites are the recurring case — the exception is recorded as an exception, with an owner, an expiry date and the compensating control that justifies it. That is a defensible answer to an auditor. An undocumented conflict is not.
Why the two halves need each other
This is the part worth stating plainly, because it is the lesson the programme actually produced.
Identity data makes the role model enforceable. A segregation-of-duties rule is a statement about a person holding two things. If the same human exists three times under three spellings, the rule is trivially defeated — not maliciously, just by accident. Only once the contractor in the procurement register and the SAP account were known to be the same identity did the conflict become detectable at all.
The role model makes reconciliation meaningful. Reading back what exists in SAP is only useful if there is something to compare it with. Before the roles were rebuilt, a reconciliation report was a list of authorisations with no expected state to check them against. Afterwards, the same report answers a question: this person holds an entitlement their role does not carry — who granted it, and when?
The mover is where both meet. A transfer that adds a plant role without removing the previous one is how an SoD conflict is created in the first place. Catching it requires the lifecycle event from the source system, the role model to know what should change, and the SoD ruleset to know what the combination would produce. Any one of the three on its own would have missed it.
Certification that produces a decision
Campaigns were then scoped by risk and by what had changed, instead of running against everyone every quarter. A reviewer receives the access that is new, the access carrying a conflict, and the access nobody has used — with the role expressed in business language and the reason it is being asked about stated on the line.
That is the difference between a campaign that produces decisions and one that produces a completed checkbox.
What changed
- One identity per person, resolved across HR, the contractor register, the plant access system and the supplier portal.
- Reconciliation runs on a schedule, so accounts appearing outside the process are found rather than discovered at audit.
- SAP roles describe jobs, not the people or projects they were originally cloned for.
- Segregation of duties is enforced at request time, with the conflicting entitlement named, rather than reported months later.
- Pre-existing conflicts were surfaced and worked through, and those that remain are documented exceptions with owners and expiry dates.
- Approvers can describe what they are approving, which is what turns an approval back into a decision.
- Contractor access ends on the contract end date, because the date lives in the source system and the source system is now read.
Where to go next
The mechanics are described in Joiner / Mover / Leaver automation, the collection layer in Connectors, and the governance capabilities — role and policy management, segregation of duties, certification — on the Identity Governance page.