Sampling issues 1219



  • Hello guys,
    while going through one of the posts here, I suddenly bumped into this thought. I am going to narrate a situation to the best of my understanding. Pls forgive me if i commit any mistake and correct me. Here it goes…
    I am an internal IT Auditor(Sox). I, along other internal auditors, have been hired to assure the company that for every critical process identified by the management, there are sufficient controls over identified risks associated with possibilities of misstatement of financial statements. Let say management , with the suggesions(if any) of internal audit committee, has identified 10 applications that are critical and on an avarage, there are 15 controls per application.
    The Job of internal auditors is to submit a report to the management on efficiency of the internal controls over financial reporting. This report will then be produced to external auditors. They will take a sample of the given controls for each application to test the effectiveness of the controls.
    I think that as an internal auditor, I have to test each and every control for each critical application. We, as an internal auditor, are not supposed to test effectiveness on samples. Becuse it is quite possible that the controls that are left out of sample, may contain some deficiencies and quite posible that external auditor may choose them as their sample.
    Please correct me if I am wrong…
    Thanks



  • I think that you should be testing all Key Controls identified, and then test a sample (from the population) of transactions in that process. Bear in mind that it’s better to select a sample of transactions to test and follow/test through all key controls within a business cycle, to the extent possible, rather than selecting a new sample for every key control.
    Sampling Key Controls among all possible Key Controls is not an option.
    The trick is limiting testing to only those Controls that are truly ‘Key’.



  • good point…(Testing a complete transaction) it makes sense. Testing a typical transaction will take care of all the key areas under consideration. True, very true we have no options as far as key controls are concerned. We must test all of them.



  • Bear in mind that it’s better to select a sample of transactions to test and follow/test through all key controls within a business cycle, to the extent possible, rather than selecting a new sample for every key control.

    What we do is that we follow the testing through a process as described above as part of the test of design. This is done during the walkthrough. The in addition we select randomly ie a new sample for every key control as part of the tests of operating effectiveness.



  • Bear in mind that it’s better to select a sample of transactions to test and follow/test through all key controls within a business cycle, to the extent possible, rather than selecting a new sample for every key control.

    What we do is that we follow the testing through a process as described above as part of the test of design. This is done during the walkthrough. The in addition we select randomly ie a new sample for every key control as part of the tests of operating effectiveness.



  • In addition to the feedback from the other persons who posted replies on the Forum, you might also consider the following:
    Identify Application and General Controls:
    Key Components-
    Application controls

    • Embedded within business processes
    • Directly support financial assertions
      General controls
    • Program development
    • Program changes
    • Program operations
    • Access control
      PCAOB Audit Standard 2004-001
      Requires an auditor to trace significant transactions through the system. Establishes the importance of IT general controls
    • Program development
    • Program changes
    • Computer operations
    • Access to programs and data
      PCAOB statements applicable to Application Controls:
      ‘The auditor should identify each significant process over each major class of transactions affecting significant accounts or groups of accounts and
      Understand the flow of transactions, including how transactions are initiated, authorized, recorded, processed, and reported.
      Identify the points within the process at which a misstatement including a misstatement due to fraud related to each relevant financial statement assertion could arise.
      Identify the controls that management has implemented to address these potential misstatements.
      Identify the controls that management has implemented over the prevention or timely detection of unauthorized acquisition, use, or disposition of the company’s assets.’
      The PCAOB requirements require that the auditors must understand how transactions flow through the system not around it.
      The auditor should obtain an understanding of the design of specific controls by applying procedures that include tracing transactions through the information system relevant to financial reporting
      Most processes involve a series of tasks such as capturing input data, sorting and merging data, making calculations, updating transactions and master files, generating transactions, and summarizing and displaying or reporting data. The processing procedures relevant for the auditor to understand the flow of transactions generally are those activities required to initiate, authorize, record, process and report transactions.
      As earlier highlighted, it is not necessary to test all application controls in an application that is considered in scope for SOX purposes. It is only necessary to test those controls relevant to financial reporting as noted above.
      It might also be noted that the sample size when testing an application control is simply one since an automated control is generally considered to be effective for all subsequent events if it operates effectively in the first testing. Thus, continuing testing requirements and related sample sizes are greatly reduced when controls are shifted from manual to automated controls and/or are embedded in the IT application.
      Hope this is of further help.
      Milan


  • My sample only includes Jan and May reconciliations. These recs were reviewed without exception. However the business accidently gives me Apr, which I found a missing approval signature. Because Apr was not part of my sample, I was told to ignore this error. Is that correct?
    Thanks in advance for all your help with this question.



  • My sample only includes Jan and May reconciliations. These recs were reviewed without exception. However the business accidently gives me Apr, which I found a missing approval signature. Because Apr was not part of my sample, I was told to ignore this error. Is that correct?
    Thanks in advance for all your help with this question.
    I am of the belief that if you become aware of a control instance that failed, even if it was not part of your sample, you need to take that into consideration when assessing the overall effectiveness of that control. Of course, if the approval signature was missing on the April reconciliation and all of the subsequent months had approval signatures, then what is the deficiency and what is the suggested remediation? It would seem that the deficiency had been remediated by approval of the May reconciliation.



  • My manager was saying that, for Sox testing, if you review something that is not part of your sample, the sample would not be considered ‘random’.



  • I agree with KYMike. I get nervous when someone tells me to ignore an exception.
    I also think that your manager’s reasoning that ‘if you consider the rec with the exception, then the sample would not be random’ doesn’t hold water. Had the additional rec (that was given to you by mistake) not been a testing exception, then there would have been no issue. But, since you noted an exception, you should not ignore it.
    Having said that, were there other exceptions with the rec without a signature? Were there any unresolved reconciling items?
    Finally, is your ‘manager’ and auditor? or, a process owner/accounting manager?
    In an audit engagement, your direct audit supervisor has the final say. Period. You can disagree later over a cold beer. Don’t get caught up in dragging something out just because it’s a finer point of a technical issue.
    If they say ‘let it go’, then just document it and let it go.
    IMHO
    john



  • Don’t be too narrowminded when doing internal SOX testing.
    Better that you discover it and get a process of mitigating the issue started before the auditors find it.
    I’ve had people telling me that ‘you should not highlight it as this is not what we’re testing right now.’. My advice is ignore them.



  • However the business accidently gives me Apr, which I found a missing approval signature. Because Apr was not part of my sample, I was told to ignore this error. Is that correct?
    The specific timeframe is less important than discovery of some carelessness in the process. I’d recommend including at least a brief written comment somewhere as ‘ignorance is not always bliss’ 😉
    The purpose of testing and sampling controls is to find weaknesses in the system and not to blame others . A brief comment that all was well in other samples, while you found this in an additional sample, shares that the system is working well for the most part and may just need some very minor fine tuning.
    A comment in the report (even though officially out-of-bounds), might help tighten controls and get folks to pay better attention to important procedures related to financial controls 🙂


Log in to reply