Pronto Xi User Access Review: Permissions, Approvals and Segregation of Duties

Can anyone change sensitive financial data and complete the resulting transaction without independent oversight? If you remove that access, can the person still perform their legitimate work?

These are useful starting questions for CFOs, CIOs and IT leaders reviewing Pronto Xi access.

A Pronto Xi user access review checks whether each person or service has authorised access appropriate to its current duties, and whether combined permissions create unacceptable risk. It covers business actions, company scope and approval authority across relevant roles, accounts and connected systems.

The management task is to identify consequential access, decide what should change and verify the result. Business value comes from stronger controls, more efficient administration and reliable operations. Financial savings require separate evidence.

This article provides a recommended framework, not an official Pronto procedure. A qualified Pronto specialist should validate configuration and testing against your version, modules, customisations and deployment.

What evidence should a Pronto Xi access review produce?

An access review should produce a reconciled account inventory, an assessment of effective business actions, documented conflict decisions, verified access changes and a register of accepted exceptions. Its conclusions should identify the systems and companies covered, the review date, exclusions and unresolved findings.

Management should receive answers to five questions:

An approved username list is an input to this work. The outcome depends on what those accounts can actually do and whether remediation has been verified.

What Pronto Xi documentation establishes

Pronto Software’s Pronto Xi 780 Core Platform overview describes role-based security that can restrict access by company, module and functions within screens. It also describes multiple role assignments, custom roles, data masking and configurable auditing.[1]

These capabilities provide a starting point for assessment. Their availability and operation in your installation need validation; the documentation does not establish that your permissions or approval processes are configured appropriately.

Ask the specialist to explain how overlapping roles, broad permissions, custom functions and alternative update routes affect access in your environment.

Review actual business capability. A role’s name alone does not establish what its holder can do.

1. Define the review boundary and accountable owners

Agree the scope before collecting evidence. Otherwise, a review may appear complete while omitting a payment platform, integration account or company directory.

Changes after the snapshot may affect the conclusion. Record relevant access changes during the review and confirm the final state before closing affected findings.

Assign responsibilities explicitly:

• Business and process owners approve required duties, data access and company scope.
• Finance owners approve financial authority within the organisation’s delegation rules.
• HR, managers and service owners confirm employment, contractor status and non-human account ownership.
• Pronto specialists interpret permissions and validate how configuration implements decisions.
• Authorised administrators implement changes; an independent reviewer verifies sensitive changes where practicable.
• Accountable executives accept residual risk within their authority.
• The ERP or IT service owner coordinates the review and tracks closure.

Administrators should not approve their own elevated access. Where staffing limits separation, document the limitation and assign independent oversight.

2. Reconcile accounts and establish effective access

Reconcile system accounts against current personnel, contractor, supplier and service records. Investigate unexplained accounts and ownership gaps.

Include named users, administrators, emergency accounts, vendor support, integrations, scheduled jobs, shared accounts and relevant reporting or database access.

For each account, record its owner, purpose, status, scope, permissions, approval evidence and any expiry date. Link multiple accounts belonging to the same person.

A service account may run a critical integration without interactive login activity. Confirm dependencies before disabling it. Likewise, low usage alone does not prove that an employee’s access is unnecessary.

The Australian Cyber Security Centre describes least privilege as limiting access to what is needed for duties.[2] Apply that principle to the business task and the person’s current responsibilities.

Translate technical access into business actions

For each person or service, establish whether it can:

• View or export sensitive information.
• Create, amend, approve, post or reverse relevant transactions.
• Change sensitive master data, approval limits or workflow rules.
• Grant access or alter security settings.
• Achieve the same outcome through another account, import, API or privileged route.

Review combined access across roles and systems. Pay particular attention to employees who have changed jobs but retained previous permissions.

The following illustrative record shows how to make the assessment understandable to a business owner. It is not a description of default Pronto behaviour.

This record connects technical permissions to a decision. It also makes clear where a control operates outside Pronto Xi.

3. Prioritise findings by consequence and existing controls

Start where inappropriate access could have the greatest business impact. Payment-related changes, financial approvals, sensitive data, privileged administration and external access are useful areas to consider first.

Use the following proposed assessment method to rank findings within your organisation:

Set remediation deadlines through your own risk and change processes. These considerations do not establish universal severity ratings or Pronto-mandated deadlines.

Where exposure needs urgent containment, use the appropriate incident or emergency-change process. For routine remediation, assess dependencies and operational timing before making changes.

4. Test approval authority and segregation of duties

Permission to open a function, authority to approve a transaction and permission to change approval rules are separate matters.

For relevant approval processes, check company scope, limits, currency, self-approval, temporary delegation, overrides and changes made after approval. Establish who can alter the rules and what evidence records those changes.

A written delegation matrix describes policy. Testing establishes whether the applicable system or procedure enforces it.

Which duty combinations deserve attention?

Segregation of duties aims to prevent one person from completing incompatible activities without effective independent oversight. These combinations are prompts for assessment, rather than declarations that every instance is unacceptable:

Assess company scope and the full process. Preparing a payment file in Pronto and releasing funds through a bank portal are different activities. Two usernames controlled by the same person do not create independent approval.

A conflict identifies potential capability; it does not establish that misconduct occurred.

What if full separation is impractical?

Document a specific compensating control and assess whether it addresses the conflict.

An independent check before payment release is preventive. Reviewing bank-detail changes against payments after release is detective. They offer different protection because retrospective review leaves exposure until detection.

For an accepted exception, record:

• The business reason and affected access.
• The risk owner and authorised acceptance decision.
• The control operator, procedure, frequency and evidence.
• The review date and expiry or exit condition.

“Management reviews reports” is too vague. Specify what the reviewer sees, how independence is maintained, what triggers investigation and how the outcome is recorded.

5. Implement changes and prove that they work

Use an approved change process with impact assessment, scheduling, testing and recovery arrangements. Use a representative test environment for transaction scenarios where appropriate, then confirm the relevant production configuration.

Each sensitive change needs two outcomes:

Positive test: required work still succeeds.

Negative test: the prohibited action fails through the relevant routes.

For the hypothetical supplier-maintenance example, the tests would include:

Define expected outcomes before testing. Retain the scope, date, result and reviewer evidence. If a restriction cannot be enforced, retain the finding or document an authorised exception with explicit interim controls.

Verify privileged access and audit evidence

ACSC guidance recommends restricting administrative privileges and using separate attributable administrative accounts.[3] Assess application, database, hosting and integration privileges where they can affect the process under review.

Establish which events are logged, which routes may fall outside coverage, who can change logging or evidence, how long records are retained and who reviews them. Configurable auditing does not establish that the required events are captured or acted on.

When is the access review complete?

Agree acceptance criteria at the start. The following provides a practical completion checklist:

Track approved for removal, removed and verified as separate states. Submitting a change request does not close a finding.

Management may sign off a review cycle with unresolved items, but the sign-off should disclose those items and their treatment. It should not imply that all remediation is complete.

How often should Pronto Xi access be reviewed?

Use scheduled reviews alongside event-driven changes. Set frequency according to risk, organisational policy, contractual requirements and the rate of change.

Departures, transfers, contractor expiry, temporary delegation, incidents and new integrations should trigger the relevant access process without waiting for the next scheduled review.

Prioritise more consequential access when setting the schedule. Record who owns the cycle and who follows up overdue decisions and expired exceptions.

How do you measure business value and ROI?

Establish a baseline before changing the process. Choose comparable periods and account for changes in user numbers, scope and transaction volume.

Keep three outcomes separate:

Also track access-related disruption after remediation. A faster review loses value if changes repeatedly prevent authorised work.

Define each measure consistently. For example, review coverage should use the reconciled in-scope population as its denominator. Count access removals as verified only after the relevant checks pass.

Include specialist assessment, internal review time, cleanup, testing and ongoing administration in the cost assessment. Compare one-off and recurring costs over the same period as the benefits.

If you calculate financial ROI, use evidenced financial benefits and a consistently defined cost basis. Report estimated capacity value separately from cash savings and avoid counting the same benefit twice. Licence savings depend on the agreement and billable usage model.

An access review can support a business case through stronger controls and reduced effort even when measurable cash savings are limited. It does not, by itself, eliminate fraud or establish compliance with a standard.

Prepare for a useful access-review discussion

Bring your account inventory, role assignments, financial delegation policy, connected-system list and known access concerns. These inputs help define the scope and identify the expertise required.

Look for capability in Pronto permissions, financial processes, connected systems and practical testing. Business owners must remain involved in decisions about required duties and accepted risk.

Read SAAPRO’s guide to Pronto Xi roles or Contact SAAPRO to discuss the specialist capability your organisation needs.