BLOG.SANDERSCONSULT.COM

A New Plan for Global Accounting Standards

Denise Sanders — Tue, 24 Aug 2010 14:56:00 GMT

The FASB and IASB revised workplan for the convergence of standards

On June 24, 2010, the US Financial Accounting Standards Board ( FASB ) and International Accounting Standards Board (IASB ), in a letter and progress report to the G20 Leaders Summit, issued a revised work plan on the convergence efforts for a single set of global accounting standards. They noted the previous emphasis that the G20 placed on the convergence timeline at the September 2009 Summit: “We call on our international accounting bodies to redouble their efforts to achieve a single set of high quality, global accounting standards within the context of their independent standard setting process, and complete their convergence project by June 2011.” In their June 24, 2010 letter they note the importance of the effort, but cite the concern of stakeholders of “their ability to provide high quality input on the large number of major exposure drafts that were planned for publication in the second quarter of this year.” Therefore they revised their plans, keeping the previous milestone goal of June 2011 for certain projects considered to be higher priority and extending the milestone targets for what are considered lesser priority projects by six months.

Below summarizes the three main points of the modified plan and a table summarizing the modified milestone target dates for the convergence projects.

Modified strategy and work plan

1. Prioritized projects

The Boards prioritized the major projects in the original Memorandum of Understanding (MoU) to provide more impact in the short term on those projects which were considered to bring about the most significant improvement and convergence of IFRS and US GAAP.

These projects include: financial instruments, revenue recognition, leases, the presentation of other comprehensive income, and fair value measurement.

2. Phased publication of exposure drafts

Stakeholders were concerned about the fast pace at which standards were going to be published and whether this would produce acceptable quality standards in such short time and whether stakeholders would have sufficient time to review the overwhelming number of exposure standards to provide quality feedback. Therefore the Boards spaced out the publication of exposure drafts and related public round-table meetings to allow more time for stakeholders to provide comprehensive, quality feedback. They also limited the number of significant or complex exposure drafts issued in any one quarter to four.

3. Stakeholder input on effective dates and transition

The Boards will issue a separate document requesting stakeholder input about effective dates and transition methods. The Boards recognized that there is a significant amount of change involved in implementing the converged standards and therefore will be consulting with stakeholders to establish reasonable effective dates and transition plans.

Milestone target dates for converged standards

Project

Exposure Draft

Comments due

Public Round-Table Meeting

Final Standard

“Priority” Projects from MoU

Financial Instruments

FASB 5/26/10

IASB Q3 2010

9/30/10

Q4 2010

Q2 2011

Presentation of Other Comprehensive Income

5/26/10

9/30/10

Q4 2010

Revenue Recognition

6/24/10

10/22/10

Q4 2010

Q2 2011

Leases

8/17/10

12/15/10

Q2 2011

Fair Value Measurement

6/29/10

9/7/10

Q1 2011

Lesser priority projects

Consolidations

Q4 2010

Q3 2010

Q2 2011

Derecognition

IASB Q3 2010*

Balance sheet Netting of Derivatives and Other Financial Instruments

Q4 2010

Q1 2011

Q2 2011

Financial Instruments with Characteristics of Equity

Q1 2011

Q3 2011

Q4 2011

Financial Statement Presentation – main project

(Staff Draft 7/1/10)

Q1 2011

Q3 2011

Q4 2011

Presentation of Discontinued Operations

Q1 2011

Q4 2011

Post-employment Benefits

IASB 4/29/10

9/6/10

Q1 2011

Insurance Contracts

Q3 2010

Q2 2011

Emissions Trading Schemes

2^nd half 2011

2012

Source: Quarter milestones compiled from the FASB/IASB June 24, 2010 Progress Report and updated with actual publish dates as of 8/20/10.

* IASB will finalize improved disclosure requirements similar to those in US GAAP. Then in 2012 the FASB will conclude its post-implementation review of the application of its amended derecognition requirements. The board will make a decision about any further convergence efforts.

Download or print article

Failures of Project Management - Why common practices still fall short

Denise Sanders — Tue, 15 Jun 2010 01:24:00 GMT

Large scale corporate projects (system implementations and upgrades, consolidating operations or systems, new compliance or regulatory standards) run into preventable cost and time overruns far more frequently than they should. They do this despite implementing mitigation plans around well known risks. Below are some of the common plans used to address the top failures and how some of these project management [PM] practices sometimes fall short.

1. LACK OF PROJECT OVERSIGHT AND GUIDANCE

Common plans:
Assign a dedicated person from the organization to oversee the project and report to management.

PM Failures:
The person assigned to oversee the project was simply available or lacking a defined role in the company and does not have experience in a disciplined project management approach. Therefore, the project manager is little more than somebody to watch the vendors and raise questions and issues based on their gut instincts without good project plans to identify the real gaps. Project dependencies, schedules, and risks end up not being managed effectively across vendors and resources of the project.

Projects that will last months or years and involve multiple departments of a company need experienced project management with a defined project management methodology.

2. INADEQUATE COMMUNICATION

Common plans:
Written reports to communicate to the project sponsor(s) on the progress of the project

PM Failures:

Stakeholder representatives who have been designated to be involved in the project do not receive adequate explanation of project methodology, procedural processes (issue management, change control, training, etc.). Equally as important, these stakeholder representatives don’t always know when and how they will be involved.
Discussion of real issues and their root cause do not occur, since feedback is not solicited and the project team relies on the project management to tell them what to do real-time.

Project management should ensure that the “process” of the project and everyone’s role in the project is clearly communicated both in writing and in meetings. Issues should be looked for, discussed and understood when they occur. Proactively seeking out issues will save time and money by addressing them at the proper point. Pushing issues down the road can cause rework, missed objectives, and scrambling to make up time.

3. USERS DO NOT RECEIVE ADEQUATE TRAINING AND MAY BE RESISTANT TO THE CHANGE(S)

Common plans:
Assign a change management lead to coordinate training plans. Create a train the trainer program. Develop training manuals and presentations on how to use the new software.

PM Failures:

Too much focus on the future state and not where the users come from. Failure to identify gaps from current to future state in the design and impact to the organization.
Lack of procedural-based training. Training focuses on how to perform a function, but ignores how that function may fit into a person’s job before and after the implementation. For example, training may show how to create a purchase order in the system. Without information about new purchasing policies and procedures such as who can approve a purchase and what types of purchases are allowed, the user may be lost after go-live.

Training programs need to be defined not only based on new system functionality, but also on the changes in the organizational structure, policies and procedures, and expectations. Defining the changes and addressing each of them creates a true change management program.

4. LACK OF STAKEHOLDER MANAGEMENT COMMITMENT

Common plans:
A project sponsor is identified from the executive team of the company to ensure the message is clear that the project is important and provide high level leadership.

PM Failures:

Executive sponsor is not engaged in the project oversight.
Other senior management representing stakeholders are not involved/supportive.

While executive sponsorship is important, it is only effective if the sponsor takes an active part in overseeing the project. Sponsorship sometimes needs to include multiple disciplines of the company to effectively ensure buy-in and involvement of the necessary resources.

5. LACK OF STAKEHOLDER INVOLVEMENT IN PROJECT

Common plans:
Project team representatives are defined from all stakeholder organizations.

PM Failures:

Roles and authority are not made clear, resulting in an inability to make decisions and conclude on design.
Stakeholder organizations with a small impact from the project do not devote full-time resources and their involvement is not managed to ensure their input in sought for affected areas.

Project team roles and authority level must be defined. Processes and schedules should be segmented to identify affected departments and who must be involved.

6. DESIGN FAILS TO ADDRESS BUSINESS REQUIREMENTS

Common plans:

Requirements are defined prior to the beginning of the project in a project charter.
Project team includes users from the business.

PM Failures:

Requirements are never clearly documented such that the project can have a clear definition of success. Project specifications are incomplete because they were documented in “powerpoint” fashion, i.e. so high-level as to only be project objectives and do not actually define business requirements at a level of detail for a design. This can also lead to a potentially long design timeline to sort through requirements and poor testing since the requirements to be tested are not clear.
Too much consultant-led design causing a cookie-cutter design that doesn’t fit the business objectives.
Not enough project-experienced team leads.
Inherent requirements may not be addressed adequately without specific plans targeted at areas such as data quality, internal controls, and security.

Requirements must be documented in some form. While requirements can be defined and documented within the design phase of the project, this takes a structured approach and iterative confirmation by stakeholders. The design process may be facilitated, but should not be taken over by consultants. Testing plans need business input on the various scenarios that may be encountered, not just generic test scripts of the base functionality.

7. SCOPE CREEP

Common plans:
A statement of scope is defined in the project charter or business case based on the project objectives.

PM Failures:

Definition of scope fails to identify dependent activities to achieve objectives such as report writing or data cleansing.
Scope simply addresses changing system functionality and does not address changing the company’s policies and procedures.
A change control process is not defined to decide and resolve potential scope changes.

Initial scope must address all activities to achieve goals, not just system functionality. It must also include data changes, integration, policies, procedures, and internal controls. Change control guidelines and escalation process must be defined and utilized.

8. PROJECT RISKS COME TO FRUITION

Common plans:
A risk analysis is performed prior to the start of the project to identify risks to the project, prioritize the risks, and define how the risks will be addressed.

PM Failures:

Risks may not be re-analyzed during the project to determine whether the risk level is decreasing and whether risk mitigation plans are effective.
Risk mitigation plans are defined at too high of a level. For example: a mitigation plan for a project risk regarding project acceptance is defined as simply “training”.

CONCLUSION

Project management is not just about having a project manager or documentation for a project. Project management is a disciplined process. Every project that lasts for more than a few months or involves multiple departments should have project management. This Project management needs to include: experienced project leadership, plans, defined processes for the key phases of the project, progress reporting, stakeholder communications and stakeholder involvement. These are basic building blocks of project management. The level of management and definition for processes will depend upon the size, requirements and complexity of the project. Solid project management will result in reduced surprises, better ability to keep within time, budget and scope, and more stakeholders who will agree that the project was a success.

Download or print article

Criteria for Enterprise GRC Software Selection

Denise Sanders — Tue, 13 Apr 2010 02:32:00 GMT

Assessing the functionality of Enterprise GRC Software

Below provides a description of some of the common functionality found in Enterprise GRC Software, providing a list that can be useful for comparing products.

Functionality	Description
Data Relationships and hierarchy	Ability to organize data elements such as accounts, processes, risks, and controls into the necessary relationships to match your use and maintain in an organized hierarchy.
Assessment	Survey-based assessment, for example for the purpose of risk assessment or control self-assessment. Automated data collection and reporting of results.
Risk management/monitoring	Risk management involves identification of risks, the assessment of inherent risk impact and likelihood, identification of risk responses and management techniques, and the ongoing monitoring and re-evaluation of risk after risk responses have been implemented (residual risk).
Electronic Audit Workpapers	Organizing and structuring audit workpapers by audit and folders, managing audit steps, tracking audit time, and keeping audit trail of persons who executed and reviewed steps.
Workflow	Automated management of the sequence of events for executing work progress, tracking status and history of events. Workflow should be customizable in the setup of the system to allow you to mimic your company’s work steps.
Document management (version control)	Maintain electronic copies of documents, versions of each document change, and facilitating document check out/check in (assignment of document to a person and locking out others to provide change control).
Policy management	Document management of policies, notification of policy changes, and maintaining their relationship to related controls.
Controls and Policy Libraries	Pre-populated content from best practices developed by the vendor or regulatory content for control standards or general policies.
Test management	Create test templates for testing procedures, manage multiple test runs or rounds of testing, and monitor status of tests.
Issue and remediation management	Identify issue details, identify remediation activities, and manage the issue and remediation status (generally with workflow). Produce detail issue reports and high-level status reports.
Flexible Reporting	Standard reports should be available for common types of reports. Customizable query-based reporting should be available to produce reports with multiple data items linked by their relationship and their data elements. Commonly used queries can be saved as a report.
Dashboards/Metrics	Ability to rollup metrics on status or specific data properties. Dashboards generally include graphical display of data in a chart or graph as well as table format reporting of metrics. Metrics should allow drill-down to detail data.
Flexible customization	Ability to add data elements for items (controls, risks, processes, etc.) of various types (text, numeric, user, reference to other items, picklist with valid values, date).
Role-based security	Security allows restrictions based on role: auditor, process owner, tester, etc. and access may be restricted by workflow or by item.
Integrated regulatory/compliance content	Some GRC products contain links or ability to pull in content from regulatory databases such as WestLaw and LexisNexis.
Data standardization	Ability to standardize data across departments, locations or organizations and maintain consistency of the data regardless of where it occurs.
Automated controls	Provides the implementation of automated controls in the form or edits and validations, warnings or role-based restrictions on the ability to perform functions or change certain data within an ERP application or other system.
Security assessment, design and provisioning	Provides the design of segregation of duties conflicts in security access and assessment of security for such conflicts. Analyze new access requests for conflicts to warn or prevent conflicts from being implemented in new provisions of access. This is provided in EGRC systems that integrate with an ERP or other system.
Continuous Controls Monitoring	Ability to tag certain business exceptions or events for automated real-time warning to user, email notifications or periodic reporting to management. This requires integration with another system.

NON-FUNCTIONAL CONSIDERATIONS:

Scalability
Method of deployment and connectivity
Ease of use
Support
Vendor background, stability, and reputation
Product strategy and development
Importing/Conversion of existing data
Cost

QUESTIONS FOR STARTING AN EVALUATION:

Who will be using the product and who are the primary stakeholders and their requirements? As Enterprise GRC products, these products have the potential to be used by auditors, compliance functions, risk management, business management, and IT.
Have the potential uses been prioritized?
What are the primary ways that you assess the status of GRC activities?
Are you selecting a product for processes that have been performed before? If so, is the process itself one that you are happy with, but requires some enablement? What are the good and bad points of the process? If not, have you defined the process and its requirements before selecting a software product?
Is the current way that you organize GRC data acceptable or lacking? If it is acceptable, how does the product handle your data classification and hierarchy? If it is lacking, have you designed a data schema for which the product must accommodate?

CAUTION

Enterprise GRC software is a relatively new market. Consolidations of software vendors and their products have been occurring frequently over the past few years. Many Enterprise GRC products are presented as a suite which were formed from the integration of several products into modules of one suite. Beware of cobbled-together solutions that have not been proven out.

Download PDF and print article

Next GRC article: A Structured Approach to GRC Software Design

Roadmap to GRC Software

Denise Sanders — Wed, 24 Mar 2010 02:03:27 GMT

Understanding the terminology and types of GRC products

‘Governance, Risk, and Compliance’ (GRC) emerged a few years ago as an umbrella term to describe the programs an organization would perform to manage these three areas entity-wide. Companies do not necessarily integrate these activities and have various departments, policies and management activities to address them. The software market is similarly segmented. Terminology used from one software company to another is inconsistent. The product markets often overlap. To confuse things further, analysis of specific products published by software research firms such as Gartner and Forrester is generally out-dated by the time it is published. Since the introduction of the Sarbanes-Oxley Act (SOX), the market of GRC products has experienced rapid change. New types of products and functionality have been developed for the management of SOX compliance. Many of the software products originally referred to as “SOX software” developed into what is now “Enterprise GRC”.

Many companies decide they need software, understand one software vendor’s terminology in describing their product and then utilize the same definition in picking a short list of vendors to evaluate. This can both eliminate viable possibilities, as well as include vendors that don’t meet the basic functional requirements simply due to inconsistent use of terminology. The first step in any software evaluation is to understand your current and potential future needs and their priority. The primary functionalities should then be the basis of identifying products, not a label for the software products. This could produce a list of multiple point solutions as well as Enterprise GRC suites. Only then can you begin to assess the fit of the products themselves.

Below outlines some of the terminology and how the product categories may overlap.

ENTERPRISE GRC SOFTWARE

When publishers refer to GRC software, they are usually referring to what the analysts now call “Enterprise GRC” software. Enterprise GRC technology supports the oversight and management of all three of the primary activities: a company’s governance functions, enterprise risk management, and compliance processes. Functionality of this type of software includes the ability to capture data relationships between items such as processes and controls, document controls and policy libraries, perform risk assessment, and monitor control activities and testing.

POINT SOLUTIONS

A point solution may address one or more of the three (governance, risk management or compliance) or may address a specific departmental focus such as financial, operational or information technology. Point solutions can also include products to actively provide compliance (for instance security controls) as opposed to manage a compliance process or documentation of compliance. Whereas Enterprise GRC products are generally designed to manage the overall GRC process, point solutions often address a specific industry, regulation or product-specific need (for example security specific to the company’s ERP system).

CATEGORIZATION OF SOLUTIONS

The below figure depicts the possible overlap or hierarchy of how products may be categorized. Enterprise GRC, shown at the top of this hierarchy, can be used to manage all the GRC processes for the second tier. The point solutions under each of the second tier generally operate more specific GRC activities. Recently, Enterprise GRC “Suites” have started to include activity-specific GRC point solutions.

Even though this shows common groupings, some products may still fall into various categories.

SUMMARY

Don’t attempt to create a short list of software for a selection process based on their label.
Define your requirements.
Then identify the software with the primary functionalities to meet requirements.

DEFINITIONS

Financial compliance
The management and control of financial processes and the compliance to specific financial standards and regulations (Sarbanes-Oxley Act, SEC, IRS).

SOX - Many of the current Enterprise GRC products began as software for the management of the Sarbanes-Oxley Act compliance process and were originally called “SOX software”.
Tax compliance - Software to prepare tax returns for federal, state or local taxes.
XBRL - XBRL Software provides the tagging of data into the XBRL format for electronic standardized data capture and submission of financial statements to the SEC.

IT GRC Management
Various point solutions exist within this realm, including security and identity management, configuration management, business continuity, IT asset management, IT policy management, and general IT risk management. Many of the Enterprise GRC products can also be used for general IT governance, risk management, compliance and policy management.

Security - Security products may include infrastructure security management such as intrusion detection, intrusion prevention systems (IDS or IPS) or firewall management or business application security such as segregation of duties and access provisioning.

Segregation of duties (SOD) and Access provisioning - Software providing analysis of security roles and their assignment or “provisioning” to users where potential conflicts are identified which may be considered a conflicting set of duties which would allow inappropriate access. Some SOD software is only detective in nature, analyzing existing access, and others are preventive in nature, analyzing a potential access provisioning to prevent granting access against corporate policy. SOD and access provisioning software may be embedded in continuous controls monitoring software.

Audit
Audit products are designed for the documentation of audits, assessment or monitoring of controls, and analytical auditing.

Electronic workpapers -“Electronic workpapers”, as they are generally called, have existed before the advent of Sarbanes-Oxley when many of the GRC software vendors emerged. They include functionality for workflow and document management for the purpose of maintaining internal audit workpapers.
Continuous Controls Monitoring (CCM) - CCM allows you to monitor business exceptions to company policies or potential fraud indicators by identifying triggers. These may report information on dashboards, reports or produce email notifications. This type of software may be used by auditors or by management as part of its normal operations.
Data analysis and auditing - This type of software is used primarily by auditors but may also be used by business analysts. It is used for the programmatic examination of data for the purpose of identifying potential audit anomalies or fraud, sampling, or continuous controls monitoring. This process is often referred to as “CAATs” or Computer-Assisted Audit Techniques or Computer-Aided Audit Techniques. These tools provide identification and combination of data files from various sources. Some data analysis software vendors refer to their products as continuous controls monitoring software.

Other Point solutions

Privacy - Privacy products may provide security functionality (overlapping into the IT GRC area) and manage the classification of data to manage privacy or disclosure requirements and regulations.
Legal GRC - Legal GRC products deal with litigation management, records retention and records management, contract management and compliance, and other legal risks and compliance issues.
Human Resources - Management of HR policies, compensation practices, hiring and termination practices, employee satisfaction, and training and employee development systems.
Health, Safety and Environmental - Software that tracks health programs, track safety programs, incidents and reporting, or maintain environmental controls.
Insurance - Insurance software products manage claims as well as policies.
Quality - Quality management products are often found in operations management for statistical quality control monitoring.
Vendor management - Vendor management products assist in managing vendor policies, credit checking, or general identity verification.
Regulatory compliance - Software specific to particular regulations (such as HIPAA, PCI, etc.). For example, some security monitoring software will claim that you can maintain PCI compliance with its use.

Next article: Evaluating Enterprise GRC Software

IFRS - Waiting on the SEC? What does it matter right now to US public companies?

Denise Sanders — Wed, 27 Jan 2010 21:41:00 GMT

Many companies are waiting on the SEC’s timeline for a US GAAP to IFRS adoption to get up to speed on International Financial Reporting Standards and take steps to assess IFRS impact. What about the impact of IFRS now? What impact you say? If the SEC hasn’t mandated it for US issuers, then it’s a non-issue right? Not necessarily. The impact now for a US issuer which operates internationally is from other countries adopting IFRS. The potential magnitude of this impact seems to have gotten shuffled under the rug.

The impact to a US issuer operating internationally can be broken down into four components:

1. Changes in the local country accounting and systems
2. Maintenance of two or more sets of accounting books (yes, I said MORE)
3. Changes in the US consolidation
4. New risk to internal control over financial reporting (Sarbanes-Oxley implications)

1. CHANGES IN THE LOCAL COUNTRY ACCOUNTING AND SYSTEMS

Local statutory reporting requirements vary by country, the type of legal entity, and operating circumstances. Your specific circumstances will determine whether your company must adopt IFRS locally when the country announces a transition to IFRS. As such, the best way to know your company requirements for reporting is to contact the local regulatory authorities.

As a local entity adopts IFRS, decisions must be made on how items will be accounted for under IFRS on the local books. These changes to accounting result in the following changes and considerations:

Accounting policies and procedures – Policies and procedures will need to be updated to reflect IFRS policies and procedures.
Accounting system – The local accounting system needs to reflect changes relevant to international accounting standards, including potentially a new ledger, new calculation methods, new general ledger accounts, and new reports.
Internal controls – Changes to policies and procedures at the local country level will likely impact the internal controls performed and documented relevant to the company’s Sarbanes-Oxley assessment.
Processes to submit financial data to US Corporate – If the local country submits a standard reporting package to the US corporate office, is that reporting package going to change? Is the local accounting staff responsible for transforming the IFRS books to US GAAP?

2. MAINTENANCE OF TWO OR MORE SETS OF ACCOUNTING BOOKS

As a US public company with an international entity adopting IFRS, at the local country level there will be a set of books for IFRS reporting, and for US consolidation there will need to be a US GAAP version of the books. Why do I mention potentially more? During the year before IFRS is required, a company which reports comparative financial statements will likely be compiling financial data under both the current local statutory requirements and the IFRS requirements. Also, depending upon the specific country requirements, the company could be required to report under a different set of standards to other entities, such as taxing authorities or banks.

3. CHANGES IN THE US CONSOLIDATION

As the local country accounting changes, the reporting package sent to corporate or system interfaces to the US corporate reporting system may change, unless the transformation from IFRS to US GAAP is to take place in the local country. In either case, the accounting staff responsible for the conversion from IFRS to US GAAP needs training on IFRS and new procedures on this conversion.

4. NEW RISK TO INTERNAL CONTROL OVER FINANCIAL REPORTING

All of the above present new risks to internal control over financial reporting (ICFR) and a new consideration in management’s and their auditor’s Sarbanes-Oxley assessment. New and updated control procedures should be considered for the changes to processes, systems, and ensuring the adequacy of skills and knowledge of IFRS and the new related procedures.

While the US GAAP transition to IFRS may be the largest potential IFRS impact to US companies, the impact of other countries’ transition should not be ignored or minimized. Companies that do not take the necessary steps to manage the change and its related risk may be sorry when their auditor finds errors in the US consolidated financial statements.

Download or print article

The risk of Enterprise Risk Management

Denise Sanders — Mon, 04 Jan 2010 15:11:00 GMT

The SEC gave final approval to a rule requiring disclosure of certain governance practices, including the Board’s role in a company’s risk oversight effective February 28, 2010. Other entities recently focusing on the topic of Enterprise Risk Management (ERM) include COSO, the AICPA, and Standard & Poor’s credit rating agency. The main targets of concern are the Board and Audit Committee role and ensuring that Board’s are addressing risk. The SEC rules provide vague requirements on how a Board or company should be addressing risk and simply require that the Board’s role in risk oversight be described. For the Chief Financial Officer or Chief Audit Executive raising awareness to the Board and Audit Committee, the challenges that exist include little SEC or authoritative guidance on what risk management should include, very few benchmarks of companies implementing ERM, and potential litigation or public perception challenges around disclosure.

In this article, I’ve laid out how we got here, the guidance that exists, and questions that need to be addressed as a company moves toward a plan for addressing the new disclosure rules and implementing ERM.

ERM BACKGROUND

The practice of risk management has been around a long time but its first real public appearance began after the Enron and WorldCom scandals in the early 2000s, which led to the development of the Sarbanes-Oxley (SOX) Act of 2002. Although entity-wide controls such as risk assessment, monitoring, and communication were part of the overall risk framework, the focus of SOX was on financial reporting risk. This was followed by the New York Stock Exchange governance rules requiring Audit Committees to discuss risk management policies and practices. The concept referred to as “Enterprise Risk Management” was coined by the Committee of Sponsoring Organizations of the Treadway Commission when they published “Enterprise Risk Management – Integrated Framework” in 2004. The COSO ERM framework defined risk broader than financial risk. This document defined ERM as a "…process, effected by an entity's board of directors, management, and other personnel, applied in strategy setting and across the enterprise, designed to identify potential events that may affect the entity, and manage risk to be within its risk appetite, to provide reasonable assurance regarding the achievement of entity objectives." The COSO ERM Framework has eight Components and four objectives categories. It is an expansion of the COSO Internal Control-Integrated Framework published in 1992 and amended in 1994. The eight components are:

Internal Environment
Objective Setting
Event Identification
Risk Assessment
Risk Response
Control Activities
Information and Communication
Monitoring

The four objectives categories are:

Strategic - high-level goals, aligned with and supporting the organization's mission
Operations - effective and efficient use of resources
Reporting - reliability of operational and financial reporting
Compliance - compliance with applicable laws and regulations

RECENT FOCUS

ERM has begun to receive more focus lately by Boards and regulators due to recent changes in our environment, including the recent banking financial crisis and recession of 2008/2009. Recent activity includes:

The SEC proposed in July 2009 and finalized in December 2009 a ruling requiring Boards to disclose their role in the company’s risk management process in proxy and information statements, annual reports and registration statements.
The AICPA Audit Committee Effectiveness Center published an article on effective Enterprise Risk Management in September 2009.
COSO released a thought paper, Effective Enterprise Risk Oversight: The Role of the Board of Directors in August 2009.
Standard & Poors (S&P), the credit rating and equity research company announced its plans to include a series of questions about risk management in its company evaluation process. This started with financial companies in 2007. The results of this inquiry is one of the many factors considered in debt rating, which has a corresponding impact on the interest rates lenders charge companies for loans or bonds. On May 7, 2008, S&P also announced that it would begin including an ERM assessment in its ratings for non-financial companies starting in 2009.

THE CHALLENGES OF ERM DISCLOSURE

The SEC approved rules relating to board leadership structure and the board's role in risk oversight require disclosure about:

A company's board leadership structure, including whether the company has combined or separated the chief executive officer and chairman position, and why the company believes its structure is the most appropriate for the company at the time of the filing.
In certain circumstances, whether and why a company has a lead independent director and the specific role of such director.
The extent of the board's role in the risk oversight of the company.

Questions that companies must now answer for themselves in disclosing this information include:

What is effective risk oversight? – While articles and whitepapers have been written by the AICPA and COSO, no authoritative/regulatory rules exist on what would be considered effective risk oversight or enterprise risk management practices.
Does disclosure of the board’s role in risk oversight present new bases for potential lawsuits by shareholders when the company has unfavorable results or surprises?
How favorable or unfavorable is the public perception of delegation of risk oversight by the board to a risk committee or the audit committee?
To what extent does the lack of a formal enterprise risk management program play in public perception? Many companies have been so focused on Sarbanes-Oxley over the past few years that a broader view of risk has been somewhat obscured. While risks are identified in Item 1A and the management discussion and analysis section of a company’s 10-K, and companies inherently address some risks in their operations, many companies do not have formal programs to ensure they address these risks.
Will companies that disclose a greater level of detail about their risk management practices be better or worse off in the market?
If your company doesn’t have an ERM program, what will you do to implement a program in the coming months? And will you disclose this in absence of an existing program?

Download or print this article (pdf)

The Business Case for a New ERP System: When is it time?

Denise Sanders — Wed, 02 Dec 2009 15:59:00 GMT

An Enterprise Resource Planning (ERP) system is a big investment and one that can provide huge benefits to a company. The worries around making such an investment involve fears of growing project timelines, over-budget project costs, and consultants taking huge amounts of time from your staff away from their normal duties. On the other hand, the benefits of ERP can produce better productivity, reduced operating and administrative costs, better reporting to manage the business, and better internal control. So when do you take that step? How do you know if you need a new ERP system?

Many of the benefits of an ERP system come from the ability to integrate and standardize processes and functions into one system that were decentralized or disparate systems. This article outlines the major signs or symptoms that it might be time to consider implementing a new ERP system or consolidating into a single ERP and the associated benefits.

Symptom	Benefit of an integrated ERP
Fast growth Rapid growth may provide obstacles to your ability to provide the appropriate system capability.	Scalable A robust ERP solution provides scalability for additional volume of operations, users, new locations or entities.
Inefficiency due to redundant processes and systems If your company has grown through acquisition, acquiring companies with different systems or expanded into new regions and each new entity or product line has implemented their own systems, you may have inefficiency challenges. Various disparate systems often mean: Processes vary which can cause excess time and cost in monitoring and consolidating activities. Data transfers between systems are required, in turn requiring reconciliation and potentially large amounts of data manipulation.	Standardized Processes A single integrated ERP system facilitates the execution of standard processes. Reduced data transfer and manipulation A single integrated system reduces or eliminates data transfer, manipulation and the associated risks.
Over-reliance on error-prone spreadsheets and manual processes Key processes are performed in spreadsheets, such as financial consolidation or fixed asset tracking and depreciation. Key management reports are produced in spreadsheets. If adequate systems are not in place, you may be spending a great deal of time manipulating data outside your system and often correcting errors.	Efficient and accurate automated processes Calculations and functions of an ERP are tested in implementation and can be relied upon going forward without the repeated review of a spreadsheet process. Time spent on spreadsheet creation and review to perform functions that are standard functionality of a an ERP can be redirected to more high-impact analysis.
Inadequate reporting capability The company is lacking in its ability to forecast or plan or even report the right information timely.	Improved reporting ERP Systems support more robust planning, budgeting, and analytics to support financial analysis and control.
Meeting reporting deadlines is difficult Reporting is not available timely due to the need to gather data from multiple systems. Reconciling information is challenging due to multiple sources of data. When a company has multiple general ledger systems, it often means there are multiple closing processes for each set of books, transfer of data, adjustments and reconciliation. Many companies spend a great deal of timing consolidating and making adjustments in a spreadsheet.	Reduced time on consolidation and period-end closing The processes for period-end closing, consolidation, review and reporting are often a simpler and less time-consuming process in a centralized reporting system. An ERP system utilizing a consolidation and reporting engine can enable a simpler, shorter closing process. This may allow a company to either reduce headcount or re-focus accounting personnel on more strategic activities or better accounting controls such as account reconciliation. A single system holding all the data leads to timely reporting and no need to reconcile various data sources.
International requirements Many accounting systems are only designed for one set of accounting books and other countries generally have local statutory requirements different than the US. Foreign currency translation may be performed inconsistently across the company with multiple systems. Exchange rates stored in separate systems may be sourced from different places and inconsistently applied. Companies that have multiple general ledger systems for multi-location entities are familiar with the need to have very manually intensive intercompany processes, with difficulties reconciling at period-end.	Multi- entity accounting books A true ERP system allows you to maintain multiple sets of books for multiple entities. Consistent application of foreign currency translation A single ERP system would eliminate having various exchange rates and translations in various systems. Many systems do not handle multiple currencies. For a company with international entities, an ERP system which handled foreign currency translation is key to ensuring accurate financial statements. Balancing inter-company transactions Utilizing a single ERP system, inter-company transactions would automatically facilitate both entity’s posting.
High compliance costs A company with various locations, systems, and processes may have inconsistent internal controls, difficulties in monitoring controls, and excessive compliance costs due to the lack of standardization. Highly manual processes take more time to monitor and test for compliance than automated ones.	Reduced compliance costs A consistent system across locations and processes would allow better standardization of processes, controls and compliance testing. Some internal controls that may be decentralized could become centralized, reducing the cost of performing and monitoring the control.
Repeated internal control deficiencies Highly manual processes have more potential for error and may require more controls for redundancy and level of comfort. Some applications have inadequate security functionality to enforce proper password controls or segregation of duties. Companies that have multiple systems may find it extremely tedious and difficult to manage and monitor appropriate segregation of duties. Physical security to servers housing key applications may be weak at regional locations. The ability to verify that unauthorized changes have not been made to systems can be extremely difficult or impossible within some systems without additional products.	Automated Process Controls Centralized integrated processing allows for more potential to automate controls for reconciliation and monitoring and fewer redundant controls. Security A good ERP solution can have consistent robust security that can be managed and monitored centrally across the company. A centralized ERP system can be maintained in one central data center making physical security easier to manage and maintain. Change control Many good ERP systems have a change control management system that keep an audit trail and allow reporting to verify when, where, and by whom changes to the system were made.
High IT costs Distributed systems with various support models are both costly and ineffective for consistent internal controls.	Centralized infrastructure and support A centrally-managed ERP allows for lower IT costs by maintaining one system instead of several in terms of less hardware and software, fewer support processes for user administration and helpdesk, patch management, backups, and monitoring. Other benefits may include lower user training cost and increased intercompany mobility.

One or more of the above symptoms might drive your decision to investigate an ERP solution. However, a careful, experienced assessment might determine that existing systems can be modified and/or processes modified to achieve your objectives with a moderate investment. Your best course of action over the next few years may be to maintain your current system(s). If you aren’t sure what the cause of your issues is or where your constraints are, then you need to start with a process and system assessment and determine this first. The above symptoms are, at the least, signs that process improvements should be made to improve efficiency and control.

6 KEY QUESTIONS IN THE ENHANCE-OR-REPLACE DECISION

A new system is never about the latest technology but rather understanding and meeting your business goals. As you try to decide whether to enhance or upgrade current system(s) or replace one or more systems, some key questions to keep in mind:

What are the current and future business goals you are trying to meet?
Do you have multiple disparate systems and processes which cause confusion, inefficiency, onerous data manipulation and increased potential for errors?
Are you managing by spreadsheets for major processes and finding inconsistency and spending an inordinate amount of time on reconciliation?
What type of growth strategy does the company have? (acquisition, new products/services, new regions or countries?
What new regulatory requirements might be imposed on the company over the next few years due to either potential changes in regulations or your growth plans? For example: new accounting standards, potential IPO and related Sarbanes-Oxley and SEC requirements, new locations subject to different regulations, international operations (Foreign Corrupt Practices Act, reporting under local country statutory requirements or transition to International Financial Reporting Standards).
Which requirements are constrained by current systems and can the systems or processes be modified to meet those requirements? If so, at what cost/benefit?

Download or print article

IT General Controls - Is it really important to financial reporting?

Denise Sanders — Thu, 20 Aug 2009 02:58:00 GMT

Download or print article

We are coming into the fall season when IT auditors schedule their annual IT walkthrough and assessment. Many IT Directors and Chief Accounting Officers responsible for the results of their company’s Sarbanes-Oxley (SOX) internal control assessment dread this timeframe because they often still have the same philosophical and practical disagreements each year over IT general controls (ITGC). These include: what areas should be in scope for assessment, how much should be tested, what is considered adequate controls for an objective, or even the basic premise of why it’s relevant to SOX and the evaluation of internal controls over financial reporting (ICFR). What are the common areas of disagreement between IT auditors and management when it comes to IT general controls? And, what is really important?

To tackle the question of what’s important, we must first have a common understanding of 1) what is an IT General Control (ITGC) and how does it fit into an overall control framework, 2) the authoritative guidance, 3) the control frameworks that provide guidance on ITGC, and last, but not least, reflect on the importance to the specific organization or 4) the company’s facts and circumstances. We can then apply this framework to some commonly disputed items.

1. DEFINING IT GENERAL CONTROLS

IT general controls can best be defined by contrast to IT application controls. Application controls are those that are implemented within a software application and directly affect or control the processing of a transaction or event, often referred to as transaction processing controls. IT general controls, in contrast, do not directly relate to processing transactions but support the IT environment. Some IT general controls have a more direct connection to the process controls, and others are more indirect. To this extent, ITGC are very similar in nature to entity-level controls.

ITGC controls are focused on four areas:
• Computer Operations
• Program Changes
• Information Security or access to programs and data
• Systems Development and Implementation

These four areas are outlined in the COSO Internal Control: Integrated Framework as well as the Control Objectives for Information and related Technology (COBIT) framework.

2. AUTHORITATIVE GUIDANCE FOR PUBLIC ISSUERS

SEC Release 33-8810

The SEC guidance on management’s internal control assessment provides the best basis for establishing that IT general controls must be considered in a SOX assessment.

It states “Controls that management identifies as addressing financial reporting risks may be automated, dependent upon IT functionality, or a combination of both manual and automated procedures. In these situations, management’s evaluation process generally considers the design and operation of the automated or IT dependent application controls and the relevant IT general controls over the applications providing the IT functionality. While IT general controls alone ordinarily do not adequately address financial reporting risks, the proper and consistent operation of automated controls or IT functionality often depends upon effective IT general controls.”

Important in this narrative is the reference to automated controls or those dependent upon IT functionality. A company may not have identified any key automated controls to the financial reporting process and therefore, believe that IT general controls are not relevant to the SOX process. However, when referring to controls dependent upon IT functionality, the SEC specifically gives examples such as balanced postings. This would suggest, as seems reasonable, that a company is dependent upon IT functionality where it is using a general ledger application or any other financially-relevant information system that compiles, balances, or reports financial information for the interim or annual financial statements. Therefore the IT general controls that support the operation and management of changes in these environments are relevant to the evaluation of ICFR.

The SEC further explains that the identification of risks and controls within IT should be an integral part of management’s top-down, risk-based approach. They go on to explain that “aspects of IT general controls that may be relevant to the evaluation of ICFR will vary depending upon a company’s facts and circumstances”, an area we will address as item number four below.

PCAOB Audit Standard No. 5

The Public Company Accounting Oversight Board’s Audit Standard No. 5 (“The Standard”) which replaced Audit Standard No. 2 to focus more on a risk-based approach does not directly give guidance on how much IT general controls should be considered. It states that an important factor in considering the risk of a control is the extent to which it relies upon “the effectiveness of other controls (e.g., the control environment or information technology general controls)”. The Standard also discusses the need to test ITGC controls when application controls are relied upon to ensure the effective operation of the application controls.

One of the most impactful pieces of information in the Standard regarding the importance of IT general controls does not actually even mention the specific term “IT general controls”. It is the guidance on the evaluation of deficiencies. The Standard states that the severity of a deficiency is dependent upon two things: “1) Whether there is a reasonable possibility that the company's controls will fail to prevent or detect a misstatement of an account balance or disclosure; and 2) The magnitude of the potential misstatement resulting from the deficiency or deficiencies.” In applying this standard, many IT auditors conclude that one ITGC deficiency by itself generally would not warrant an evaluation as a significant deficiency or material weakness since ITGC controls do not directly relate to the achievement of a financial statement assertion. However, if an ITGC issue contributes to the deficiency of a key application control, (for example, ineffective testing of program changes to an application resulting in inaccurate system calculations of an account balance), then the ITGC deficiency is generally considered to be as severe as the application deficiency. The aggregation of multiple ITGC deficiencies however, can trigger an auditor to conclude that they are important enough to call to the attention of those responsible for oversight of financial reporting, i.e. the Chief Financial Officer and Audit Committee, and therefore a significant deficiency. The step from significant deficiency to material weakness is largely judgmental.

3. THE CONTROL FRAMEWORKS

COSO

The Committee of Sponsoring Organizations of the Treadway Commission’s Integrated Framework for Internal Control (COSO) is the most commonly used control framework when evaluating the Sarbanes-Oxley Section 404 assessment of ICFR. COSO defines internal control and five components of internal control: control environment, risk assessment, control activities, information and communication, and monitoring. IT general controls may be contained in any of these five components. COSO provides a definition of IT general controls and the key areas considered in ITGC but does not give detail guidance on designing or implementing IT controls.

COBIT

The Control Objectives for Information and related Technology (COBIT) published by the IT Governance Institute (ITGI) is widely used by IT auditors and management to supplement the COSO framework since it goes beyond defining the key areas of ITGC by outlining specific guidance on the application of a control framework for designing and implementing IT controls. It defines commonly accepted control objectives for technology and gives examples of controls to meet the control objectives. The IT Control Objectives for Sarbanes-Oxley, 2nd Edition (“SOX COBIT”) published by the ITGI applies the COBIT framework to Sarbanes-Oxley and provides additional IT guidance on areas of greater importance to internal control over financial reporting. This includes an approach to risk assessment for the information technology environment and guidance on the priority of controls. It is interesting to note that this publication places a greater priority on risk assessment and the risk-based approach than the first edition, although it was published prior to the PCAOB’s Audit Standard No. 5 which emphasized risk-based approach. The references to PCAOB in SOX COBIT refer to Audit Standard No. 2, which is now superceded. The SOX COBIT document provides good guidance on points to consider, example controls and tests for controls. The use of this document however, sometimes gets warped when the points to consider for entity-level IT controls and example activity-level controls get used as a “checklist” rather than as guidance, and little thought is given to understanding the company’s circumstances and the overall achievement of control objectives.

4. THE COMPANY’S FACTS AND CIRCUMSTANCES

In applying the above guidance and frameworks, it is important to also take the company’s specific circumstances into consideration. Avoiding a “checklist” audit is as simple as two considerations:

Achievement of relevant control objectives
In most cases, a variety of different controls can be utilized to achieve the same control objective. Sometimes it is desirable to utilize multiple controls to achieve a control objective to achieve greater assurance. However, utilizing all the possible controls or all of the illustrative controls listed in the SOX COBIT is not necessary to provide reasonable assurance of control over financial reporting.
Risk (or applicability) to the company
An auditor who is not following a top-down risk-based approach to the assessment of company controls may request information on controls or control objectives that are not even relevant to the company, such as controls around a System Development Lifecycle methodology, when the company has no software development activities and utilizes only “off-the-shelf” applications. The controls relevant to assess for SOX not only need to be applicable, but the level of control and the nature and extent of testing should be consistent with the system’s or area’s risk and the specific control risk. The use of a good risk assessment for IT will right-size the number of controls identified as key to SOX and the nature and extent of testing to what is reasonable and appropriate to the company. A good IT risk assessment is not independent of the overall SOX risk assessment, but follows it from the identification of existing risk to financial statement accounts to relevant process to the IT applications and systems that support those processes.

COMMON AREAS OF DISAGREEMENT

Network vulnerability

When assessing controls to ensure system security, many auditors following COBIT will insist that a network vulnerability assessment or attack and penetration test should occur every year. An auditor following the SOX COBIT model will point to an illustrative control that states: “Appropriate controls, including firewalls, intrusion detection and vulnerability assessments exist and are used to prevent unauthorized access via public networks.”
However, this control is only illustrative and by no means mandatory. Furthermore, the SOX COBIT document identifies some controls as “most relevant” to SOX, however threat and vulnerability assessments are not among them. Companies with an elevated threat level, such as Fortune 100 companies or companies that are well-known in the media, and could be considered a target from outside hackers may need to have continuous vulnerability monitoring with specialized network monitoring software (intrusion detection systems or intrusion prevention systems) as well as periodic attack and penetration studies, along with strict firewall rules and related configuration policies. However, a middle-market company with little external threat based on name-recognition or confidentiality of information in its possession may have adequate security even if its network is secured only by good firewall rules and basic firewall monitoring. The level of control should be commiserate with the company and the IT risk assessment.

Segregation of duties

A common assessment of segregation of duties by an IT auditor includes obtaining security data from the company’s ERP system, and then comparing it to best practice cases, outlining which duties should not be performed by any one single person. One such best practice, for example, mandates that “A person who creates accounts payable invoices in the system should not also be able to produce check runs to pay the invoices”. While this addresses the valid concern that a person could create an invoice to their own benefit and then create a check to pay that invoice, there are a number of conceivable mitigating controls that may be in place to prevent such an occurrence. A strict conflict match based on two activities considered to be inappropriately segregated according to best case scenarios, however, does not consider mitigating controls or the remaining risk level. In the above example, an Accounts Payable clerk who can create both invoices and checks may be prevented from defrauding the company by not having the authorization to create invoices for vendors that have not been approved by a another party, or sign any of the checks they have created themselves. Checks may be reconciled by another person. These would be considerations in the assessment of segregation of duties that may fully mitigate or reduce the conflict to a point where the risk of the scenario is very low. A structured approach to documenting segregation of duties conflicts, related controls, and mitigating controls will reduce the amount of discussion with auditors and helps avoid the time-consuming assessment of segregation of duties.

Backup and recovery

From the beginning of SOX assessments, auditors have agreed that a full-scale disaster recovery plan was outside the scope of SOX. Continued debate occurs, however, as to what relevance to internal control over financial reporting there is to taking data backups of systems. Also debated is whether testing the recovery of those backups is something that should occur periodically and to what extent. The inclusion of controls over data backups is closely tied to our definition of ITGC and the authoritative guidance on what types of ITGC are considered relevant in an assessment of ICFR. ITGC support the IT environment and their inclusion is based on the extent to which process or application controls are dependent upon IT. Data backups sustain the continuity of the IT environment which supports the financially-relevant applications. At a small company where most journal entries are made at month-end and a whole new set of financial statements could be re-created very quickly, data backups are not as significant. And while backups are relevant to most companies, the absence of reliable backup procedures or controls may not pose a high risk and may not lead to a significant deficiency. The necessity of testing the ability to recover data from backup is often debated. The fact is that you can’t rely on a backup being usable unless you can prove it. The level of backup control should be based on 1) ability to ensure that the right data is in fact there, and 2) data can be recovered. Some auditors insist that a full recovery test be performed. If one separates verification of data and ability to recover into two parts then you find that full recovery testing may not be necessary. The question of what proves it can be recovered will depend upon the software and data format.

CONCLUSION

ITGC is a necessary part of the IT controls supporting financially-relevant applications. Auditors may go overboard on what controls are necessary, the level of significance of certain controls and on certain tests due to a checklist approach to auditing ITGC. A structured IT risk assessment supported by documentation of the environment, including relationships to related process controls can reduce the amount of discussion and therefore time spent by auditors.

Download or print article

Project	Exposure Draft	Comments due	Public Round-Table Meeting	Final Standard
“Priority” Projects from MoU
Financial Instruments	FASB 5/26/10 IASB Q3 2010	9/30/10	Q4 2010	Q2 2011
Presentation of Other Comprehensive Income	5/26/10	9/30/10		Q4 2010
Revenue Recognition	6/24/10	10/22/10	Q4 2010	Q2 2011
Leases	8/17/10	12/15/10		Q2 2011
Fair Value Measurement	6/29/10	9/7/10		Q1 2011
Lesser priority projects
Consolidations	Q4 2010		Q3 2010	Q2 2011
Derecognition				IASB Q3 2010*
Balance sheet Netting of Derivatives and Other Financial Instruments	Q4 2010		Q1 2011	Q2 2011
Financial Instruments with Characteristics of Equity	Q1 2011		Q3 2011	Q4 2011
Financial Statement Presentation – main project	(Staff Draft 7/1/10) Q1 2011		Q3 2011	Q4 2011
Presentation of Discontinued Operations	Q1 2011			Q4 2011
Post-employment Benefits	IASB 4/29/10	9/6/10		Q1 2011
Insurance Contracts	Q3 2010			Q2 2011
Emissions Trading Schemes	2^nd half 2011			2012