CAATs are used to test application controls as well as perform substantive tests on sample items. Types of CAATs include:
* Generalized Audit Software (GAS) – allows the auditor to perform tests on computer files and databases.
* Custom Audit Software (CAS) – generally written by auditors for specific audit tasks. CAS is necessary when the organization’s computer system is not compatible with the auditor’s GAS or when the auditor wants to conduct some testing that may not be possible with the GAS.
* Test Data – the auditor uses test data for testing the application controls in the client’s computer programs. The auditor includes simulated valid and invalid test data, used to test the accuracy of the computer system’s operations. This technique can be used to check data validation controls and error detection routines, processing logic controls, and arithmetic calculations, to name a few.
* Parallel Simulation – the auditor must construct a computer simulation that mimics the client’s production programs.
* Integrated Test Facility – the auditor enters test data along with actual data in a normal application run.
Saturday, May 30, 2009
Evaluation of Internal Controls
COSO defines internal control as, “a process, influenced by an entity’s board of directors, management, and other personnel, that is designed to provide reasonable assurance in the effectiveness and efficiency of operations, reliability of financial reporting, and the compliance of applicable laws and regulations”. The auditor evaluates the organization’s control structure by understanding the organization’s five interrelated control components. They include:
1. Control Environment Provides the foundation for the other components. Encompasses such factors as management’s philosophy and operating style.
2. Risk Assessment Consists of risk identification and analysis.
3. Control Activities Consists of the policies and procedures that ensure employees carry out management’s directions. Types of control activities an organization must implement are preventative controls (controls intended to stop an error from occurring), detective controls (controls intended to detect if an error has occurred), and mitigating controls (control activities that can mitigate the risks associated with a key control not operating effectively).
4. Information and Communication Ensures the organization obtains pertinent information, and then communicates it throughout the organization.
5. Monitoring Reviewing the output generated by control activities and conducting special evaluations.
In addition to understanding the organization’s control components, the auditor must also evaluate the organization’s General and Application controls. there are three audit risk componenets which are control risk, detection risk and inherent risk.
1. Control Environment Provides the foundation for the other components. Encompasses such factors as management’s philosophy and operating style.
2. Risk Assessment Consists of risk identification and analysis.
3. Control Activities Consists of the policies and procedures that ensure employees carry out management’s directions. Types of control activities an organization must implement are preventative controls (controls intended to stop an error from occurring), detective controls (controls intended to detect if an error has occurred), and mitigating controls (control activities that can mitigate the risks associated with a key control not operating effectively).
4. Information and Communication Ensures the organization obtains pertinent information, and then communicates it throughout the organization.
5. Monitoring Reviewing the output generated by control activities and conducting special evaluations.
In addition to understanding the organization’s control components, the auditor must also evaluate the organization’s General and Application controls. there are three audit risk componenets which are control risk, detection risk and inherent risk.
IT Audit Process Overview
The auditor must plan and conduct the audit to ensure their audit risk (the risk of reaching an incorrect conclusion based on the audit findings) will be limited to an acceptable level. To eliminate the possibility of assessing audit risk too low the auditor should perform the following steps:
1. Obtain an Understanding of the Organization and its Environment: The understanding of the organization and its environment is used to assess the risk of material misstatement/weakness and to set the scope of the audit. The auditor’s understanding should include information on the nature of the entity, management, governance, objectives and strategies, and business processes.
2. Identify Risks that May Result in Material Misstatements: The auditor must evaluate an organization’s business risks (threats to the organization’s ability to achieve its objectives). An organization’s business risks can arise or change due to new personnel, new or restructured information systems, corporate restructuring, and rapid growth to name a few.
3. Evaluate the Organization’s Response to those Risks: Once the auditor has evaluated the organization’s response to the assessed risks, the auditor should then obtain evidence of management’s actions toward those risks. The organization’s response (or lack thereof) to any business risks will impact the auditor’s assessed level of audit risk.
4. Assess the Risk of Material Misstatement: Based on the knowledge obtained in evaluating the organization’s responses to business risks, the auditor then assesses the risk of material misstatements and determines specific audit procedures that are necessary based on that risk assessment.
5. Evaluate Results and Issue Audit Report: At this level, the auditor should determine if the assessments of risks were appropriate and whether sufficient evidence was obtained. The auditor will issue either an unqualified or qualified audit report based on their findings.
1. Obtain an Understanding of the Organization and its Environment: The understanding of the organization and its environment is used to assess the risk of material misstatement/weakness and to set the scope of the audit. The auditor’s understanding should include information on the nature of the entity, management, governance, objectives and strategies, and business processes.
2. Identify Risks that May Result in Material Misstatements: The auditor must evaluate an organization’s business risks (threats to the organization’s ability to achieve its objectives). An organization’s business risks can arise or change due to new personnel, new or restructured information systems, corporate restructuring, and rapid growth to name a few.
3. Evaluate the Organization’s Response to those Risks: Once the auditor has evaluated the organization’s response to the assessed risks, the auditor should then obtain evidence of management’s actions toward those risks. The organization’s response (or lack thereof) to any business risks will impact the auditor’s assessed level of audit risk.
4. Assess the Risk of Material Misstatement: Based on the knowledge obtained in evaluating the organization’s responses to business risks, the auditor then assesses the risk of material misstatements and determines specific audit procedures that are necessary based on that risk assessment.
5. Evaluate Results and Issue Audit Report: At this level, the auditor should determine if the assessments of risks were appropriate and whether sufficient evidence was obtained. The auditor will issue either an unqualified or qualified audit report based on their findings.
Wednesday, May 27, 2009
IT auditor one of the fastest growing careers
Nobody likes the word “audit.” That is unless you are, or are thinking about becoming, an IT auditor, which is one of the fastest growing career areas in IT according to CareerProNews. Since the passage of information legislation, like Sarbanes-Oxley, IT audits have increased, and so has the need for people to do them.
An IT audit is basically the process of collecting and evaluating evidence of an organization’s information systems, practices, and operations. IT auditors look not only at physical controls as a security auditor would, but they also look at business and financial controls within an organization.
IT auditors help organizations comply with legislation, making sure they keeping data and records secure. These auditors don’t actually implement any fixes; they just offer an independent review of the situation.
Fred Roth, a senior consultant at a training institute, says he believes the demand for IT auditors will continue for the next couple of years: “I talk to a lot of management from companies in the U.S., Canada and Europe. The answers are always the same — they cannot find enough good IT auditors.”
So what does it take to be an IT auditor? CareerProNews says that “CIA (certified internal auditor), CISA (certified information systems auditor) and CISSP (certified information systems security professional) certifications are becoming an absolute must for IT auditors.”
Roth adds: “IT auditors need to be qualified to audit the many different aspects of IT: systems, networks, databases, encryption, etc., and that they need to be proficient and stay current as the technology changes. This requires ongoing training.”
Although most IT auditor positions start out on contract, many firms are realizing the need to hire full-time personnel to handle the duties.
An IT audit is basically the process of collecting and evaluating evidence of an organization’s information systems, practices, and operations. IT auditors look not only at physical controls as a security auditor would, but they also look at business and financial controls within an organization.
IT auditors help organizations comply with legislation, making sure they keeping data and records secure. These auditors don’t actually implement any fixes; they just offer an independent review of the situation.
Fred Roth, a senior consultant at a training institute, says he believes the demand for IT auditors will continue for the next couple of years: “I talk to a lot of management from companies in the U.S., Canada and Europe. The answers are always the same — they cannot find enough good IT auditors.”
So what does it take to be an IT auditor? CareerProNews says that “CIA (certified internal auditor), CISA (certified information systems auditor) and CISSP (certified information systems security professional) certifications are becoming an absolute must for IT auditors.”
Roth adds: “IT auditors need to be qualified to audit the many different aspects of IT: systems, networks, databases, encryption, etc., and that they need to be proficient and stay current as the technology changes. This requires ongoing training.”
Although most IT auditor positions start out on contract, many firms are realizing the need to hire full-time personnel to handle the duties.
Thursday, May 21, 2009
Regulation and Standard Usually Use For IT Audit
ISO / IEC 17799 and BS7799
Control Objectives for Information and related Technology (CobiT)
ISO TR 13335
IT Baseline Protection Manual
ITSEC / Common Criteria
Federal Information Processing Standard 140-1/2 (FIPS 140-1/2)
The “Sicheres Internet” Task Force [Task Force Sicheres Internet]
The quality seal and product audit scheme operated by the Schleswig-Holstein Independent State Centre for Data Privacy Protection (ULD)
ISO 9000
CobiT (Control Objectives for Information and Related Technology)
BS7799
10 Ways developers can meet user expectation and ease frustations
It’s no surprise that users have expectations that, if not met, make those users angry and frustrated. User think every programmer can make everything that user wants. Here are 10 common user expectations and what you can do to meet them so that you'll have a happy group of users.
First : Accurate data
Nothing on the planet can set a user off like seeing inaccurate data on the screen. “Inaccurate” covers a huge amount of ground, in the users’ eyes. For example, if a package has been delivered but the courier’s Web site shows that it is still 200 miles away, that isn’t “out of date” to the user, it is “inaccurate.” Another winner is when item information on an invoice or account history has no resemblance to the product that was ordered; this is sure to generate a few frantic calls to the customer service department. The potential for user pain is limitless within this category. Unfortunately, many of the root causes of inaccurate data are out of the developer’s hands: user error, insufficient information, failure to follow processes, and so on. But enough of it is within our power to at least make a dent in the problem. Make sure that your application validates all data, contains rules for performing “sanity checks” whenever possible, requires the right data, and uses atomic transactions instead of batch processing whenever possible.
Second : Responsive UIs
If there's one surefire way to make users angry, it’s to put the dreaded hourglass on their screen. For extra credit, block the main UI thread entirely so it doesn't respond to user input and looks like the application is hung. If they don’t kill the application completely, they sure will be shocked when it suddenly starts to respond like a ghoul rising from the grave (brain eating optional). If you really want to annoy them, have it suddenly process all of their frantic clicks and other inputs. Nothing can cause users to fly off the handle like finding out that their work was destroyed by keystrokes sent while the application looked hung. Provide them with the experience they expect and deserve: Perform long-running processes in a separate thread to allow the UI to update, give them a progress indicator that makes it clear that the application is not hung, and offer them a useful and responsive cancel button if possible.
Third : Easy logins
One of the most frustrating things for users is when they don't use a service often enough to really remember a username -- and the username they have on that service is hard to remember. For example, I use “seagate” for many Web sites, but sometimes that is not available, so I might end up with “seagate” or something else, and I use site only a few times a year. The frustration comes in when I keep trying passwords with the username “seagate” and I forget that this is a site where I have the unusual name. That’s when I start asking myself if I really need the site at all. You should either have a prominent “forgot your username?” system or just use the e-mail address, account number, or some other piece of information that is unique to each user but is not an arbitrary username.
Fourth : Consistent input
Some Web developers seem to think that it makes sense for the phone number field to have a different input box for each part of the phone number and to make the cursor automatically move to the next part of the phone number field when the current one is filled. This does make sense in a way, but it doesn't make too much sense to users unless all of the fields they encounter behave the same way. Do your users a favor and save yourself some work in the process: leave these fields alone or just have the phone number be one large text input.
Fifth : Compatibility
A long time ago, when people went to stores to purchase software in boxes, it was common to have to spend 15 minutes studying the box to determine whether it would run on your system. Now, as long as the application runs on your OS, it's hard to find a machine made in the last few years that lacks the physical specs to run the non-game applications out there. Nonetheless, application incompatibility still exists. Ironically, it is most common on the supposedly platform-independent Internet. With the exception of some “must-have” enterprise class application, there is no way that a user or organization is going to jump through hoops to make your application run or your Web site work. So instead of driving away potential users, find and fix the incompatibilities. Obviously, that doesn’t mean that a Windows application needs to be made to run on Linux; but it does mean that a Windows application should work on XP, Vista, the upcoming Windows 7, and possibly even 2000. Likewise, your Web applications should work on Internet Explorer, Firefox, Opera, Safari, and Chrome across OSes without a loss of functionality or significant differences in appearance.
Sixth : Reasonable resource consumption
It really does not make sense that a keyboard needs 200 MB worth of software to be installed to work or that a simple text editor should require 1 GB of RAM to run. Yet it seems that more and more applications are huge resource hogs. It seems like every minor application out there is nearly as large as Microsoft Office was five years ago... and Microsoft Office itself is now the size that an operating system was a few years ago! Users expect better, and so should you. Cut the bloat. Ask yourself if your application really needs 100 MB of stock images of people using their laptops on the beach or 30 MB of custom sound files. Chances are, it doesn’t.
Seventh : Documentation
We all know how much developers dislike writing documentation. So we tell ourselves that the application is so easy to use, “only an idiot would need a manual.” There are two problems with this thinking. The first is that the world has plenty of idiots in it. The second is that we are usually wrong about how easy the application is to use. If your organization has a technical writer to create the documentation, involve that person from the get-go; the top complaint I hear from technical writers is that they are handed a nearly finished product and told to document it, with little insight into how it actually should be used. If you do not have a technical writer available, you will really need to work hard to make sure that the documentation does not merely state the obvious and is written in a way that will be helpful to end users who are unfamiliar with your application.
Eighth : No surprises
Some applications are filled with surprises. Of course, the definition of a “surprise” is that users don't expect it. But at a higher level, users expect that nothing will come at them from left field, either. This covers a lot of territory. Here are some examples of things your application should not do:
Ninth : Easy data backup/restore
Some applications are notorious for being difficult to back up and restore. Some applications hide their data in areas that might not get backed up (especially when the user prepares to move to a new PC or do an OS wipe/reinstall). Microsoft Outlook Express immediately comes to mind, since it buries your mail in the Windows folder instead of user data. (I once lost five years' worth of saved e-mails thanks to this.) Other applications like to lock their data in a way that backup applications can't back them up properly. Make sure that your application puts its data in the appropriate places to allow it to be easily backed up, restored, transferred to a new PC, and so on, and test common backup applications for compatibility with your application, even while it is running, if appropriate.
Tenth : Does what it says it will
I know, this one is just plain silly, right? It makes perfect sense that if an application claims it will do something, that it actually does it. (Doing it well is optional.) At the same time, far too many apps not only fail to meet users' assumptions, but they do not deliver on their explicitly stated promises either. While this may bring up the traditional issues of salespeople and marketing departments promising beyond reality, the simple fact is this: If a user has paid for a particular feature set, you need to deliver that feature set, one way or another. Don’t let your users down by delivering an application that says it does ABC, but only does A and C!
First : Accurate data
Nothing on the planet can set a user off like seeing inaccurate data on the screen. “Inaccurate” covers a huge amount of ground, in the users’ eyes. For example, if a package has been delivered but the courier’s Web site shows that it is still 200 miles away, that isn’t “out of date” to the user, it is “inaccurate.” Another winner is when item information on an invoice or account history has no resemblance to the product that was ordered; this is sure to generate a few frantic calls to the customer service department. The potential for user pain is limitless within this category. Unfortunately, many of the root causes of inaccurate data are out of the developer’s hands: user error, insufficient information, failure to follow processes, and so on. But enough of it is within our power to at least make a dent in the problem. Make sure that your application validates all data, contains rules for performing “sanity checks” whenever possible, requires the right data, and uses atomic transactions instead of batch processing whenever possible.
Second : Responsive UIs
If there's one surefire way to make users angry, it’s to put the dreaded hourglass on their screen. For extra credit, block the main UI thread entirely so it doesn't respond to user input and looks like the application is hung. If they don’t kill the application completely, they sure will be shocked when it suddenly starts to respond like a ghoul rising from the grave (brain eating optional). If you really want to annoy them, have it suddenly process all of their frantic clicks and other inputs. Nothing can cause users to fly off the handle like finding out that their work was destroyed by keystrokes sent while the application looked hung. Provide them with the experience they expect and deserve: Perform long-running processes in a separate thread to allow the UI to update, give them a progress indicator that makes it clear that the application is not hung, and offer them a useful and responsive cancel button if possible.
Third : Easy logins
One of the most frustrating things for users is when they don't use a service often enough to really remember a username -- and the username they have on that service is hard to remember. For example, I use “seagate” for many Web sites, but sometimes that is not available, so I might end up with “seagate” or something else, and I use site only a few times a year. The frustration comes in when I keep trying passwords with the username “seagate” and I forget that this is a site where I have the unusual name. That’s when I start asking myself if I really need the site at all. You should either have a prominent “forgot your username?” system or just use the e-mail address, account number, or some other piece of information that is unique to each user but is not an arbitrary username.
Fourth : Consistent input
Some Web developers seem to think that it makes sense for the phone number field to have a different input box for each part of the phone number and to make the cursor automatically move to the next part of the phone number field when the current one is filled. This does make sense in a way, but it doesn't make too much sense to users unless all of the fields they encounter behave the same way. Do your users a favor and save yourself some work in the process: leave these fields alone or just have the phone number be one large text input.
Fifth : Compatibility
A long time ago, when people went to stores to purchase software in boxes, it was common to have to spend 15 minutes studying the box to determine whether it would run on your system. Now, as long as the application runs on your OS, it's hard to find a machine made in the last few years that lacks the physical specs to run the non-game applications out there. Nonetheless, application incompatibility still exists. Ironically, it is most common on the supposedly platform-independent Internet. With the exception of some “must-have” enterprise class application, there is no way that a user or organization is going to jump through hoops to make your application run or your Web site work. So instead of driving away potential users, find and fix the incompatibilities. Obviously, that doesn’t mean that a Windows application needs to be made to run on Linux; but it does mean that a Windows application should work on XP, Vista, the upcoming Windows 7, and possibly even 2000. Likewise, your Web applications should work on Internet Explorer, Firefox, Opera, Safari, and Chrome across OSes without a loss of functionality or significant differences in appearance.
Sixth : Reasonable resource consumption
It really does not make sense that a keyboard needs 200 MB worth of software to be installed to work or that a simple text editor should require 1 GB of RAM to run. Yet it seems that more and more applications are huge resource hogs. It seems like every minor application out there is nearly as large as Microsoft Office was five years ago... and Microsoft Office itself is now the size that an operating system was a few years ago! Users expect better, and so should you. Cut the bloat. Ask yourself if your application really needs 100 MB of stock images of people using their laptops on the beach or 30 MB of custom sound files. Chances are, it doesn’t.
Seventh : Documentation
We all know how much developers dislike writing documentation. So we tell ourselves that the application is so easy to use, “only an idiot would need a manual.” There are two problems with this thinking. The first is that the world has plenty of idiots in it. The second is that we are usually wrong about how easy the application is to use. If your organization has a technical writer to create the documentation, involve that person from the get-go; the top complaint I hear from technical writers is that they are handed a nearly finished product and told to document it, with little insight into how it actually should be used. If you do not have a technical writer available, you will really need to work hard to make sure that the documentation does not merely state the obvious and is written in a way that will be helpful to end users who are unfamiliar with your application.
Eighth : No surprises
Some applications are filled with surprises. Of course, the definition of a “surprise” is that users don't expect it. But at a higher level, users expect that nothing will come at them from left field, either. This covers a lot of territory. Here are some examples of things your application should not do:
- Require additional payments or service fees (including cell phone minutes for mobile applications) that are not made obvious before the user purchases the software in the first place • Install any advertisement distribution mechanisms
- Add any browser toolbars, Outlook plug-ins, or other “helpful applications or add-ons” to the system
- Delete or modify user data or system files, including libraries
- Send or capture usage data or personal information, for marketing or technical purposes, without the user’s knowledge and consent
- Replace the current default applications for tasks without explicit user confirmation While many users probably won’t notice at least a few of these, and many users won’t raise a big stink about it, it is still wrong. Users don't like it. After all, do you like it when applications behave like this?
Ninth : Easy data backup/restore
Some applications are notorious for being difficult to back up and restore. Some applications hide their data in areas that might not get backed up (especially when the user prepares to move to a new PC or do an OS wipe/reinstall). Microsoft Outlook Express immediately comes to mind, since it buries your mail in the Windows folder instead of user data. (I once lost five years' worth of saved e-mails thanks to this.) Other applications like to lock their data in a way that backup applications can't back them up properly. Make sure that your application puts its data in the appropriate places to allow it to be easily backed up, restored, transferred to a new PC, and so on, and test common backup applications for compatibility with your application, even while it is running, if appropriate.
Tenth : Does what it says it will
I know, this one is just plain silly, right? It makes perfect sense that if an application claims it will do something, that it actually does it. (Doing it well is optional.) At the same time, far too many apps not only fail to meet users' assumptions, but they do not deliver on their explicitly stated promises either. While this may bring up the traditional issues of salespeople and marketing departments promising beyond reality, the simple fact is this: If a user has paid for a particular feature set, you need to deliver that feature set, one way or another. Don’t let your users down by delivering an application that says it does ABC, but only does A and C!
Subscribe to:
Posts (Atom)