Review of Users-Can you just focus on Segregation of Duties? 2657



  • Whether the combination of certain access rights presents a segregation of duties issue depends on the entire process and its controls including compensating controls, such as a review of new data/changes to data by an independent person.
    The segregation of duties, which is implemented in processes that use IT by segregating the access rights that correspond with those duties among several persons is a control to prevent fraud (e.g. the misappropriation of assets). While simply having access rights that one does not need and that do not conflict with the person’s other access rights may or may not enable fraud, can pose the risk of errors. Either users can play with a function that they really do not know or users can have access to post transactions to more accounts, cost centers, organizational subdivisions or companies than they need (are responsible) for and can accidentally post transactions to the wrong place. Material errors in the financial statements are an issue for internal control over financial reporting (i.e. section 404 of the Sarbanes-Oxley Act). Keep in mind that the materiality threshold for fraud is lower than the one for errors since fraud is also a qualitative issue for investors.
    ‘Control objective: Application access rights, including segregation of duties, are regularly reviewed and confirmed as appropriate by appropriate business managers.’ I am not sure how ‘segregation of duties’ should be interpreted by readers without expanding on it. In addition, I am not sure whether the grammar of the sentence is right without ‘the’ in front of ‘segregation of duties’, but then I am not a native English speaker.



  • Thanks all for your inputs. We still are having a debate about this one. Finance’s view is every scenario where people have more access than required is covered by by alternative finance reconciliation and controls. Problem is in the IT team we don’t have any visibility of this.
    Interestingly our external auditors do think we should check everyone’s access levels to see if they have more access than required.



  • As I said the risk is errors in the financial statements. Whether this is a significant deficiency or a material weakness or nothing for management’s assessment (e.g. by internal audit) or for the public auditors depends on whether the errors are material and of the likelihood of errors and on any effective compensating controls that would catch those errors. If you can identify past errors that sum up to material missstatements they will have a hard time to argue that the probability of errors is low and that any compensating controls are effective.
    If they argue that they have compensating controls that would identify material errors, they need to explain them and demonstrate that they are working effectively.
    You should also investigate the root cause why they have unnecessary access and how pervasive this problem is among users. A pervasive problem in controls relating to the assignment of appropriate access rights would indicate a significant deficiency in internal control over financial reporting. Even if it does not show up in any audit report, management should at least agree to establish controls concerning access rights that prevent this in the future and remove any unnecessary access.



  • As I said the risk is errors in the financial statements. Whether this is a significant deficiency or a material weakness or nothing for management’s assessment (e.g. by internal audit) or for the public auditors depends on whether the errors are material and of the likelihood of errors and on any effective compensating controls that would catch those errors. If you can identify past errors that sum up to material missstatements they will have a hard time to argue that the probability of errors is low and that any compensating controls are effective.
    If they argue that they have compensating controls that would identify material errors, they need to explain them and demonstrate that they are working effectively.
    You should also investigate the root cause why they have unnecessary access and how pervasive this problem is among users. A pervasive problem in controls relating to the assignment of appropriate access rights would indicate a significant deficiency in internal control over financial reporting. Even if it does not show up in any audit report, management should at least agree to establish controls concerning access rights that prevent this in the future and remove any unnecessary access.
    thanks, this is useful advice.



  • external auditors do think we should check everyone’s access levels to see if they have more access than required
    gmerkl covered this well (esp. in his last paragraph).
    COBIT 4 and other guidelines acceptable for meeting SOX 404 requirements specify ‘minimal access rights’ (just enough to get the job done). Given the amount of electronic fraud that has occurred in recent years, even the argument of compensating controls by the financial area may be seen as a weak one by the SOX external auditors. I’d recommend meeting with the system owners and streamlining access so that the external auditor’s concerns are satisfied.



  • Just to give some context we do operate strong Joiner Mover leaver controls (Preventative controls), Also we are strengthening SoD controls using an automated detective system. What we cannot prove is managers have checked access is ok periodically (eg annually). This is across 100 applications. So situations where individuals have more access than required cannot be evidenced, so Finance are arguing to ignore it as they will pick up with compensating controls.



  • I do not think that the review of access rights by line managers is a very workable control.
    Most line managers from departments outside of IT security or IT audit have no clue how access rights work in ERP systems (e.g. SAP) and would not be able to interpret a report with authorization objects and type of access to these objects. If they get a more high-level report with just the names of authorization profiles then they do not really know what is inside this profile. In other words, I think a review by non knowledgeable people is a waste of their time and you would be better off to have the reports reviewed by IT security or IT audit.
    The important preventive control is the access rights policy (i.e. only what is necessary, segregation of duty conflicts only if there are compensating controls and an exlicit authorization) and that the IT security person that grants the access rights has all necessary background information about the job duties of a person to make an informed access profile (in which company code, which plant, which cost center, work center with which purchasing groups, material groups, accounts, etc. the person works). Naturally only as needed access rights result in more access profiles since fewer generic access profiles can be assigned to persons with the same job duties. This means initially more work for the IT security person (and I can understand their point of view). However without reorganizations in the job content and only changes in the person that performs a particular position, there will not be more work later.



  • I do not think that the review of access rights by line managers is a very workable control.

    Yes, I think this is what we are encountering. But a similar issue is encountered with the preventative control when granting access - this isn’t reviewed by a specialist so its dependent on managers knowledge of what access they are granting and what other access the individual has.
    The core issue at debate here internally is we shouldn’t have detective controls. Our auditor’s have indicated there needs to be a mix of preventative and detective controls.
    What would you use as a detective control? eg in Practice is it necessary to get a specialist reviewing the access types in conjunction with line managers?



  • I would recommend to use a standardized paper or electronic user access rights change request form that has different request types:

    1. user leaves the company (and leaves his position)
    2. new user joins the company (and gets a position)
    3. user changes from one position within the company to a different one (transfer, automatically means losing access right profiles of the old position)
    4. creation of a new position or changes to the tasks of an existing position.
      While type 1) - 3) requests are routine changes that do not require a change to standard user profiles that are associated with a particular position and just assign existing user profiles (or block user-IDs), a type 4) request requires the creation of new user profiles or the modification of existing user profiles.
      The request forms are easy to handle for line managers (i.e. people with no specialized know how of access rights) by just using the job title and department of the position on the request forms. In the case of request type 4) an in-depth interview between the IT user access specialist and the requesting line manager is necessary. In addition, the IT user access specialist should run a segregation of access rights query that would identify conflicting user access rights before activating type 4) request changes (using standard predefined conflicts of user access). Any conflicts would require a description of compensating controls and an additional approval by somebody with knowledge in internal controls (and how compensating controls need to be structured). Ideally the query should allow to be restricted for one single user in order to save processing time (no need to run it for all users). If employees are also maintained in a payroll system and if this HR/payroll system also assigns users to companies, cost centers or other organizational subdivisions, it may be possible to write a query that compares whether the access rights match this organizational subdivision or to give some read-only access to the HR/payroll system (excluding salary data) to the IT user access administrator.
      While this may help to have clean new access rights, it does not help to determine whether people in existing positions have excessive or conflicting access rights. The solution here is queries across all users that are reviewed by an user access rights and internal control specialist (typically an IT auditor). There are several queries that could be designed/used:
    5. segregation of user access conflicts for all users (based on standard predefined conflicts)
    6. mismatches between HR/payroll organizational assignment and user access rights to organizations subdivisions, such as company codes, plant codes, work centers, cost centers, purchasing organizations, etc.
    7. a comparison which organizational units are actually being used by the user in his transactions with the units that he has access to (this can be very intensive for processing time and should be for small groups of similar users).
      As a byproduct those queries (especially no. 3) could also identify erroneous or unauthorized transactions that use organizational units that have nothing to do with the user’s position. Requiring those queries for all existing users on an annual basis would be clearly excessive from a cost benefit point of view if the preventive controls over access rights changes are solid.


  • I do not think that the review of access rights by line managers is a very workable control.
    Also agreeing with the good concerns.
    Just to briefly note that this only works at a high level and with assistance from IT as well. The ‘system owner’ usually is an individual entrusted with overall responsibility for an application, rather than line managers who might also be involved with the application. They are sometimes executives or might be someone who has good IT technical skills that is seen as the
    The system managers (end-users) would define goals based on job roles. The IT team would then apply this information, so that users based on their job roles are placed into ‘security groups’ in Windows or other platforms.
    The key is to have the user area clearly definely regular and special job roles and then build the security framework around their access needs. It requires considerable work and sometimes security is retrofitted in rather than planned up front.
    The subsequent posts by gmerkl provide excellent guidelines for proactively monitoring the end-user security environment . You definitely want to ensure terminations and other actions are handled promptly, as that’s any audit checklist including SOX related reviews.


Log in to reply