User Access to Applications 1321

  • Our auditors are telling us this year that the lack of a formalized process of filling out forms for users to be added to each application (handled by system admins located in each department responsible for the application) will likely be considered a deficiency. My point of view is that if our informal process of adding employees can be confirmed to be accurate by reviewing those with access to any given application by reviewing that only current, authorized employees are on the user list, how is this deficient?.? As an additional mitigating factor, we do have a more formalized process with forms submitted by managers for individuals to be added to the network, and without access to the network, they can’t get to the log in screen for the application anyways. Any thoughts - agree or disagree?

  • I would tend to side with your auditors on this. How often do you review the list of authorized users? If monthly, an unauthorized individual could have access for up to one month before being detected. How are users added to the system today? There must be a process to add a user, even if not formalized. It shouldn’t take much effort to formalize this.
    I don’t see this as a SD or MW, just another deficiency to fix.

  • It might be a good idea to develop and implement a User Access Form or an Automated Access Control Process to control access to IT Applications. Although the network access controls might prevent access to the Corporate IT Network, a layered approach to manage user access is generally preferable.
    Some access control items for consideration:
    Access control:

    • Business requirement for access control.
    • User access management.
    • User responsibilities.
    • Network access control.
    • Operating system access control.
    • Application access control.
    • Monitoring system access and use.
    • Mobile computing and teleworking.
      Lack of documentation or inadequate documentation is a recurring control deficiency that has been previously and repeatedly cited by many auditors during the SOX assessment.
      Lack of a formal user access form may not necessarily lead to a significant control deficiency or worse yet, a material control deficency that would preclude a satisfactory opinion on the internal controls over financial reporting. However, informal controls over user access to IT applications would likely detract from the overall ITGC (IT General Controls) and would be considered in conjunction with other IT related deficiencies by the auditors. Taken as a whole, the lack of documentation then could lead to something quite significant.
      As for making a case that since no unauthorized users are found with access to the IT Application and that basic network access controls exist, so a control deficiency does not exist…this is like saying that because I’ve left my car keys in the car (windows were closed) and imy car has never been stolen…sounds nice, but pointless and winless to do battle with the auditor…better to save your strength for the more subjective auditor findings.
      Hope this helps,

  • JoBar,
    Auditors are going to look for complementary prevent and detect controls, the idea being that if one control fails the other will still be working.
    In your case, you can only demonstrate an effective detect control which the auditors will not like for reasons stated by Milan.
    Therefore, you need to formlaize and appropriately document your prevent and detect controls. (As an aside, just read through PCAOB auditing standard #2 and count the number of times they say ‘prevent and detect.’)
    There are some cases where only a detect control would be appropriate if the establishment of a prevent control is not practical given the level of risk. However, these situations are exceptional and logical access is not one of those exceptions.

  • I also agree with the other professionals on need to more formally document this. You might develop an overall checklist, for adding new employees, changes in access or job roles, and termination procedures. I would capture what is being done now from a workflow perspective and look for ways to strengthen it. Milan’s post is an excellent starting point.

  • Sox Wants DOCUMENTATION. Everything needs to be documented and it better be a FORMAL documentation. All said and done, only formal documentation would ensure that the the work assigned to a particular person is indeed done only by him/her. I am interested in knowing whether the authority matrix that you follow is a formal document or not? And again, if this document is a formal one, its all the more better to have the subsequent documents that follow this document to be formal as well.
    My suggestion would b for your orgn to use automated system based tools that take care of all these issues and maintain solid logs as well. Again it depnds on your affordability, as most of these tools come at a shocking price 8O

  • I agree with NC’s good points … Use Change Control techniques to formally establish and later revise documentation.
    For example, we use the Intranet for some of the non-sensitive procedures where everyone needs to know and to be following guidelines. It’s a great way to communicate security or procedureal work flow standards 🙂
    More restrictive procedures (e.g., our Information Security guidelines) are in protected Lotus Notes data bases with only read access to only those who need to know.

  • On one of my clients audited by KPMG, for the 2004 Sox Efforts, I created an Access Matrix on Excel, identifying users by Security Groups. KPMG auditors utilized this as a starting point to identify conflicting segregation of duties. This matrix is also being used for quarterly review by management and KPMG for subseqeunt attestation on ITGC related to logical access.
    Unless, the system churns out this matrix, I would recommend creating one on excel and using this matrix for Sox Attestation.

Log in to reply