What Technology Should be Audited within Banks and Financial Institutions ?

??

When determining what technology should be audited, there is no “right” answer. A poor choice is to begin with a checklist for a particular technology and execute the test steps without first understanding the overall audit scope and related risks and objectives. This article focuses on some specific areas of the technology process that should be considered within that scope in addition to the specific technology itself:

• ?IT Strategy
• Personnel Management
• Sourcing Practices
• Business Continuity and Disaster Recovery
• Change Management
• User Provisioning and Segregation of Duties
• Configuration Management
• Operations
• Security
• Monitoring

This is not a comprehensive listing of areas to be tested but is rather a collection of commonly encountered topics relevant to a wide variety of IT audits. It can be used as a general starting point to identify some of the more likely elements that may need to be considered during the course of developing an audit work program or performing an audit. Because these topics are complex processes in and of themselves, they will be designed and performed differently across organizations. However, there should be a well-defined and understood process in place (preferably documented) that the IT auditor can use as a guide for his or her environment when developing an audit program. These “indigenous” practices should be considered along with recognized industry practices and frameworks to help guide the auditor to a comprehensive audit process that measures both the client’s compliance with expected practices and the organization’s deployment of the best practices for their environment.

?This article also briefly addresses the concepts of an integrated audit and continuous auditing, two very effective approaches to an audit of technology, providing possible considerations of the “how” for an IT audit. Excellent guidance for all of these topics can be found throughout The IIA’s GTAG series.

?IT Strategy

Strategic planning from an information systems standpoint relates to the long-term direction a bank wants to take in leveraging IT for improving its business processes. Under the responsibility of top management, factors to consider include identifying cost-effective IT solutions in addressing problems and opportunities that confront the bank and developing action plans for identifying and acquiring needed resources.

?When developing IT strategic plans, organizations should evaluate whether the plans are fully aligned and consistent with the overall organizational goals and objectives. Information technology departmental management, along with the IT steering committee and the strategy committee, play a key?role?in the development and implementation of these plans. Effective IT strategic planning involves consideration of the organization’s demand for IT and its IT supply capacity. Determining IT demand involves a systematic consideration of the organization’s strategic intentions, how these translate into specific objectives and business initiatives, and what IT capabilities will be needed to support these objectives and initiatives. For example, if the bank is anticipating substantial growth or acquisition, the IT capabilities must have resource capacity for these future activities. Conversely,?if?the bank is divesting businesses, increased consideration may be focused on how data assets are protected as IT functionality (and perhaps systems) are carved out of the existing organization. In assessing IT capabilities, the existing system’s portfolio should be reviewed in terms of functional fit, cost, and risk. IT supply planning involves assessing the organization’s technical?IT?infrastructure and key support processes to determine whether expansion or improvement?is necessary. It is important that the strategic planning process encompasses not just the delivery of new systems and technology, but considers the returns being achieved from investment in existing IT infrastructure.

?

Personnel Management

Personnel management relates to organizational policies and procedures for hiring, promotion, retention, training, and termination. The effectiveness of these activities as they relate to the IT functions can impact the quality of staff and the effective performance of IT duties, and potentially impact related controls (e.g., successful removal of access from terminated personnel). An organization’s hiring practices are important for helping ensure that appropriately skilled personnel are hired, and the bank is in compliance with legal recruitment requirements.

?

Sourcing Practices

Sourcing practices relate to the way in which the bank will obtain the IT functions required to support the business. Organizations can perform all of the IT functions in-house (known as “insourcing”) in a centralized fashion or outsource some or all functions across the globe. The sourcing strategy should consider each IT function and determine which approach allows them to meet the overall organizational goals.

?Delivery of IT functions can include:

1. Insourced — Fully performed by the organization’s staff.
2. Outsourced — Fully performed by the vendor’s staff.
3. Hybrid — Performed by a mix of the organization’s and vendor’s staff.

IT functions can be performed across the globe, taking advantage of time zones and differing labor rates, and can include:

1. Onsite — Personnel work onsite in the IT department.
2. Offsite — Personnel work at a remote location in the same geographical area.
3. Offshore — Personnel work at a remote location in a different geographic region.

?

The bank should evaluate its IT functions and determine the most appropriate way to deliver these services and capabilities, giving consideration to:

• ?Is this a core function for the organization?
• Does this function have specific knowledge, processes, and personnel that are critical to meeting its goals and objectives, and that cannot be replicated externally or in another location?
• Can this function be performed by another party or in another location for the same or lower price, with the same or higher quality, and without increasing risk?
• Does the bank have experience managing third parties or using remote/offshore locations to execute IT or business functions?
• For functions that are outsourced, can we obtain evidence of the effectiveness of their control structure (e.g., Type II SAS70 report, etc.)?

As a note, while efficiencies can be gained through outsourced arrangements, careful consideration of these agreements should be given as, in many instances, they result in moving some level of an organization’s IT controls to outside parties. Therefore, at a minimum, agreements must include comprehensive service-level agreements, methods used to control the inappropriate dissemination of privileged information and system access by the outsourcers’ staff, and a right-to-audit clause in the contract.

?

Business?Continuity/Disaster Recovery

Business Continuity Planning (BCP) and Disaster Recovery Planning (DRP) are processes that help organizations prepare for disruptive events, ranging from natural disasters such as a hurricane to localized events such as a power outage. Generally, a high-level strategic executive should be responsible for overseeing those involved with documenting potential events, defining a comprehensive response, overseeing mock tests for the defined responses, and modifying those plans accordingly to help ensure all areas of the business are adequately addressed throughout an integrated BCP/DRP program. Each business area will best understand and be able to contribute its specific needs to a comprehensive recovery program. However, the IT department should be involved with many of the areas because they are responsible for providing support functions to almost all of the business operations.

Disaster Recovery is the process by which business resumes after a disruptive event, generally through restoring critical information and systems. The event could include anything from an earthquake to malfunctioning software caused by???a computer virus. BCP suggests a more comprehensive approach to ensuring the bank is able to continue the core business operations over time, not only after a natural calamity, but also in the event of smaller disruptions, such as the departure of key personnel, supply chain partner issues, etc. Despite these distinctions, the two terms are often married under the acronym BCP/ DR because of their many common considerations.

BCP/DR plans should detail how employees will communicate, where they will go, and how they will continue to perform their duties. The details can vary greatly, depending on the size and scope of a bank and the manner in which it operates. For some businesses, issues such as supply chain logistics are most crucial and are the focus of the plan. For others, IT may play a more pivotal role, and the BCP/DR plan may?have?more of?a focus?on systems recovery. Neither element can be ignored, and physical, IT, and human resources plans cannot be developed in isolation. While the scope of IT audit might include review of a BCP or DR, the broader scope invariably involves other types of audits (operational, etc.). For example, the IT audit may focus more closely on how data is retrieved, restored, and available to personnel, while an operational component of the audit may focus more closely on how disasters are communicated, how employees are kept safe, and how they continue paying personnel.

?

Change Management

The change process itself consists of a series of sub-processes encompassing areas such as:

• Change Request.
• Change Review.
• Change Development.
• Change Testing.
• Change Approval.
• Change Deployment.
• Post-change Follow-up and Validation.

The change management process begins with requesting proposed changes to systems. As changes to the IT environment (whether to infrastructure items such as databases or to application code to modify the processing of transactions) can have a major impact on the overall integrity of the environment,?any change can pose a significant risk to the organization. For this purpose, there should be a methodology for prioritizing and approving system change requests. Change requests may be initiated from users, operational staff, or system development/maintenance staff. Authorization should be obtained from appropriate stakeholders, which can include the business process owners and IT personnel. For example, for acquired systems, a vendor may distribute periodic updates, patches, or new release levels of the software. Changes of this type are frequently referred to as “patch management,” but should follow a defined and documented process just as any other change to a system as they present the same types of risks and can have the same potential impacts on the environment if not managed correctly. User and systems management should review such changes and determine whether they are appropriate for the bank and whether or not they will negatively affect existing systems.

Requests to make system modifications should be communicated via a documented system that could include a formal change tracking system or, in some cases, a less sophisticated method, such as hard copy change request forms, memos, or e-mail. The request generally includes, at a minimum, the requestor’s name, date of the request, date the change is needed, priority of the request, a thorough description of the change request, testing detail, a description of any anticipated effects on other systems or programs, and evidence that the request has been approved and reviewed by authorized personnel. The change request could also provide a reason for the change, a cost justification analysis, and expected benefits. Before the change is migrated to the production environment, it should be subject to testing by relevant stakeholders. For example, if an operating system patch is applied, testing may be performed by IT personnel in a test environment to help ensure it is functioning as anticipated and the existing functionality (including the functioning of security) has not been negatively impacted. If an upgrade to a database or application were applied, in addition to any testing performed by IT personnel, it may be appropriate for the users to perform testing to help ensure that the new application functionality and/or database structure functions as intended and existing functionality has not been negatively impacted. The organization’s policies and procedures for change requirements should be explicitly documented and should specify the requirements for each type of change.

Change requests should be in a format that helps ensure all changes are considered for action and that allow management to easily track the status of the request. This is usually accomplished by assigning a unique control number to each request and entering the change request information into a computerized system, but it also can be performed manually.

?

User Provisioning and Segregation of Duties (SOD)

User provisioning refers to the process of assigning, modifying, and removing user access to systems based on current job responsibilities. Users are generally assigned new access when they join the bank or if they switch job responsibilities. They generally have their access modified within a particular system when changing job responsibilities within the bank or removed when they change job responsibilities within the organization, resign, or, in the case of contractors, their assignment ends.

The methods that organizations employ to manage this process are varied, but most use either manual (e.g., the user’s manager manually notifies the various system administrators to change access) or automated (e.g., the human resources system automatically disables network access on the termination date via an automated process).

The bank should have a defined process for their user provisioning activities. The defined process should include guidance regarding how access changes are requested, the level of detail that is specified in the change request, and who is authorized to approve such changes. When assigning new systems access, it is important to specify a sufficient level of detail. For example, a new user request for a financial system that states “add access like John Doe” can be problematic in that the approver might assume incorrectly what type of access the existing person really has.?One approach to addressing this issue?is to create “roles” rather than “users” for systems. In using role-based access control, each job or role within a bank (e.g., finance supervisor or HR specialist) has a defined set of tasks or activities to perform, and the rights or authorities necessary to access or perform those tasks are collected together as a “role,” which is then assigned to a user rather than the individual rights being assigned to each user. This simplifies the need to administer individual users separately, aids in ensuring conflicts related to segregation of duties are considered, and allows a change in job responsibilities to be easily applied to all affected users with a single change to the role template. A critical concept to keep in mind when looking at the user provisioning process is that the creation and assignment of user capabilities should be performed by a function independent of the affected business unit to reduce the risk of fraud, enforce segregation of duties, and help ensure that appropriately trained and knowledgeable individuals are the only people making changes to a system.

Many?organizations struggle with keeping system access current based on job responsibilities. In addition to the preventative control of approving new and modified systems access, it is often wise to implement a detective control in the form of periodically reviewing system access to help ensure it remains appropriate based on job responsibilities. This type of review should include a sufficiently detailed report with which to review access and should be reviewed by a relevant process owner (e.g., controller for super user access within a general ledger application). As important as keeping appropriate access current and periodically reviewed is the timely removal of access when a user changes job roles or separates from the organization. Such removal is critical to prevent unauthorized access, particularly to sensitive or valuable information.

Job titles and organizational structures vary greatly from one bank to another, depending on the size and nature of the business. However, it is important for an IT auditor to obtain information to assess the relationship among various job functions, responsibilities, and authorities in determining if adequate SOD is in place. SOD avoids the possibility that a single person could be responsible for functions such that errors or misappropriations could occur and not be detected timely in the normal course of business processes. For example, a bank might not want a system administrator to review audit logs that include their own activities. Another example might include users who can create vendors, approve invoices, and print checks. SOD is an important means by which fraudulent and/or malicious acts can be discouraged and prevented.

SOD conflicts within a particular bank should be explicitly documented. Ideally, this occurs before creating roles within applications such that any inherent SOD conflicts (roles that, by default, contain SOD conflicts) can be modified before assigning those roles to users. From a preventative perspective, SOD conflicts should be evaluated before assigning access, either through an inherent SOD conflict as mentioned above or through the assignment of multiple roles that cause a SOD conflict. In addition, the periodic review of access mentioned above within the user provisioning description can be used to review any potential SOD conflicts not previously detected. In conjunction with segregating conflicting job roles within the IT function, it is critically important to make sure there are no user IDs shared by multiple users, as this can cause a segregation-of-duties conflict when IDs with separate role responsibilities are used by a single user (this is known as “aggregation” and should be avoided). Sharing IDs also eliminates one of the key purposes of the use of unique IDs, which is the ability to determine who is accountable for actions taken within the system. Where SOD conflicts are unavoidable due to business constraints, the specific roles and users should be identified as high risk, and mitigating controls (most commonly monitoring in nature) should be designed and regularly tested

This segregation is critically important for a strong IT control environment, as inappropriate or poorly tested changes are often the root cause of system disruptions or outages at organizations. Conversely, business?areas?often have numerous segregation-of-duties controls implemented through specific application system access privileges. Understanding of these controls and responsibility for their enforcement generally resides in the respective business unit, with monitoring assistance provided by IT (e.g., user access listings). Similar to IT segregation of duties, business application systems access controls are often the subject of an integrated audit (defined in more detail later in this article).

As you conduct IT audits, you may find a significant challenge in many large organizations, because segregation of duties control sustainability is reacting to the movement of?individuals and modifying their system access timely??as they change job roles. Changes in personnel or roles often require corresponding changes to systems. This challenge requires optimal coordination between HR, IT, and the business units to manage the risk effectively.

?

Configuration Management

Configuration management refers to creation of a baseline and change management process for configurable settings within the various IT systems. These settings can include security-related items, such as password parameters and auditing configuration, and application configuration, such as three-way matching or chart of accounts settings.

?The initial baseline for these settings is similar to creating documented policies within an organization. It serves to instruct process owners of management’s intent when configuring systems. It also serves as a guide when replicating well-controlled environments.

Configuration management is inextricably linked to the overall change management process. When implementing new systems, the systems should be reviewed to help ensure they comply with existing baseline settings. When modifying an existing system, not only does the newly modified system need to be compared to the baseline settings while being tested in the test environment, but an assessment needs to be performed to determine whether any additional settings need to be added to the baseline configuration (e.g., a newly updated system might contain a newly created parameter, which must be considered). For these reasons, many organizations mandate that configuration changes be incorporated into their overall change control process to help ensure they are reviewed, tested, and approved in accordance with the organization’s procedures and policies.

There are some automated tools that can capture a snapshot of system configurations. These tools are useful not just in assisting with documenting current configuration, but also creating alerts when key configuration settings are modified. This latter portion of the functionality may serve as a key control in mitigating risks related to modification of such settings.

?

Operations

Operations refers to the day-to-day activities of the IT function and encompasses such activities as job scheduling (the processing of computing activities that are automated and occur at predefined times of the day, such as a backup that occurs overnight), problem management?(sometimes?also?referred?to as the helpdesk), incident management, daily maintenance and updating of systems, and all of the other routine procedures that are carried out by the IT department. Operations also can include the design and implementation of computing environments, and the budgeting, management, and oversight of the IT function itself.

Operations can be performed solely in-house, co-sourced with specialist vendors, or outsourced entirely to IT service organizations. However, the operations are handled within an organization, there should be documented policies, processes, and procedures to provide guidance to those responsible for the IT services needed by the organization.

?

Security

Security can be broken into two broad categories: logical and physical. Physical security encompasses access to, and the protection of, tangible items such as computer hardware, specific locations such as a data center, employees such as IT operations staff, and other physical objects. Logical security refers to the protection of access to non-physical elements such as computer files, system activities, areas of computer networks, and other intangible aspects of an IT environment through the use of software safeguards such as access controls, authentication mechanisms, authorization rights, and systems auditing. Logical security typically includes both configuration elements such as role-based access controls and device-based elements such as firewalls and intrusion prevention systems. IT security is a component in every aspect of the IT environment and is commonly audited both as a specific subject in its own right and as an element of other audits as well.

?

Monitoring

The term “monitoring” can be used to describe two different things. The first is monitoring the actual IT environment. An example is monitoring the health of the network to ensure availability. Another type of monitoring entails monitoring controls for effective operation. An example of this type of monitoring might include reviewing audit logs of network traffic for the effectiveness of the firewall configuration.

For the first type of monitoring, processes should be defined for conditions that support the effective operation of the system. Examples of this type of monitoring might include network monitoring, application batch job monitoring, and data backup monitoring. The purpose in monitoring these areas includes helping to ensure system availability, complete and timely recording of transactions, and recoverability of data, respectively. Most often, automated tools are used to schedule jobs, review performance, and help ensure appropriate access authorization. Use of such tools is generally complemented by manual controls performed by management and/or users to review the output of such tools. In addition to the primary function of monitoring the systems, these related areas (use of automated tools, manual review of output, restriction of privileges to modify the tool, etc.) act as complementary controls. For example, if the automated tool used for monitoring is not designed/configured effectively or the ability to modify its configuration is not restricted appropriately, the effectiveness of the review of output is reduced.

The monitoring activities discussed above can directly affect business process controls. For example, batch jobs cause application system programs to be executed. If such programs terminate abnormally (i.e., before the full set of programs has been completely executed), the transaction may not be recorded completely or accurately. Similarly, if certain programs that are necessary for online transactions or batch jobs are not executed, the related items will be inaccurately or incompletely recorded. For example, there might be a batch job that would transfer transaction data from a subledger to the general ledger.

If that program does not transfer all data or does not record it for the correct period near a period end, the completeness or cutoff of those transactions may be impacted.

For the second type of monitoring (also referred to as auditing or logging), tools are generally used by administrators to allow them to take periodic snapshots of the system, identify specific configuration changes or use of “super user” or “emergency” accounts, and assist in resolving any potential control issues. Generally, systems have the ability to log specific events such as unauthorized access attempts or updates to key data. Reports can be periodically generated and timely reviewed by security management and/or system owners. Unauthorized users may access and modify data without detection if violations are not researched timely. Organizations sometimes struggle with the perceived conflict between logging enough information to satisfy audit requirements while not overburdening the system resource constraints by logging mass amounts of data. If correctly designed, the configuration of audit trails should be exception based. For example, logging all purchase orders where there is a large volume of activity may not be useful for reviewing. However, reviewing purchase orders that are of an exceptionally large dollar amount or related to a specific type of procurement (e.g., capital expenditures for assets) would entail a much smaller audit log and be more practical and useful for the reviewer. Similarly,?organizations sometimes grant high-level access to?IT personnel for emergency purposes. A common mitigating control for the inherent risk in that type of access is to log and review any instances of usage. In theory, the usage should be minimal, and, therefore, the related logging should have a limited system impact.

Integrated Auditing

An integrated audit considers IT, financial, and operational controls as mutually dependent for establishing an effective and efficient internal control environment. When performing an audit, one overall objective is to determine whether controls are effective and efficient in supporting the underlying business processes. As opposed to other types of audits (e.g., financial, operational, compliance), IT audits are unique in that it is sometimes more difficult to tie them directly to an underlying business process. For example, an IT audit may be performed for network security. The underlying business processes that are supported by network security could potentially encompass all business processes that use data transmitted over the network. The implication of this distinction is that findings from an IT audit are not as easily quantifiable when determining their impact in terms of financial, operational, or compliance outcomes.

When performing a financial or operational audit, the objective is to determine whether financial and operational controls are effective and efficient???to support the business process. Often the controls within a financial, operational, or compliance audit rely on supporting IT controls. For example, a three-way match may be configured within an accounting application to accurately match purchase orders, invoices, and receipts. When performing a financial audit, the reviewer may validate that the configuration is in compliance with corporate guidance. However, the successful implementation of that control is contingent on a sound IT environment. If the underlying database is not secure, it might be possible to modify that setting without detection for a period of time. If the auditor determined that the underlying database security was weak and this parameter could have been modified, but not detected, how do you assess the risk that this action occurred? How do you quantify the outcome? For these reasons, within an integrated audit, all perspectives need to be considered because IT, financial, and operational issues can impact the achievement of management’s objectives of safeguarding information system assets and ensuring the reliability and integrity of information.

?The IT portion of an integrated audit includes the applications, servers, and network configurations that support the business process. For example, the IT, financial, and operational auditors collaboratively consider the following as they relate to the business process being examined:

?

• The business and information processing risks and controls are understood and agreed upon by the business owners, IT delivery and support organization, and the integrated audit team.
• Manual and automated feeds, system interfaces, and communications are accurate, timely, and secure.
• Manual and automated transactions are approved timely and accurately processed.
• Information is secure and privacy controls are in compliance with current regulations and industry standards.
• Disaster recovery plans and business continuity plans provide reasonable assurance that both the system and business operations can recover and continue when a system or business interruption occurs.
• Program changes are authorized, tested, approved, and migrated to production as prescribed by the business process owners.

With all IT audits, though perhaps most critical with the integrated audit approach, is the need to understand the IT environment and structure of the audit area. IT environments are often a complex combination of applications, servers, network components, databases, and interfaces spanning multiple areas of the organization. An initial way to visualize and organize this structure is to separate the IT infrastructure, which includes operating systems, databases, and network components, from the application systems (e.g., a Treasury system).

??

Simplified Representation of the Common Elements of an IT Environment

Generally, responsibility for the IT infrastructure?will?be?the?function?of the IT department, whereas responsibility for?the application systems will??be within the associated business process or functional area. These responsibilities include ensuring the IT and financial and operational controls are implemented, effective, and efficient.

The business process owner, typically along with the chief information officer (CIO), is ultimately responsible for ensuring the IT and financial and operational controls are implemented, effective, and efficient. Regardless of the overall type of audit being performed, for a comprehensive IT audit, each of the areas outlined in the previous sections (IT strategy through monitoring) should be considered when defining the IT audit scope.

?

Continuous Auditing

The focus on increased effectiveness and efficiency of assurance, internal auditing, and control has spurred the development of new studies and examination of new ideas concerning continuous auditing, as opposed to more traditional periodic auditing reviews. Several research studies and documents addressing the subject use different definitions of continuous auditing. All of them, however, recognize that a distinctive character of continuous auditing?is the short time lapse between the facts to be audited and the collection of evidence and audit reporting. Typically, the collection and evaluation of transactions is automated.

The traditional method of auditing entails performing reviews at defined intervals (e.g., annually, biannually, quarterly, etc.). Due to the periodic nature of reporting during these audits, by the time the findings are published, the process owners may have a much larger set of issues to resolve and management has a more limited amount of time to find timely resolutions to the audit findings. In the context of a financial audit, this can be especially problematic as the audit findings may impact the financial statement audit strategy (e.g., level of substantive testing) and/or the periodic assertions (e.g., Sarbanes-Oxley, OMB A-123, etc.). Conversely, if continuous auditing methods are employed, control exceptions are predefined and relevant parties are notified in real-time. The timely nature of these notifications allows decision makers and process owners not only the ability to correct the initial issue proactively (before being flagged by an auditor), but they can design and implement any additional preventative controls that might be required to avert further instances from occurring in the future.

Another benefit of continuous auditing is for the auditors themselves. When continuous auditing methods are employed, the procedures performed to test the effectiveness of controls can be more efficient. Most audits entail testing a combination of automated controls (e.g., configuration that does not require a sample) and manual controls (e.g., sample-based controls). When continuous auditing is employed, these generally fall into the configuration or “sample?of one” category. The auditor can review the auditing configuration and then trace a “sample of one” to validate that it is functioning as intended. Assuming the configuration is designed effectively, there would be no need to test a larger sample of transactions. For example, a bank might implement a control, such as a corporate policy, to limit journal entry approval for particular personnel for defined dollar amounts. Traditionally, an auditor might select a sample of journal entries to determine whether they were approved in accordance with the defined policy. If the control were an automated control (i.e., the configuration of personnel and dollar amounts were defined in the application system), the auditor might inspect the configuration to validate that it conforms with the corporate policy and then review one journal entry to validate that it follows the logic of the configuration. However, there are often instances where management override exists or someone has additional access to function as a backup for the primary user. If a continuous auditing method were employed, such that all instances of noncompliance with the policy were automatically routed to an appropriate reviewer, the auditor would only need to review the automated monitoring configuration and then check the audit trail and/or logs to see that no instances had occurred during the relevant time frame. In theory, continuous auditing can serve as both an effective preventative control and a more efficient audit means.

Some of the drivers of continuous auditing are a need for better monitoring of controls that support the financial reporting objectives, ensuring that real-time transactions also benefit from real-time monitoring, and the use of software to determine that financial, operational, and compliance controls are operating effectively. Another potential benefit of continuous auditing is that it addresses a higher percentage of the population of transactions. As mentioned previously, traditional auditing methods entail selecting a sample of the population and then extrapolating those results to determine the operating effectiveness of the related control. With continuous auditing methods, the process owners and the audit personnel can validate the operating effectiveness for a much larger percentage of the population (in some cases, perhaps, the entire population for a given period) with the same or less effort. This is due to the exception-based nature and real-time monitoring with this approach. Continuous auditing is not a recent development. Many robust applications contain embedded modules with the ability to configure and use continuous monitoring. These would allow an auditor to identify predefined types of events or directly inspect abnormal or suspect conditions and transactions.