⚖️ OasisPro · IFS Cloud Segregation of Duties · Access Governance · PermissionWorks
The control may exist.
Can you prove it does?
IFS Cloud segregation of duties findings rarely arise because somebody was negligent. They arise because of how the access model was built. Access granted by copying whoever seemed similar. Exceptions nobody can now explain. One bespoke permission set per person. Leavers whose access was never fully withdrawn because nobody was certain what removing it might break. None of that is misconduct, and all of it is undemonstrable.
That last point is what auditors actually record. A control you cannot evidence is treated as a control you do not have.
These are the 6 controls worth establishing, and the moment when establishing them is cheapest.
The clearest sign a model has stopped being understood is reluctance to remove access, in case something quietly breaks.
Every organisation has met this. A colleague leaves, or moves department, and their access lingers because nobody is confident about what depends on it. That hesitation is not a process failure, it is a legibility failure. Once nobody can reason about the model, segregation of duties becomes impossible to assert, regardless of how careful the original design was.
The 6 controls behind IFS Cloud segregation of duties
- 1. A legible role model. Roles that map recognisably to job functions, composed from reusable blocks. If access cannot be described in business terms, conflicts cannot be identified.
- 2. A documented conflict matrix. Write down which combinations are unacceptable in your business: supplier creation with payment approval, purchase order raising with goods receipt, journal posting with reconciliation.
- 3. Recorded intent per role. Not just what a role permits, but what it is meant to permit and why. Intent is what makes a later review possible at all.
- 4. A leaver and mover process that runs continuously. The gap between someone changing job and their access changing is where most findings originate. Annual cleanup does not close it.
- 5. An exception register with expiry dates. Temporary elevated access is legitimate. Temporary access that nobody revisits is how models drift. Give every exception an owner and an end date.
- 6. A formal review at least annually. Someone accountable confirms that assigned access still matches current job functions, with the output recorded rather than assumed.
Why the upgrade is the cheapest moment to fix this
Moving from IFS Applications 10 to IFS Cloud usually requires the access model to be rebuilt anyway, because the underlying mechanisms differ. Designing the new model around segregation of duties from the start adds very little to work you are already committed to. Retrofitting controls onto a model that has drifted for three years costs considerably more, and tends to happen under pressure.
Building IFS Cloud segregation of duties into the design
Start from the conflict matrix rather than from the permission sets. The combinations you will not allow shape the role boundaries.
Compose roles so that a conflicting pair cannot be satisfied by a single assignment, which is far easier to design in than to detect afterwards.
Test the conflicts explicitly, alongside the functional access testing, by attempting the combinations that should be impossible.
And record the result, because IFS Cloud segregation of duties is ultimately an evidence exercise as much as a configuration one.
The IFS documentation site covers permission set mechanics, and the IFS Community is where access governance approaches get compared in practice.
Our role design guide covers the modelling that has to come first.
A control you cannot demonstrate is recorded as a control you do not have, however carefully it was designed.
The conflicts worth writing down first
Every business has its own list, but a few combinations appear almost universally and are a sensible starting point.
Creating or amending a supplier record alongside approving payments to suppliers. This is the classic, and it is the one auditors ask about first.
Raising a purchase order alongside confirming goods receipt against it. Convenient in a small team, and precisely the convenience the control exists to prevent.
Posting journals alongside performing the reconciliation that would detect an error in them.
Amending master data such as prices or credit limits alongside processing the transactions those values govern.
Write your list before designing roles. IFS Cloud segregation of duties is far easier to build in than to detect afterwards.
When smaller organisations cannot fully segregate
Plenty of businesses do not have enough people to separate every conflicting pair, and pretending otherwise helps nobody.
The accepted answer is compensating controls: documented review by someone independent, exception reporting on the specific combinations, and a recorded rationale for why full separation is not practical.
What matters is that the position is deliberate and evidenced rather than accidental and undiscovered.
An auditor is generally far more comfortable with a documented compensating control than with a model nobody can explain.
Evidencing IFS Cloud segregation of duties to an auditor
Auditors are not asking you to prove nothing bad happened. They are asking you to show the control exists and operates.
That means producing the conflict matrix, the role model showing how access is composed, evidence that conflicting combinations were tested, and the record of your last access review.
A model built from reusable blocks can produce all four in an afternoon. A model of bespoke per-person permission sets cannot produce them at all.
That difference is the practical case for treating IFS Cloud segregation of duties as an architecture decision rather than a reporting exercise.
Where IFS Cloud segregation of duties usually breaks first
Not in the original design. In the year afterwards, through temporary access granted during a busy period and never withdrawn.
Through a restructure where people took on new duties and kept the old permissions alongside them.
And through the quiet accumulation of one-off exceptions, each reasonable on its own, none of them recorded together.
PermissionWorks makes the rebuild affordable enough to do properly.
Generating and validating permission sets from role definitions is repetitive volume work, and it is what makes a governance-led rebuild feel expensive. PermissionWorks removes roughly 80 percent of that manual effort so your team can spend its time on the conflict decisions that genuinely need judgement.
Where this fits in an Apps 10 upgradeNot confident your model would stand up to a question?
We will review your current access structure against a conflict matrix, tell you where the model is not legible enough to evidence control, and set out what rebuilding it during your upgrade would actually involve.
What is segregation of duties in IFS Cloud?
Segregation of duties means no single person can complete a sensitive process end to end without another party involved. In an ERP context that typically covers combinations such as creating a supplier and approving payments to it, or raising a purchase order and confirming its receipt. In IFS Cloud it is enforced through how permission sets and roles are composed.
Why do IFS access models fail segregation of duties checks?
Usually because the model is not legible. When access has been granted by copying colleagues, exceptions have accumulated, and one bespoke permission set exists per person, nobody can demonstrate which combinations are possible. The control may exist in practice and still be impossible to evidence, which is what auditors record.
How often should IFS Cloud access be reviewed?
At least annually as a formal exercise, with a lighter check whenever there is a significant restructure. Leavers and role changes should be handled continuously rather than at review time, because the gap between someone changing job and their access changing is where most findings originate.
Is an upgrade a good time to fix segregation of duties?
It is the best time. Moving from IFS Applications 10 to IFS Cloud frequently requires the access model to be rebuilt anyway, so the incremental cost of designing it around segregation of duties from the start is small. Retrofitting controls onto a model that has already drifted costs considerably more.
IFS Cloud segregation of duties is a design decision, not a cleanup exercise
Models that can demonstrate control were designed to be legible. Models that cannot were assembled, usually under time pressure, one exception at a time.
The distinction is set at design time and is expensive to reverse later.
If an upgrade is on your roadmap, that is the moment to make the decision deliberately.