SyteLine security audit checklist

Short answer

A SyteLine security audit is mostly about access you didn't mean to grant. List every active user and remove leavers and shared logins. Check who has Super User or developer-level rights, and why. Review what each group is authorized to open, especially the Users form and other administration forms. Confirm the Password Parameters match your company policy. Then test the login and password screens yourself as an ordinary user, including the forgot-password and change-password options, and confirm they behave the way your policy says they should. Settings that look right on paper don't always behave the way you expect.

Why SyteLine security drifts

Nobody sets out to give a warehouse user administrator rights. It happens gradually:

A user is added to a powerful group "temporarily" to fix one problem, and never taken out.
Someone leaves, and their account stays active because nobody told IT.
A shared "shipping" or "scanner" login is created for convenience, and now nobody knows who did what.
An upgrade adds new forms, and existing groups pick up access nobody reviewed.

An annual audit catches this drift. Before an upgrade, a migration, or an external audit is the best time to do one.

The checklist

1. Users: who is in the system at all

Export the list of active users from the Users form and check it against a current staff list from HR:

Leavers. Any active account for someone who has left should be disabled straight away.
Shared or generic accounts. Each one should have a named owner and a reason. Where possible, replace them with named accounts.
Never-used accounts. Accounts created but never logged into are easy targets and can usually go.
Test and consultant accounts. Implementation partners and contractors often leave accounts behind. Yours included: when a contractor's work ends, their account should end too.

2. Super User and developer rights

These are the keys to everything. List every user with Super User status or developer-level editing rights, and for each one, write down why. In most businesses the honest list is very short: the system administrator and one backup. Everyone else who has these rights for convenience should have them removed, with the specific access they actually need granted through a group.

3. Groups and authorizations

SyteLine controls access mainly through groups, with authorizations set for each group, plus permissions at the user level. Review each group:

What does the group exist for? If no one can say, it's a candidate for removal.
Who is in it? Look for people whose job no longer matches.
What can it open, and what can it change? Read access and edit access are different, so check both.

Pay particular attention to administration forms, above all the Users form. Any group that can open the Users form can potentially change other people's accounts. Only administrators should be in such a group.

4. Password Parameters

Open the Password Parameters form and compare each setting with your written password policy: length, complexity, expiry, reuse and lockout. If there's no written policy, this audit is a good reason to write one. If you sign in through Infor OS or another identity provider, check that policy instead, because that's what users actually go through.

5. Test the screens as a real user

This is the step most audits skip. It's also where surprises turn up.

Sign in as an ordinary user in a test environment, not as an administrator, and try the password-related options on the login and user screens yourself: forgot password, change password, and anything else the screen offers. For each one, ask:

Does it do exactly what your policy says, and nothing more?
Does it only ever affect the signed-in user's own account?
Is the change recorded somewhere an administrator can see?

If anything behaves differently from what you expected, don't publish or share the details. Restrict access in the meantime, and raise it with your Infor support contact or partner, who can confirm whether it's configuration or something that needs a fix.

6. Database and server access (on-premises)

SyteLine's permissions only protect access through SyteLine. Anyone with direct SQL access can read or change the data underneath, and that bypasses every rule above:

List every SQL login and Windows group with access to the SyteLine databases.
Reporting tools should use a read-only login.
Service accounts, such as the one TaskMan runs as, should have only what they need, and their passwords should be stored securely.
Remove access for anyone who no longer needs it, contractors included.

7. Record what you found

For each finding, write down the risk, the fix, who approved it, and the date. Next year's audit then starts from a known position, and you have something to show an external auditor.

How often

Leavers: immediately, as part of the leaving process, not the audit.
Full audit: once a year, and before any upgrade, migration or external audit.
Super User list: every quarter. It's short, so it takes five minutes.

FAQ

How do I audit user access in SyteLine?

List active users against HR's staff list, review who has Super User or developer rights, check each group's authorizations (especially for administration forms like Users), compare Password Parameters with your policy, and test the login and password screens as an ordinary user.

Who should have Super User rights in SyteLine?

Very few people, usually the system administrator and one backup, each with a documented reason.

Where are password rules set in SyteLine?

On the Password Parameters form, unless sign-in is handled by Infor OS or another identity provider, in which case that provider's policy applies.

What should I do if I find a security problem in SyteLine?

Restrict access straight away, don't share the details publicly, and raise it with Infor support or your partner to confirm whether it's configuration or a product issue.