SOX testing 1514



  • Hey guys,
    I’m trying to do some research on what SoX Testers have to do… so far i’ve found nothing.
    In a nutshell, what do SoX Testers have to do to meet their goals?
    Thanks in advance,
    Will



  • Hi Will and welcome to the forums 🙂
    I’ll requote one of Milan’s excellent posts on Testing and share a few other links
    An unofficial transcript of the Public Company Accounting Oversight Board Roundtable on Reporting on Internal Control was convened by the Public Company Accounting Oversight Board at the Capital Hilton on Tuesday, July 29, 2003.
    An archive of the webcast of the program can be found on the Public Company Accounting Oversight Board’s website at www.pcaobus.org.
    The document is titled, ‘ROUNDTABLE ON REPORTING ON INTERNAL CONTROL’. You can download the document and search on the term ‘key control’. There are at least ten references to ‘key control’ in the document with the related dialogue from the PCAOB.
    Additionally, AS2, Audit Standard No. 2 addresses important controls that should be tested to comply with SOX. It provides significant guidance about other information that might be helpful in making a decision to determine if a control is considered a ‘key control’ for SOX purposes and should be tested.
    AS2:
    pcaobus.org/Rules/Rules_of_the_Board/Auditing_Standard_2.pdf
    Characteristics of a Key Control
    Factors management should consider in determining which controls to test include:
    The magnitude of the potential misstatement that could result from failure of the control
    The likelihood that failure of the control could result in a misstatement
    The degree to which other controls, if effective, achieve the same control objective
    Controls to be tested include:
    Controls over initiating, recording, processing, reconciling, and reporting significant account balances, classes of transactions and disclosures, and related assertions embodied in the financial statements
    Controls over the selection and application of accounting policies in conformity with GAAP
    Controls related to the prevention, identification, and detection of fraud
    Controls on which other significant controls are dependent (includes IT controls e.g. information security, program change control, computer operations)
    Each significant control in a group of controls that functions together to achieve a control objective
    Controls over significant non-routine and non-systematic transactions (such as accounts involving judgment
    estimates)
    Controls over the period-end financial reporting process, including controls over procedures used to enter transaction totals into the general ledger; to initiate, record, and process journal entries in the general ledger; and to record recurring and nonrecurring adjustments to the financial statements (e.g., consolidating adjustments, report combinations,
    reclassifications)
    Regards, milan
    Some other links in our forums
    http://www.sarbanes-oxley-forum.com/modules.php?name=Forums-and-file=viewtopic-and-t=1332
    http://www.sarbanes-oxley-forum.com/modules.php?name=Forums-and-file=viewtopic-and-t=1004
    http://www.sarbanes-oxley-forum.com/modules.php?name=Forums-and-file=viewtopic-and-t=1309



  • wow, thanks.
    So, correct me if i’m wrong:
    Data is sent through a whole bunch of ‘controls’ which act like filters and red flag data that is suspicious?
    I also have one more questions, whats a common way of testing these controls?
    Thanks,
    Will



  • Hi Will - Below are more ideas on testing in response to your questions:

    1. Looking at the big picture, you want to implement controls on all financials so that no one can ‘cook the books’ at a high level or so a worker can’t siphon funds away at lower levels in the financial flow. Controls are needed from top to bottom.
    2. SOX implementation requires SEC reporting companies (at the least larger ones) to improve all existing workflow controls. Even though you may have good controls in place prior to SOX, the new standards require an even more thorough approach of auditing, sampling, autonomy levels, separation of duties, etc.
    3. Not only do SOX controls need to be implemented, but they must be tested and documented as well. Based on a risk management approach and working with audit, the tester would randomly sample at control points and document the findings.
    4. Testing includes looking beyond just the data alone, as you should also re-evaluate procedures, workflow handoffs, or anything you can make better in the process.


  • I also have one more question, what’s a common way of testing these controls?

    1. In working with the SOX testing approach, it’s beneficial to partner with Internal Audit (or the external auditors) up front, so that there are no expectation gaps.
    2. You would describe the when, what, how, where, and why for testing needs – and gain their inputs plus approval.
    3. You would set up and publish a testing plan in advance. You should also update this along the way as improvements are made in the workflows or testing procedures
      EXAMPLE: You might see a need to test controls on a quarterly basis for a key financial system that might be using Excel based spreadsheets. You’d make sure that input data is accurate (your red flags analogy), that there’s versioning controls, that there’s security controls, and that everyone is following proper procedures. You’d then file this in the SOX library of documents for future audit inspections and repeat the same process next quarter.


  • I will assume that any readers that follow this string are looking for practical step by step tips on how to do testing. Here is what I’ve learned after reviewing professional literature and interacting with management and attest auditors. (Note: my perspective is as consultant assisting management with testing of their controls.)
    First, understand the established controls. Make sure you know which are key or non-key, frequency, type (automated, manual or mixed), who performs the control and how it is evidenced. This is a major undertaking because to do so means you need to interact and query a lot of process owners, managers etc. Another key point to consider is how long the control has been established. Example: If a company reengineered a process, added controls, or modified or remediated any controls, it stands to reason that the sample period would only cover the period in which the control was functionally in place as currently documented.
    Second, develop a test plan that fully addresses whether the control is operating effectively or not. A test plan is a plain English description of what a tester will do to test that specific control. (Example of a basic test plan for testing a control: Obtain a random sample of xxxxx. Verify that xxx ties with xxxx. Verify evidence of review and approval by xxxxx. Document results.) Of course, the test plan will vary based on the type and nature of the control. The de facto standard is to put all the individual control test pans together in an excel spreadsheet or thrid party software tool for quick review before any testing begins.
    A key component of a test plan is the sample size. The smaple size should consider the frequency of the control performed, the population of available instances, and the risk level assigned to the control. The proper size of the sample will typically vary depending on management preferences and external auditors opinion. On this issue, early communication among all parties cannot be underestimated.
    Next, the testing should be performed according to the test plan. Random samples should use a random number generator tool (several are availalble online). When reviewing controls, it is especially critical to well document each item in the sample. The supporting sample documents and a logically organized testing summary sheet should stand alone to support whether the control was performed correctly. Again, communication on acceptable format with all parties concerned is essential.
    Hope this helps those going at this for the first time.



  • Hi all, I am confused as to how to differentiate Sox testing from a regular audit testing. For example the control activity requires reviewing for approval signature of a monthly account reconciliation, and no exception was found during testing. However, a miscalculation was found in the supporting schedule for one of the reconciling item. Is it correct that since this is a Sox testing that only looks at approval signature, I dont have to go further and review the supporting schedule as I would have done in a regular audit?



  • It is pretty much worthless to look only for a signature indicating a review of a reconciliation. Even though the control may be the review and evidence of the review is a signature, the only way that you can determine whether or not the review is an effective control is to also check to ensure that the reviewer did a thorough job in his review. For example, you want to ensure that the reconciliation ties both to the general ledger and to the independent document that the general ledger is being reconcilied with. You want to ensure that there are no obvious math errors on the reconciliation, that it was prepared timely and that all reconciling items have been identified and are being cleared timely (i.e., no reconciling items exist greater than xx days old).
    Anyone can sign to evidence a review, but the real key control is the proper completion of the reconciliation.



  • I agree with Mike…the objective in assessing the operating effectiveness of a key control is to obtain assurance that the key control is in operation, consistently and reliably applied, and the intended COSO or other framework (CobiT) control objective is satisfied.
    Thus, evidence of a management sign-off on the reconciliation provides a basis to conclude that:

    1. management obtained the reconciliation at some point and performed sign-off. and
    2. adequate segregation of duties might exist if the preparer of the reconciliation is different from the reviewer.
      In this example, the management sign-off does not provide assurance that the reconciliation was properly reviewed, amounts were agreed to the related account balances in the GL, SL, bank statement, etc. This conclusion is achieved by performing additional audit procedures, namely those identified in Mike’s reply.
      Audit procedures conducted within the scope of a financial statement audit provide assurance that the amounts in the financial statements are accurate, complete, properly presented/disclosed, and in accordance with GAAP. These procedures are more focused on the amounts and required disclosures in the FS as opposed to the underlying internal controls over financial reporting (ICFR).
      Hope this further clarifies.
      Milan


  • Thank you for the responses. I have another question:
    The control activity is that monthly cash recs are performed and reviewed by management. The business/process owners are the ones who write the control activities. Internal Audit writes the test procedures and independently performs the sox testing. One of the bank accounts in the sample is a new account that was just created in the 2nd qtr (the test periods are jan-jun). The process owner sent an email to the sox tester to assert that the bank account was open mid-may. As such, the only available rec was Jun.
    Can the tester use the email as documentation, and is this email sufficent to support missing recs for the periods before Jun? Or does the tester have to further obtain independent confirmation from Treasury department regarding the new bank account?



  • If the process owner cannot open accounts and is not authorized to execute transactions on the account, then I would trust his statement. You could also verify by looking at GL activity or the May bank statement showing no activity prior to the mid-May date.


Log in to reply