Fellow Auditors please advise 2578



  • Hey everyone,
    More of a vent story… but your input would be appreciated too :
    Today was a very interesting day at work.
    Due to internal power struggles over few last months our whole IT testing team just crumbled, fortunately no one got fired nor laid off, but everyone just went their own marry way.
    Politics aside… back to topic on hand… I was excited because a new director for IT Audit was hired and I had a chance to work with someone that was in IT field for over 20 years… and I’m always excited to meet other IT auditors because there are just few people that truly understand what IT Audit is about. Today was our first working session; when I got to the meeting this guy was already elbows deep in the control matrix… hard worker, I can definitely appreciate that.
    Then he lifts his head…
    And informs me that he had removed the Physical Access, Back Up and Malicious Code Controls as they have no impact on financials. We are no longer to test or be concerned with them.
    My jaw dropped… I couldn’t collect my thoughts, and on the same token failed to be persuasive enough to get him to reconsider.
    This attempted scaling back is so off the charts and goes against the grain that Im wondering if perhaps I have missed some new AS ruling :roll: … but I dont recall missing any ISACA meets
    Now if this came from another auditor at my level I would just chuckle it up to some kind of misunderstanding or a joke, but this guy supposedly has 3 times more experience than me and is serious… there is only two of us.
    Am I crazy? :



  • If the risk and control matrix that you mentioned is a specific risk and control matrix for internal control over financial reporting only, then he may have a point. If it is a general risk and control matrix that covers all risks in the IT audit universe, he may be wrong.
    In internal control over financial reporting, you only test those controls where there is at least a reasonable possibility that a material misstatement of the financial statements can occur. If the risk assessment is that it is extremely unlikely that somebody can do accounting postings with material amounts from the data room that would not be detected by any compensating controls (i.e. reviews by controllers/accountants), he may have a point. The same can be true for back up controls and controls over malicious code. If the risk assessment is sufficiently low, then testing the controls for internal control over financial reporting is not worth the effort.
    While I would not test those controls for ICFR, I would test them for other purposes. Probably not every year, but at least every couple of years. So in conclusion, you may have misunderstood the guy and it is just about a difference in the level of risk that you and he assess.



  • Excellent point.
    I should have mentioned, that we are not an inhouse audit team but a consulting service… 9 out of 10 times we go in without any prior risk assessments; mainly deal with smaller organizations, in many cases fresh start ups.



  • Hi,
    Your post was interesting and I am sure that it will stir some debate/discussion among those who visit this site.
    I agree that it may be possible to scope out controls that have indirect influence at best or have no direct impact to financial reporting.
    Additionally, you may also be able to reduce some process level testing if you have strong compensating controls, a strong control environment/company level controls.
    However, the external auditor is required to consider evidence to support the design and operating effectiveness over the ICFR. As a consultant responsible for providing assistance to the client to comply with SOX requirements, this seems to require that you consider the expectations of the auditor so that the client can achieve the SOX attestation.
    With respect to the IT environment, many companies have selected CobiT as the framework to support their compliance with SOX IT requirements.
    CobiT requires that you must document and risks and controls for:

    1. Application level controls and procedures,
    2. IT supporting processes (IT General Controls) and
    3. IT entity level controls.
      At the process level, applying CobiT involves an assessment to consider the potential impact on financial reporting internal control objectives over:
      a. Security if designed and implemented properly can assure that transactions are executed by only authorized individuals and
      b. security if designed appropriately, access to assets ( PHYSICAL and electronic) is appropriately restricted and safeguarded from unauthorized access, modification, or destruction.
      Given these considerations, it seems reasonable to conclude that consideration and/or testing of PHYSICAL ACCESS and MALICIOUS CODE controls are within the scope of ITGC.
      Typically, the following are generally accepted as comprising ITGC:
    • Systems maintenance
    • Disaster recovery
    • Physical and logical security
    • Data management
    • Incident response
      Of these, backup and recovery falls into two of the above components. So if you include ITGC within scope for SOX purposes, this also entails considering data BACKUP in your controls assessment.
      After reading through the CobiT processes, I noted a number of processes that directly address the areas that were scoped out as noted in your post. This approach may be defensible for a number of reasons, but as noted in an earlier post, not advisable.
      Hope this further adds to the conversation.
      Milan


  • you have the answer in your post.
    If your RISK ASSESSMENT is convincing enough to support that the three mentioned areas need not be covered( low risk) then there is no point in covering them at all.
    Your lucky to have a manager who is interested in doing things based on Risk assessment
    :roll:



  • Milan, thanks for breaking it down and reaffirming my beliefs… and here I was thinking I’m going crazy 😉
    you have the answer in your post.
    If your RISK ASSESSMENT is convincing enough to support that the three mentioned areas need not be covered( low risk) then there is no point in covering them at all.
    Your lucky to have a manager who is interested in doing things based on Risk assessment
    :roll:
    Well, risk assessment shrisk assessment, I’m not afraid to get my hands dirty, and I’ll be dam*ed if I will put out any work that I’m not confident standing behind…
    Which leads me to the next point… we are a consulting service 😄 Client pays me to do their SOX, GLBA etc. testing and there is no way in h3ll I will hand them something half way done, with some BS story why I dont think they should worry about Physical Access or Back Ups. All the grief and my own morals on the line to save 5 minutes on a data center walk thru… I take pride in my work 😉
    /Vent
    I assume most of you are consultants too??



  • Milan, 404Error,
    Let’s be clear on one thing. The rules of the SEC relating to section 404 of the Sarbanes-Oxley Act reqire that the issuer uses a generally accepted framework for internal control over financial reporting and disclose which framework was used in the annual report. The rules mention internal controls - integrated framework (COSO), Turnbull and the CICA’s CoCo as examples. It does NOT require an additional framework that deals purely with IT controls and you will find virtually no company that discloses that they use COBIT in addition to COSO in their annual report (I have reviewed ALL reports from 2002 to 2007 from issuers from the UK, France, Germany, Italy, The Netherlands, Switzerland and Austria).
    While an IT auditor (and I used to be one and a CISA, respectively) may find his own job important and care about IT risks no matter how low they are, a lot of clients of IT audit consultants will perceive a lot of IT audit procedures as over-the-top buerocratic stuff that hardly has any link to financial reporting. Let’s be honest. How many cases in your professional life have you had where a system that was important for financial reporting went down and could not be restored due to a lack of backups so that the guys missed a financial reporting deadline? Or a different question, how likley do think it is that a company that you have never been to never makes a backup?
    IT audit clients also care about the number of hours that are charged to them. The budget has limits. In such situations, one has to focus on the areas with a higher risk of errors in financial reporting. There is tons of areas in an accounting system like SAP that one could look at instead.



  • Hi,
    I agree that SOX does not specifically require using an additional framework and as you stated, one that deals purely with IT controls .
    However, virtually all companies that are subject to SOX rely on computers to process, accummulate, and compile data that is used for financial reporting purposes.
    This fundamental relationship between the IT system, financial reporting application(s) and the business processes that are performed to prepare the financial reports results in the requirement to conduct basic controls testing in the IT environment along four domains.
    In the US, the external auditors will require input from the IT auditor who is responsible to review the IT controls at the audit client so that the external auditor can render an opinion for SOX purposes. The IT auditor will make use of a framework…CobiT, ITIL, etc., to assess the IT environment in connection with the SOX assessment.
    Thus, the external auditor will make use of an IT controls framework to perform the SOX assessment regardless of whether the audit client and/or IT auditor uses one.
    While the IT auditor might consider the IT controls to be low risk or ‘over the top’, the external auditor might not agree in this assessment and in the end, will require some controls testing in the IT environment.
    Virtually all companies disclose using COSO or another framework and make no mention of using CobiT or another IT controls framework. This seems to be the result of the large audit firms using ‘boiler plate’ language.
    This does not mean that CobiT or another IT controls framework was not used. Rather, the Company might simply chosen not to identified use of a secondary framework.



  • Taking a step back from this.
    Most approaches, COSO included, require (or at least infer) an asessment of General Computer Controls over significant applications that support financial reporting.
    Of course this does not mean you havbe to apply COBIT, and even if you use COBIT it would not require that you apply every objective. In fact the ISACA document mapping IT control objectives to COSO states:
    IT Organizations should considerthe nature and extent of their operations in determining which of the control objectives, illustrative controls and tests of controls need to be included in their internal control program.
    Personally I wouldn’t remove the objectives you refer to in the initial question. In my organisation we are look at control from the point of view of what are all of the requirements that the business faces (IT or otherwise) and having internal control processes that deliver all of those requirements in the most efficient way. We are getting away from a programme that just delivers SOX compliance.
    From a pure SOX point of view this may very well be a justifiable decision.


Log in to reply