Solutions

What is ICAM?

ICAM is an enterprise Internal Control and Audit Management System. The Internal Control System provides the enterprise with a transparent overview based on supervisory controls as its focal point therefore allowing a more effective and efficient control coverage in addition to enabling management responsibility from an oversight perspective. The Audit Management System allows the Enterprise Audit Committee to monitor the progress of completion of all recommendations as a result of internal and external review reports.

Internal Control

Effective internal control helps enterprises to cope with shifting environments, evolving demands and priorities. Within an enterprise regulations change, operational processes are improved and new technological developments are deployed so management must continually assess and evaluate the internal controls to assure that the control activities that are being used are effective and when necessary updated. ICAM enables management to monitor assets, prevent fraud, minimize errors, verify the correctness and reliability of data, promote operational efficiency, and ensure that established managerial policies are followed.

Audit Management

This allows management the ability to track all shortcomings based on a periodic review, both internal and external. After an investigation, a report is produced outlining all shortcomings the auditors found during their review. This report containing the findings, recommendations and the managements responses is held within the Audit Management System thereby enabling oversight of the issues raised with respect to agreed deadlines and implementation by the Enterprise Audit Committee. The target of this is to prevent similar shortcomings in the future and secondly to minimize the risks, be they regulatory, financial, reputational, etc., that can have a major effect on the enterprise. To enable the Enterprise Audit Committee to fulfill its mandate the functions of the system enables management to monitor centrally all reviews and to ensure a timely and satisfactory resolution of the issues raised.

Segregation Of Duties

A fundamental element of internal control is the segregation of certain key duties. The basic idea underlying SOD is that no employee or group of employees should be in a position both to perpetrate and to conceal errors or fraud in the normal course of their duties. In general, the principal incompatible duties to be segregated are:

• Custody of assets
• Authorization or approval of related transactions affecting those assets
• Recording or reporting of related transactions

It is important that enterprises start to focus on segregation of duties (SOD) due to the amount of guidance being issued such as the U.S. Public Company Accounting Oversight Board’s Audit Standard No. 5, the American Institute of Certified Public Accountants’ (AICPA’s) Statement on Auditing Standards No. 99, and the U.S. Securities and Exchange Commission’s (SEC’s) Guidance Regarding Management’s Report on Internal Control Over Financial Reporting, the SEC and the AICPA to name but a few.

Traditional systems of internal control rely on assigning certain responsibilities to different individuals or segregating incompatible functions. The general premise of SOD is to prevent one person from having both access to assets and responsibility for maintaining the accountability of those assets.

For internal control to be effective there needs to be an adequate division of responsibilities among those who perform control activities and those who signoff those activities. In general, the flow of transaction processing and related activities should be designed so that the work of one individual is independent of, or serves to check on, the work of another. These types of arrangements reduce the risk of undetected error and limit opportunities to misappropriate assets or conceal intentional misstatements in the financial statements. SOD serves as a deterrent to fraud and concealment of error because of the need to recruit another individual's cooperation, via collusion, to conceal it.

ICAM automatically enforces segregation of duties thereby enabling the enterprise to be fully compliant with the latest guidance from such regulatory authorities. The assignment of tasks via the scheduler ensures that the same employees are never assigned to both the execution and signoff tasks thereby ensuring SOD.

Even though ICAM enforces segregation of duties it is possible to switch this off on a control-by-control basis. Naturally warnings are issued to the control owner to indicate the possible issues that could arise out of switching this option off. Top level management are kept in touch with option of real time online drill down functionality to the underlying controls so that they can make educated decisions based on what is contained within the controls. In addition a predefined management report outlining the controls that do not conform to SOD is also available and can be scheduled on a user-defined basis.

Zone of Responsibility (ZoR)

A user has a Zone of Responsibility if they are assigned as an owner of a node in a pyramid. From an organizational perspective this could be a regional, sector or department head for example. In an alternative pyramid this could be heads of product categories, e.g. Hardware Sales, Software Sales or Services, whereby the product category cuts across the organization effectively making a matrix type organization. This is all supported and part of the standard solution of ICAM.

If a user has been defined as responsible for a "Zone" within a pyramid structure then they can request reports based on any of the underlying nodes of that structure. This means that they can report on the controls, execution tasks and audit issues within their "Zone of Responsibility". All of the following have a Zone of Responsibility as the authorization reference.

ZoRs have two ways to view the data.

• Online via management functionality giving aggregate functions and drill down functionality for example to real time aggregate of Execution Tasks.
• Via Background Reporting – whereby ZoRs are able to schedule reports

Role Assignment

Pyramid Administrators

There are two types of administrator in a pyramid. Those who are assigned directly at the top of the pyramid have exactly the same functional rights as the pyramid owner. Administrators assigned below the top are not allowed to assigned additional administrators.

A Review Type points to the group of employees who "manage" this type of review in addition to the setup details for the Review Type.

The above allows decentralized management throughout the ICAM application.

Regional Visibility Restrictions

The visibility concept in ICAM not only limits what an employee can see from another region but also determines whether an administrator of one region can switch to a employee of another region. A typical example is that if a employee is "Swiss" based and the data is stored in Switzerland then no employee external to Switzerland is allowed access to this data. This effective means that the administrator cannot login as a "Swiss" employee and override the legal and regulatory requirements for Swiss based data.

An example of such a setup could look like:

All execution task detailed data is restricted to the region that the user entered the data in.
Aggregated data can be shown across the enterprise as this does not point to an "individuals" data. Therefore it is possible to run reports over an enterprise to get the aggregated data but no "details" will be shown for that data.
Regional visibility rules can be set that override the regional restriction.

Execution Task Assignment

The assignment of employees to tasks can be done wither directly or indirectly. Direct assignment means that the activity points to a specific user. The task will always be assigned to this user.
Indirect assignment does not point to any specific user in particular. It points to a position in a pyramid where the Control Owner has defined the rules for selecting employees.

Indirect -
Pro: Assignment changes as the organization changes. For large organizations with automated employee and organization overnight batch updates the benefits of Indirect assignment becomes clear as most of the work has been completed outside of the application in a central HR department and the application uses this master information to maintain the structure. Controls based on this structure automatically change as the structure changes.
Pro: No changes to Control are required for changes in the organization structure.
Con: Only possible to see the assignment definition at a point in time as this can change on a day-by-day basis.

Direct -
Pro: The Control Owner always know to whom the control will be assigned.
Con: When a users moves department or leaves the organization, or the organizational structure changes the Control probably needs changing.
Con: Overhead of maintaining controls is much greater than an indirect assignment

Scheduling

Scheduling is Activity based NOT Control based. This allows a control to have several activities with different schedules. The idea is that instead of having multiple controls exactly the same except for the schedule we keep them together. This allows a low level manger to say complete on a monthly basis a check that employees under his control have complied with the "Employee Time Reporting" guidelines. On a quarterly basis the senior manager also needs to complete the control based on the lower level managers. This way the same control is used and only the schedule is different.

Scheduling is done on a Weekly, Monthly or Yearly basis with a relevant frequency. e.g. Schedule "Weekly" with a  frequency of 2 means every 2 weeks the activity will be scheduled. In this way we would select "Monthly" with a frequency of 3 or 6 for quarter or half-yearly scheduling.

We have activities and these activities can have a combination of definitions for creating execution tasks. These definitions are for

Support
Execution
QA
Signoff

Support == this is used to define a task(s) that will be created to help to aggregate information for the preceding Execution Task. It is not possible to have a Support without an Execution Definition since the whole purpose of the Support is to prepare in advance the documents/information required for the users of the execution tasks.

Execution == this is Mandatory for an Activity. We do not need a support task and all following tasks (QA, Signoff) require there to be an Execution Task to either do the QA on, or Signoff. This definition is used to assign all users, either directly or indirectly, to Execution Tasks. The Execution Tasks are used to determine that the controls that have been setup with the application for the associated enterprise policies have been adhered to.

QA == this is used to define a task(s) that will check the information entered by user in the Execution Tasks. It is possible to reject incomplete tasks at this stage and have the user complete a new task, which will also be review once again by QA user(s). This is can be used as a two stage signoff whereby the QA is in effect the first stage of the two stage signoff.

Signoff == this is used to define a signoff for all execution tasks.
If a QA definition exists then the Signoff will only be allowed to take place once the QA has been completed. A Signoff can reject Execution Tasks that the user determines are not satisfactory and a new Execution Task will be created that will be required, as defined for the activity, to satisfy possibly both QA and Signoff.

Here is a diagram of what can be scheduled.

What is a Chain?

What does a breaking chains achieve?

This allows the QA or Signoff tasks to run in parallel. This means that for example the signoff task can complete the signoff of execution tasks as soon as they have finished and not wait until they have all finished. See below

This allows the user who is doing the signoff to have 99% of his work completed whilst the slow user does not hold him up.  However in both scenarios his task will not be completed before user 3 has completed his task.

Execution Task Re-assignment

No system can work 100% autonomously since it is sometimes not possible to know in advance to whom some execution tasks should be assigned, e.g. an employee leaves and a new replacement arrives one month later. Maybe a task has been assigned to a user but that user has now been sacked. The person taking over the role will be required to complete the task.

For these types of unforeseen problem this functionality allows an administrator with the relevant "Re-Assignment" role to assign an execution task from one employee to another. All relevant data based on the original user will stored as part of the records history.

Audit/Reviews

The application supports all types of reviews, from internal audits, external audits, regulatory deficiencies letters, Credit Risk reviews, etc. All of these can be input into the application for documentation purposes. In addition issues raised on these reviews can be tracked to
resolution. In addition the application allows for Issue Implementation Resolution Planning whereby employees of the enterprise are assigned activities to complete by a specified deadline in order to resolve the issue. Issue Owners track the resolution of the activities so that they can see the percentage completion of the issue. All of these details are also available to internal auditors for "Internal Audit" issues based on the applications visibility restrictions.

The basic implementation

The application can be used as a review documentation repository. All reviews can be entered into the application and retrieved based on various criteria. A review comprises of findings that are further split into recommendations. This audit type of structure can be found across all industry types for example:
Legal Services Corporation Office of Inspector General, Compliance with Selected Regulations, https://www.oig.lsc.gov/scar/rupxvii.htm
Audit of the New York City Department of Housing Preservation and Development's Enforcement of the Housing Maintenance Code, http://www.tenant.net/Oversight/Codeenf/codefind.html
Australian Government, Department of Infrastructure, Transport, Regional Development and Local Government. ICAO Audit Findings and Recommendations Relating to Aircraft Operations, http://www.infrastructure.gov.au/aviation/safety/icao/plan3.aspx
Bank of Jamaica, Audit, http://www.boj.org.jm/bank_audit.php
Report On Audit Of Internal Controls Over The Office Of Personnel Management's Travel Card Program, http://www.ignet.gov/randp/cards/OPM%204A-CF-00-01-102.pdf

The recommendations are further split into issue(s) that need to be resolved.

Issue Resolution Tracking

Once a review has been entered and the issue is flagged as active then the employee responsible for the issue is notified of the issue. The assigned person is responsible for the resolution of the issue. Management can track these issues and see how the resolution of the issue is progressing.

Issue Implementation Resolution Planning

Issue responsibility is not delegatable. Responsibility of the issue always stays with the Issue Owner as defined within the review. He can delegate activities, i.e. work, that need to be completed in order to resolve the issue by the specified deadline. Both the Issue Owner and management can track activities, issue automated reminders, etc. to get the activities completed by the agreed deadline therefore helping to avoiding any unforeseen overruns.