Segregation of duties and access security

As auditors review areas for organizational risk and financial statement accuracy, they investigate the adoption and practice of related internal control techniques for segregation of duties and access security.

Segregation of duties

A main focus of regulatory compliance is to ensure that data is only accessed or created by the correct people. Segregation of duties is the act of separating and assigning steps in a process to different owners, which serves as a double-check for accuracy and the absence of fraud. As a general principle, an organization needs to ensure that responsibilities support separation of duties so that one individual cannot bypass financial controls or have end-to-end responsibility for a process.

To learn more, see:

Considerations for segregation of duties

Many organizations struggle to implement an access-based segregation of duties framework because of a lack of staff in finance-related roles. Consequently, they need to supplement access controls with mitigating detective controls.

As a general principle, list the segregation of duties controls in the organization’s main controls framework and not in the access controls framework. This encourages the organization to consider other ways to manage risks beyond relying on access and permissions.

Access security and permissions

Sage Intacct allows administrators to restrict employees from accessing different application areas based on their role and department. For example, an IT manager could give a new employee who handles accounts payable access to only the Sage Intacct Accounts Payable application while preventing their access to other applications, such as Accounts Receivable and Cash Management.

The several ways that access can be restricted to functions and segregation of duties can be achieved in Sage Intacct include:

  • The standard way is through permissions. Permissions can be managed at an individual level or with roles. To learn more, see:
  • Reports and dashboards can be created with restricted access lists. With restricted lists, only specific users can access the data in the report or dashboard. To learn more, see Permissions tab.
  • Transaction definitions can be built with rules to restrict access to functionality for a particular activity. For example, a sales invoice can only be created with reference to a sales order. In addition, a transaction definition can be created with restricted access lists. With restricted lists, only specific users can create or access those transaction types. To learn more, see Transaction definitions (the User and group permissions on the Security configuration tab).

Considerations for access security and permissions

Many access issues can arise due to the organization requirements and realities, particularly as organizations scale and experience changes to operations and staffing. These issues might include the following:

  • In small- and medium-sized organizations, employee roles tend to more flexible. So, access that doesn't meet audit requirements is given. This is not an issue if they remain small, but they might require more organizational discipline when they grow, seek certain funding, or plan for a change in legal structure.
  • Organizational changes that affect who does what might require a redesign of access permissions after the system is in use. Such redesign requires additional time and effort to evaluate, update, and test.
  • Many organizations tend to rely too heavily on access controls for existence control objectives instead of taking a more holistic view on the power of detective controls (such as reports and monitoring), which are often effective in small and medium sized organizations.
  • Permissions can be very complex to design properly from the start. Before you design, understand the full potential of Sage Intacct’s sophisticated access controls and anticipate all organization requirements, including future needs.

External auditor firms sometimes focus on access controls before fully understanding how a Sage Intacct solution performs financial controls because access controls are easier to audit and easier to find errors. Remember that access controls are only one element of control and that the other ways of gaining evidence of existence/genuineness of transactions, such as detective and monitoring controls, need to also be considered.

Access security and permissions
Access and permissions features Rationale Limitations

Transaction and menu-based access

Easy to understand and visible. Simple to design as security checks are mad at transaction outset.

 Might not support complex access requirements

Workflow based

Essential to support workflow controls.

Can be complex if workflows are overly complex

Data element based (for example, entity or supplier)

Supports controls over sensitive data (for example, government contracts, sensitive fields such as bank details, personal data for employees who are suppliers).

Might dictate the need for transaction logic that requires this data to be input up front

Special permissions for specific transactions

Where there are specific access permissions tied to functionality. This is often the case for system administration activities, but can be extended to business transactions.

Adds complexity but might be a solution for specific needs

Features for custom-built security checks, allowing customer-defined rules

Gives increased flexibility.

Auditors need to understand and test the design effectiveness of these controls.