Categorising controls as 'prevent' or 'detect' 2927



  • Morning%0ACould I ask for soem guidance on categorising controls as prevent or detect:%0AFirstly, my understanding is that for there to be an ‘effective internal control environment over externally reported financial data’ there must be an ‘adequate’ mix of prevent and detect controls - does anyone have any further definitions on ‘adequate’ - is there best practice % split?%0AMore importantly, I’m really struggling with the definitions. On the face of it it’s simple - prevent controls stop and error and detect picks up an error after it’s occured - but for SOx purposes, what is the error? Is it errors in externally reported numbers? If so, surely all controls before the numbers are externally pulished are preventing an error and any control subsequent to the data being published would detect a mistake?%0AOr another approach would be to say that the definition of an ‘error’ is any mistake in any system within the business. This would mean nearly all controls were detect as any type of review etc is detecting errors - the only prevents I could think of in this situation are access controls and maybe system controls which only allow a certain number of digits to be input?%0AThe approach we are proposing to take is to consider each ‘process’ in isolation, identify the purpose of that process, and then class any control which picks up erros before the purpose of the process is acheived as prevent and any control after the purpose of the process has been achieved as detect. eg in a consolidation process, a check that all individual entities balance sheets balance before the consolidation is preventing errors, wheras a check that the consolidated balance sheet balances (ie after consolidation) is a detect control?%0AThoughts please…



  • but for SOx purposes, what is the error? Is it errors in externally reported numbers? If so, surely all controls before the numbers are externally pulished are preventing an error and any control subsequent to the data being published would detect a mistake?
    Hi - In terms of designing and testing controls, it might be helpful to think beyond just SEC reporting requirements in light of the questions asked about error prevention or detection. The goal of the process is strengthen controls, plus prove to the external SOX audit firm that all financial processes are well controlled.
    In preventing errors , the classical audit approaches of ‘separation of duties’, ‘checks-and-balances’, ‘autonomy controls’, etc., might be used to design Financial workflows that reduce the risk of error and potential compromise of financial results. In detecting errors , this is where internal SOX testing of controls might be employed for those daily, monthly, or quarterly high-risk exposures.
    In testing Financial controls, an error might be any failure in the system and not necessarily a mathematical one in reporting to SEC. Usually they are human failures in the procedural flows. For example, it autonomy levels were in place and authorization was required (but was skipped because the approving manager was out) – that would be an error in the control system.
    If a finanical workflow had a rigid sequence of events and someone took a shortcut, that could be seen as a control error. Most often errors like this are minor in nature, where someone has failed to rubberstamp an approval or the shortcut was taken with good honent intent.
    You might check some of the other posts in the forum related to Control testing. While there is indeed a need to look at financial accuracy of the financial figures posted, there’s also a need to audit the actual control processes themselves.
    While I’m more involved on the IT side, that’s at least my understanding of error detection and prevention as it applies to SOX



  • Below are additional links you might want to copy/paste to your browser:
    Fraud - Detection and Prevention
    http-and-#58;//en.wikipedia.org/wiki/Fraud_deterrence
    What is COSO?
    http-and-#58;//en.wikipedia.org/wiki/Committee_of_Sponsoring_Organizations_of_the_Treadway_Commission

    Many key testing concepts are covered here:
    SOX 404 - TOP DOWN Risk Assessment:
    http-and-#58;//en.wikipedia.org/wiki/SOX_404_top-down_risk_assessment
    At each step, qualitative or quantitative risk factors are used to focus the scope of the SOX404 assessment effort and determine the evidence required. Key steps include:

    1. identifying significant financial reporting elements (accounts or disclosures)
    2. identifying material financial statement risks within these accounts or disclosures
    3. determining which entity-level controls would address these risks with sufficient precision
    4. determining which transaction-level controls would address these risks in the absence of precise entity-level controls
    5. determining the nature, extent, and timing of evidence gathered to complete the assessment of in-scope controls

Log in to reply