Application controls 434



  • I’m looking for documentation on what is an application control. So far I know to look for program or application logic that prevents or detects unauthorized transactions. Is that the only definition I need? Where can I find more information on this fascinating topic? 🙂
    Mostly I am finding manual controls, as the applications have, historically, been relatively wide open. Access controls, we understand, will have to be improved, but there are not many embedded controls.
    -Dan



  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • An application control is a control that is part of the ‘application’.
    For example, a Purchase Requisition is submitted and approved for USD10; within the limits of the approver. The buyer receives the requisition and investigates the purchase request but finds that the amount is now USD15 which is over the approval limit of the requester. What is the application control that stops this order from being placed until there is authorization from someone with a higher approval limit?
    An application control would check this against the approval limits and stop the transaction until appropriately approved. A manual control would be that the Purchasing Agent would do this and get the requisition signed by the higher authority before placing the order.
    Other common application controls check for things like date ranges, dollar amounts, account codes, check number ranges, po number ranges, etc. Other application controls might ‘suspend’ transactions when data is changed. For example, changing a Vendor Master Record address might suspend payments until someone ‘authorizes’ the address change to keep from having checks sent to a new name or new address when then shouldn’t be.
    I hope this helps.



  • Yes, that is the sort of thing I thought. There are not many here, as we are using 20-year old package software and some home-grown applications. The new systems, when implemented, will have more application control capabilities.



  • Application controls apply to the business processes they support. They are controls disigned within the application to prevent or detect unauthorized transactions.
    You should look at the ‘IT Control Objectives for Sarbanes-Oxley’ Booklet and the COSO report for a closer definition.



  • Where do I get a copy of the IT Controls of Sarbannes Oxley booklet you mentioned?
    Thanks



  • _at_JLC: Visit either isaca.org or itgi.org There’s PDF File called ‘IT control objectives for Sarbanes-Oxley’. It’s free of charge.





  • Thanks for the quick response. Copy now downloaded.



  • Application controls apply to the business processes they support. They are controls disigned within the application to prevent or detect unauthorized transactions.
    You should look at the ‘IT Control Objectives for Sarbanes-Oxley’ Booklet and the COSO report for a closer definition.
    I have been trying to go the this document, especially the IT general controls section, and am finding it difficult to decipher/interpret the control in terms of the extent to which it should be tested.
    For example. Figure 11, pg 58 - Acquire or develop application software –
    The first two controls and corresponding illustrative tests of controls ask for review of SDLC methodology, but have not explicitly asked for reviewing/testing whether the organization has actually applied the processes stated in the SDLC.
    As a result, I have two views in my team - 1)we should only review the SDLC as that’s what is being asked, and, 2)- review SDLC and also the processes stated in SDLC should also be tested - that the development/maint./acquisition projects actually followed them -, because the auditors would go to that level.
    ?? - I would welcome any suggestions/advice on this.
    The problem is that sometimes the controls and illustrated tests seem to be very exact and explicit as to what needs to be tested, and sometimes they are very vague, which leads to diff. people having different interpretations.
    Next, coming to 3rd control in the same section -
    Control : The SDLC methodology ensures that Info systems are designed to include application controls that support complete, accurate, valid and authorized transaction processing.
    Illustrated Test of this control : Review the methodology to determine if it addresses application controls. Consider whether there are appropriate steps to ensure that application controls are considered throughout the acquisition or development lifecycle. For example -application controls should be included in conceptual design and detailed design phases.
    Now, reading this, I am thoroughly confused as to what exactly is being asked to be tested, and to what extent /depth?
    What would be the ‘appropriate steps’?
    And how would one test that application controls were actually included in the s/w being developed, without actually reviewing the design docs? which I don’t think possible that an auditor would do or understand.
    Am I missing something or is it actually as confusing as I think it is ??? :?



  • Hello, I will try to help.
    As a result, I have two views in my team - 1)we should only review the SDLC as that’s what is being asked, and, 2)- review SDLC and also the processes stated in SDLC should also be tested - that the development/maint./acquisition projects actually followed them -, because the auditors would go to that level.
    As an IT Auditor I will obtain the SDLC as my first test. Then I will look to see if it was approved by an appropriate person in upper management. Then I will review it to ensure that it has either been reviewed for ongoing appropriateness and relevance within the past year, and / or that it has an explicit statement that this must be reviewed and approved on a yearly basis.
    Then I will review the entire SDLC to see if it makes sense. Is it really an SDLC or is it password standards called an SDLC. Once it seems reasonable, and usually explained to me by the client why it is reasonable, I will test the entire SDLC.
    If the SDLC says that client will do A, then B, then C, then D. I will go through logs for changes to all systems and applications and select 25 (or less depending on the number of changes). I will then request all of the documentation to ensure that yes indeed, A happened before B happened and then and only then did C happen. I will also ensure that there is adequate sign off at each step to ensure that it was reviewed. I / we take the attitude that if it isn’t documented it didn’t happen.
    The problem is that sometimes the controls and illustrated tests seem to be very exact and explicit as to what needs to be tested, and sometimes they are very vague, which leads to diff. people having different interpretations.
    True, there is a lot of overlap and conjuncture. If you explain something to me and I think it is reasonable for your business then I will follow your understanding.
    Next, coming to 3rd control in the same section -
    Control : The SDLC methodology ensures that Info systems are designed to include application controls that support complete, accurate, valid and authorized transaction processing.
    Illustrated Test of this control : Review the methodology to determine if it addresses application controls. Consider whether there are appropriate steps to ensure that application controls are considered throughout the acquisition or development lifecycle. For example -application controls should be included in conceptual design and detailed design phases.
    Now, reading this, I am thoroughly confused as to what exactly is being asked to be tested, and to what extent /depth?
    As an auditor I would be looking to ensure that your SDLC takes application controls into consideration as appropriate. It might be something that says . All applications will whenever possible include automated controls to ensure the complete, accurate, and valid processing of data.
    Then there might be a process in the SDLC that has a step, has the new application been reviewed to ensure that appropriate automated controls are implemented. (I am being fast and loose here with examples).
    What would be the ‘appropriate steps’? See above for an example?
    And how would one test that application controls were actually included in the s/w being developed, without actually reviewing the design docs? which I don’t think possible that an auditor would do or understand.
    Don’t count out your IT Auditor until he/she have proven themselves useless. I might understand your design docs, god knows I have seen enough of them, but looking at them means 1.) They are there, (which should be a control), and 2) with someone in your company I would /better be able to understand to form an opinion.
    Another test is that someone needs to review and sign off that either applications controls have been included, or the systems has been reviewed and application controls are not appropriate.
    Am I missing something or is it actually as confusing as I think it is ???
    Nope you are not missing anything. It really is as confusing as you think it its.
    Hope this helps.


Log in to reply