Working with Access & Segregation of Duties

Access & Segregation of Duties reads who can do what in your finance systems, and what each person did there. It compares the user lists, roles and activity logs from those systems with your rules on who may do which job. Segregation of duties is the rule that certain pairs of jobs take two people, such as approving a payment and making it. It reports every occasion one person did two jobs that should take two, as a count of conflicts for the quarter. This page is how to work with it from day to day.

What to put in the Data Room

Two documents are enough to begin. Export the user list, with each person's roles, from your finance system, such as Xero. Export the log of who did what and when, which the system may call its audit log or its history. Add both with Add to Data Room, as PDFs; one user list and one log covering the same quarter produce a first finding. These documents sit beside Contracts and Agreements and Invoices as their own kind, and the module's Data Room tab lists them under Access and change logs.

Add the remaining documents as you have them, because each one lets another check finish. Your employee list with leaving dates lets the module see whether someone who has left still has access. Your segregation rules, the pairs of jobs one person should not do alone, and your approved exceptions can be typed as answers rather than added as documents. Without them the module starts from six standard pairs and says so in each finding. The same log lets it check that a change to a tax rate, an approval rule or a bank account had an approver.

No Connection brings user lists or logs in today, so add a fresh export whenever access changes and it is examined the same way as the first. Open the module's Data Room tab to see which documents it has drawn on and to link one it has not used yet. The Data Room explains where documents live and what each kind is for.

When it asks you a question

Access & Segregation of Duties asks you nothing when you add it. It asks a question only when a check needs the answer, and until then it uses a default and names it in the finding, so you can correct it when it matters. Five questions can arise: which two jobs should never be done by the same person, who is allowed to do both on purpose, who is allowed to be an admin in your finance systems, how many days without a login before an account is flagged, and how often you review who has access.

A question arrives as a needs-information finding in the Findings list, and as a card in Ask Ressura. Your answer becomes an entry in your Organisational context, with your name and the date on it, and the check runs again automatically. An exception you approve for one person, such as the Owner in a two-person company, applies to that person only. The pairs of jobs, the admin list, the number of days and the review rhythm apply to every user the module checks.

How to read a finding

The module's Overview shows Conflicts, a count rather than a sum of money. It counts the occasions in the quarter one person did two jobs your rules say take two, plus roles held together without an approved exception. Because it is a count, it does not join the money-found total for your company. The list of Users sits beneath it, with each one's roles, conflicts, last activity and the date their access was last reviewed. In a shared list a user appears by id, and admins and the Owner see the name. Its Findings tab lists every finding: the user, the Control that produced it, its kind, the amount where a payment carries one, the confidence, its disposition and the date. Choose Review finding to open one.

An exception says what the person did, what your rule says, and the difference between them. For a segregation conflict it names the two actions, their dates and the pair of jobs they break. For an approval over a limit it shows the amount approved against the most that person may approve. Its provenance shows the log rows, the roles held and the context entry that holds the rule, so you can check the reasoning yourself. It says what happened and never whether it was on purpose, and when it leans on a default rather than a value you gave, it says so explicitly.

A needs-information finding names the answer or the document that would let a check finish: a rule you have not given, the name behind a user id, whether an exception is approved, or the employee list with leaving dates. It never blocks the other checks. A fraud-risk finding comes from Fraud Watch and links the findings behind it. The Checks tab shows each of the seven Controls with its pass, exception and needs-information counts for the quarter.

How to disposition a finding

You answer a finding in one of three ways, and each answer is recorded with your name and the date. Accept an exception when it happened as described, and add a note if you like. One example is a person who set up a new supplier and approved its first payment with nobody else signing off. Reject it with the reason when the rule does not apply, such as the Owner doing both jobs in a two-person company on purpose. The reason becomes a context entry, scoped to this finding, this user, this module or the whole company, so the same point is never raised twice. Answer a needs-information finding by typing the answer, such as the names allowed to be admins, or by adding the document it asks for, such as the employee list with leaving dates. Either way the check runs again automatically.

A user's own page, under Users, gathers their findings, the documents they appear in and the context entries about them. Its header shows their roles, systems, last activity, approved exception and access review date. Findings and Dispositions has the rules every module shares, including the two-person rule for rejecting a fraud-risk finding.

What it costs

Running its checks, opening a finding and dispositioning one cost nothing, and checking the same documents again is free.

This page is the how-to. The Access & Segregation of Duties page says why it exists and what it checks.