Deutsch (Deutschland) 
Polski (PL) 
Independent IFS Cloud practice · Security
An IFS Cloud user access review that leaves an evidence trail an auditor can follow, and your team can repeat
Key takeaways
- A user access review compares the permission sets each person holds with what their job needs today, and a role owner in the business confirms or rejects every line.
- ISO/IEC 27001:2022 control A.5.18 requires access rights to be reviewed but names no interval, so your access policy sets the frequency.
- Five steps cover a review: fix the scope and freeze a snapshot, match it to the HR list, collect owner decisions, execute changes through your change process, and file the evidence.
- The accounts that escape review are the ones nobody is assigned to report: leavers, movers, integrations and administrators.
- An auditor tests the evidence trail, not your intentions: who decided, when, on what list, and which change request carried it out.
A user access review in IFS Cloud is a periodic comparison between the permission sets each user holds and the access that person’s job needs, confirmed by the owner of the role and recorded as evidence. Without that record, the same finding returns at every audit: someone left in March and could still post journals in June, and nobody can show who last looked.
One complete review covers preparation, five steps, the accounts people forget, the findings and the auditor’s evidence.
1.What is a user access review in IFS Cloud?
Access in IFS Cloud comes from permission sets granted to users, so a review is a check of those grants against current need. It answers one question per person: does this individual still require every set they hold?
Review versus design
Design decides which permission sets exist and which combinations are allowed. A review tests whether reality still matches that design. If your sets are badly cut, a review will only expose the damage, so fix the model first with permission set design in IFS Cloud and the conflict matrix in RBAC and Segregation of Duties in IFS Cloud. This article does not repeat either.
What the standard asks for
ISO/IEC 27001:2022 Annex A control 5.18, “Access rights”, covers the whole life of an access right: provision, review, modification and removal. The control requires that rights are reviewed, and it gives no number of days or months. The interval is your decision, written into your access policy and then followed. The standard itself is listed on the ISO catalogue page for ISO/IEC 27001.
2.What do you need before you start?
A review stalls when one of its inputs is missing on the day the owners are asked to decide. Gather these first:
- Access policy. It states the review interval, who may approve access and how exceptions are handled.
- Role catalogue. Each permission set has a plain-language description of what it allows a person to do.
- Current HR list. It shows every active employee and contractor, with department, manager and job title.
- Named role owners. One business person per role or process area, with a deputy for absences.
- A deadline for answers. An open-ended request gets the slowest owner’s timetable.
3.How do you run the review, step by step?
One review needs five steps in a fixed order, because each step produces the document the next one consumes.
- Fix the scope and freeze a snapshot. Export the list of users and the permission sets granted to each, and save it with the date. Decisions are taken against this file, so later grants do not shift the ground under the owners.
- Match the snapshot to the HR list. Every IFS user needs a matching active person. Accounts with no match are leavers, shared logins or integrations, and each one needs an explanation.
- Send each owner their slice. The role owner marks every line as keep, reduce or remove. Silence is not approval, so chase the gaps until the file is complete.
- Carry out the decisions through your change process. IT removes or reduces access against a ticket. The ticket number goes back into the review file.
- Close with evidence. Store the snapshot, the owner decisions, the ticket references and a short sign-off with a date.
| Step | Who | Evidence it leaves |
|---|---|---|
| Scope and snapshot | IT or security manager with the IFS administrator | Dated export of users and permission sets |
| Match to HR list | IT with HR | List of unmatched accounts with explanations |
| Owner decisions | Role owners | Keep, reduce or remove marked on each line |
| Execute changes | IT | Change tickets referenced in the file |
| Close | IT or security manager | Signed and dated summary filed with the above |
Asking IT to approve access it granted itself turns the review into a formality, which is why step 3 sits with the business and step 4 with IT.
4.Which accounts do people forget?
Leavers, movers and joiners
A leaver keeps access until someone disables the account, and that someone is only told if HR and IT have a working hand-over. A mover is harder: the accountant who joins purchasing takes on new permission sets and keeps the old ones, since nobody is assigned to remove them. Joiners create the third gap. Say a manager asks for “the same access as Anna”: the new account inherits everything Anna has accumulated over the years, including sets she should have lost after her own move. Compare each new account with the role catalogue, not with a colleague.
Service and integration accounts
A service account is a login used by software, so no person sits behind it to notice a surplus right. It needs a named owner, a written reason, and the smallest permission set the integration can work with. A monitoring or reporting integration should hold read access only, one account per integration, so that revoking one cannot break another. This is also how the read-only account for the OData monitoring approach is set up, and it is the account model behind the SCM Automation Pack, which reads IFS and writes nothing into it.
Privileged and administrator accounts
An administrator account can grant itself anything, so a mistake in its sets costs more than an error on a clerk’s login. Review these more often than ordinary users. Quarterly is a sensible working practice for privileged accounts against an annual cycle for everyone else, though that is a choice to write into your policy, not a requirement of the standard.
5.What do you do with the findings?
Every finding ends in one of three outcomes: the access is removed, reduced to a narrower permission set, or kept as a documented exception. Removal and reduction run through a change ticket so the action can be traced.
An exception is for the case where a conflict in duties cannot be removed. A small team may need one person to create suppliers and approve their invoices, for example. The exception then carries a compensating control, such as a second person approving those invoices, plus a named owner and a date on which it is looked at again. An exception with no review date is a permanent grant under a different name. Conflicts that appear repeatedly point at the role design, and the matrix in the RBAC and SoD article is where to resolve them.
6.What does an auditor want to see?
An auditor wants proof that the review happened as your policy describes, and will sample it. The file should let them follow one user from the snapshot to the final outcome without asking anyone for help:
- The access policy with the review interval.
- The scope: which systems, companies and account types were included.
- The dated snapshot of users and permission sets.
- The owner’s decision for each line, with name and date.
- Change ticket references for every removal or reduction.
- The list of exceptions with their compensating controls and review dates.
Whether the control meets a standard is for the auditor or certification body to judge. A consultant can prepare the role model and the procedure; the evidence comes from your own review.
7.How do you make the next review cheaper?
The first review is slow because roles are undocumented and owners are unnamed. Once permission sets map to documented roles, each with an owner, the next review shrinks to confirming a list that is mostly unchanged. The effort moves from discovery to a short decision round.
A repeatable procedure also removes the dependency on whoever ran the last one. If the steps, templates and evidence format are written down, your own finance or IT team can run the review without outside help. That is the outcome of the IFS Cloud Security and SoD service: a role model plus an access review procedure your team repeats unaided.
Book a 30-minute technical call See the Security and SoD service
8.Frequently asked questions
How often should you run a user access review in IFS Cloud?
The interval is set by your own access policy, because ISO/IEC 27001:2022 control A.5.18 requires reviews but names no frequency. One workable arrangement is an annual review of ordinary users and a quarterly one for administrator and other privileged accounts, with an extra check whenever someone changes role.
Who should approve access in a review: IT or the business?
The business owner of the role approves, and IT carries out the resulting changes. The owner knows what the job requires, whereas IT knows only what was requested. Separating the two also prevents the team that grants access from certifying its own work.
How do you list who has which permission set in IFS Cloud?
An IFS administrator exports the users with the permission sets granted to each, using the security administration features of your IFS Cloud release. Save the export with its date as the review snapshot. The screen names differ between releases, so confirm the route on your own version before the first review.
What evidence does an auditor expect from an access review?
An auditor expects the access policy, the scope, the dated list of users and permission sets, the owner’s decision for each line with name and date, and the change ticket for every removal. Documented exceptions with compensating controls and review dates complete the file.
Does the access review cover service and integration accounts?
Yes, an IFS access review includes service and integration accounts, since software logins hold permission sets like any user. Each needs a named owner, a recorded reason and the smallest permission set that works. An integration that only reads data should hold read-only access.
9.About the author
Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally. You talk to the consultant who builds the role model, not a sales layer.
Selected clients across my IFS work: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Prepare for the next audit question
If you have been asked to review user access in IFS Cloud and are unsure where the scope should end, bring your current permission sets to a 30-minute technical call. There is no sales pitch; you talk to the consultant who writes the procedure.
