Journal Online

Compliance Management: A Holistic Approach

amelia Ho, cisa, cisM, cissp, pMp, cia, ca, cFsa, ccsa, ceH, Bcce, iso 27001 la, is the senior manager of Audit Services Asia for Manulife. She has more than 10 years of experience in internal and external auditing and consulting for Fortune Global 500 companies and financial institutions and has worked in compliance, risk management and audit functions in multinational financial institutions. She can be contacted at [email protected].

Enterprises are subject to various types of compliance requirements, including regulatory, industry (e.g., Payment Card Industry Data Security Standard [PCI DSS]) and corporate, as well as requirements that need to be met before certification is granted (e.g., ISO 27001), if the enterprise chooses to obtain external certification. Enterprises need to establish compliance management processes within which compliance risks are managed and addressed (e.g., through mitigation). With the advent of Basel II regulation, risk management is in the spotlight and there are enterprises that have both compliance and risk management teams.1 The collective term governance, risk management and compliance (GRC) has become a top business priority and an integrated approach to GRC is encouraged to reduce duplication of effort and cost. Figure 1 illustrates the holistic responsibility of corporate governance.

Figure 1 outline of the Holistic responsibility for corporate Governance

Market, Regulator and Stakeholder Expectations (Emerging Standards and New Requirements)

un ica

G GOVERNANCE R

Inf

RISK MANAGEMENT C COMPLIANCE

Not Doing the Wrong Thing (Rules and Constraints) Extended Enterprise and Value Chain Doing The Right Thing (Values) Culture Integrity Ethics

Governance, risk ManaGeMent and coMpliance An integrated approach to GRC is recommended as it avoids the pitfalls of the silo-based approach. The term silo refers to the separation of units into autonomous segments based on geography

or business function.2 When risk management becomes siloed, each of these units (e.g., internal audit, IT, treasury, human resources) brings to bear different philosophies and approaches. From the silo state, a host of problems can arise including duplication of effort, increased burden on the business, lack of appropriate reliance on coworkers efforts and lack of standardization in methodology. Increased burden on the business can result if each business function records risk management/compliance issues in different systems, incurs resources without pursuing economy of scale in activities (e.g., training, purchase and implementation of single sign-on and/or encryption tools/systems, and outsourcing of risk assessment activities) and/or addresses governance/risk management/compliance issues in its own way. For example, if the security function writes stand-alone policies without coordinating the content with the human resources (HR) department, it could create procedures and policies that will not be followed in practice.3 An example of a lack of standardization in methodology is when an inconsistent risk acceptance methodology is adopted. This can expose an enterprise to unnecessary risk. Compliance and risk management are closely related. According to a Gartner report,4 enterprises that adopt a risk management approach for a control framework will cut the cost of their compliance programs by 50 percent during the initial five years.5 Enterprises that have sound risk management frameworks in place may find it easier to comply with various types of requirements when foundational risk and control frameworks are already in place. Regulations such as Basel II also provide incentive for organizations to improve the quality of their risk management frameworks and systems. This provides a competitive advantage to financial services organizations with a strong GRC framework. For example, figure 2 illustrates how Basel II principles can be mapped to the Committee of Sponsoring Organizations of the Treadway Commission (COSO) framework and CobiT domains.
ISACA JOURNAL VOLUME 5, 2009

tio n

nit Mo n ori

mm

ga

Co

nd

nd

As

on a

su

ati

ran

orm

ce

compliance management process involves the following, which will be described in more detail IT controls should consider the overall governance framework to support the quality and integrity of information. in subsequent sections: COBIT Domains Identification of requirements d d nd nd an an ze ra e Interpretation of requirements and re ent r a rt o n i e nit at qu m liv o Pla gani Ac ple Mo Evalu De Supp Or m impact analysis I Basel II Principles Scope determination Internal Environment Board awareness and approval Independent internal audit Data collection and identification of Objective Setting Risk management framework compliance issue(s) Identification and assessement Event Identification Monitoring operational risk Risk analysis Policies, processes and procedures Risk Assessment Contingency and business continuity plans Implementation of appropriate action(s) for Banking supervision requirement for effective framework Risk Response Banking supervision regular independent evaluation compliance issue(s) Sufficient public disclosure by banks Control Objectives Reporting and monitoring Continuous improvement Control Activities Throughout the compliance management Information and Communication process, there should be early involvement of Competency in all eight layers of COSOs framework is necessary to achieve an integrated control framework. and continuous communication among relevant parties to avoid a silo-based approach to Good governance addresses deficiencies such as inadequate compliance. Management can also use an information system understanding of risk and behavior, poor information flows, in the compliance management process for defining, collecting, and poor communication. Enterprises that create a culture of reporting and monitoring compliance information. compliance and risk management throughout the organization to Enterprises can establish metrics for ongoing compliance emphasize the importance of compliance have a higher chance measurement and management. Potential key performance of success in compliance. Compliance needs to be seen less as indicators (KPIs) for management to monitor include cost of a function and more as an institutional state of mind, helping compliance, financial impact of noncompliance incidents (e.g., organizations to anticipate risk as well as to avoid it.7 One way to fines/penalties paid to regulators/customers), number of incidents demonstrate managements emphasis on compliance is to include compliance in performance appraisals and discipline staff members of noncompliance, number of audit findings and number of incidents of risk acceptance approved. Management can analyze who have noncompliance incident(s). KPIs to create actionable reports about the risk posture of the A crucial element in compliance is staff. Processes should organization and provide insight into the effectiveness of the risk be in place to ensure that all personnel are properly briefed management program8 and compliance. and/or trained in requirements (including new requirements)

Figure 2Basel ii principles Mapped to coso and cobit6

on an ongoing basis. Staff should also learn the corporate risk management approach, e.g., documented risk acceptance process, risk appetite, risk tolerance and limit. This will alert staff to the possibility of applying for risk acceptance for noncompliance with corporate requirements after considering the risk(s), cost(s) and impact(s) of noncompliance. Ultimately, staff and management need to exhibit risk management and compliance in their day-to-day decision making (e.g., new product development). coMpliance ManaGeMent process Enterprises should have compliance management processes in place to ensure that various requirements are met and the impact of noncompliance is within a tolerable risk level. The 2
ISACA JOURNAL VOLUME 5, 2009

COSO Components

identiFication oF requireMents There are various ways to identify different requirements for compliance purposes. For a change in corporate requirements, the relevant department (e.g., IT or corporate security) can send a notification to users regarding the change. For change in regulatory requirements, enterprises can have various channels obtain the update. For example, enterprises can receive a notification from a regulatory body/industry groups or e-mail alert(s) from law firms or information from external auditors or consultants. Additionally, enterprises can subscribe to services for regulatory change updates or can check relevant regulators web sites regularly. Overseas offices can also provide updates of overseas regulatory requirements (e.g., US Sarbanes-Oxley

Act requirements) that are applicable to the enterprise (e.g., Sarbanes-Oxley is applicable to significant overseas subsidiaries of US-listed companies). Enterprises should maintain a repository of compliance requirements9 that contains the complete range of laws, regulations, policies, standards, guidelines and derivatives to which an organization is subject.10 Such a repository can be useful for staff circulation and record maintenance purposes. Management can use such repositories (e.g., a compliance database system) to keep all the compliance requirements in a central place. interpretation oF requireMents and iMpact analysis Once a requirement is identified, the crucial next step is the analysis of requirements. One of the chief causes of an organization failing during the audit process is a general lack of understanding of regulatory requirements.11 Requirements should be carefully examined, and the examination should determine whether the requirement is mandatory or recommended/optional, as this affects the results of impact analysis. Enterprises should ensure that impact analysis of the requirements is duly performed, as the result can facilitate enterprises in determining the priorities of the compliance efforts and resources. Once a new law or regulation is identified as having relevance to the organization, corporate policies, standards, guidelines and architectures must be revised to align with the new requirements. In interpreting requirements, opinions from various parties can be sought. Key parties can be compliance representatives or groups that oversee compliance. Appropriate internal parties to be involved and consulted include IT, compliance, legal, corporate security, risk and control functions within an enterprise, whether they are separate teams or compliance/ risk and control functionaries within the IT department. By involving various parties, enterprises can avoid the common pitfall of different risk and control teams working in silos. In addition, at the requirement interpretation stage, people who use or own the information in question can be involved. For each compliance initiative, different people can participate. For instance, a Sarbanes-Oxley project should involve the finance team. The sales and marketing team, as well as IT, legal and compliance representatives, should together interpret the requirements in legal, business and technology terms for cross-marketing provisions in application forms, and determine whether the US Graham-Leach-Bliley Act (GLBA) and/or another privacy act would have an impact.

When possible, management can also seek clarification from external parties, such as government regulators, industrial regulatory bodies for specific industries, and external auditors. Early and continuous communication with such parties can minimize surprises being identified later. scope deterMination Scope determination is an important step in facilitating compliance with various requirements. Proper scoping can result in a clearly defined scope, which increases the chance for successful compliance. If the scope of applying certain requirements can be reduced, there will be less strain on the companys resources and the enterprise can achieve compliance status in a shorter period of time. This can be an important concern for the enterprise as regulatory requirements can specify a deadline for implementation. For example, the amount of time and resources required would be paramount if the Sarbanes-Oxley requirements were imposed on every IT system of all overseas subsidiaries of a US-listed company and the scope covered every line of business. For an enterprise to comply with Sarbanes-Oxley in the specified timeline imposed by the regulation, it is essential to define the scope for the SarbanesOxley purpose, which covers only material subsidiaries (based on certain criteria) and IT controls, systems and end-user computing tools that are related to financial reporting.12 Figure 3 provides an illustration of the scoping of IT controls for Sarbanes-Oxley. If the application scope is not limited and becomes too complex, some enterprises cannot handle it. For example, with the implementation of the first compliance initiatives, many organizations sought to build a compliance framework by leveraging all of the control objectives of CobiT. This can prove to be too complex for certain enterprises. Organizations

Figure 3scoping it controls for sarbanes oxley purposes13

ISACA JOURNAL VOLUME 5, 2009

should document all of their controls and then minimize them to a manageable and comprehensible list. These controls should align with audit objectives and encompass those that are critical to maintaining compliance.14 data collection and identiFication oF coMpliance issues Enterprises should collect data to determine the existance and extent of any compliance gaps. Compliance issues can be detected through various reviews (e.g., self-assessment reviews, compliance reviews, regulatory reviews, internal/external audits, consulting services contracted, reviews of external certification). Another source of compliance issue identification is compliance issues identified in other offices, as these issues can be commonly faced by the organization regionally and/or globally. In addition, management can use systems to collect and monitor compliance of various systems. For example, the corporate password policy can be input to the compliance system and then the compliance system can check for noncompliance with password policy in various systems. Moreover, there are technology solutions that have predefined policies and rules for compliance regulations and leading information security standards.15 risk analysis From the compliance management operation perspective, an enterprise should assess the level of compliance risks (e.g., regulatory compliance risks) for implementing appropriate controls. Management should also assess the risk of staff/service providers not complying with requirements. Staff/ relevant external service providers who have past incidents of noncompliance or who fail compliance tests would pose a higher risk for the enterprise. Additional training, monitoring and/or penalty clause employment (e.g., with external service providers) may be required to reduce the risk of noncompliance by high-risk staff/external service providers and to provide recourse to the enterprise. Risk analysis can also be conducted for compliance to individual requirements. Enterprises should place higher priority in complying with regulatory requirements, requirements that have a larger impact on the enterprise or requirements that are mandatory (compared to requirements that are a good practice and should be implemented whenever possible). An example of a compulsory requirement is secure communication using a digital certificate and a public key infrastructure (PKI), which is mandated for doing business in certain countries.16 4
ISACA JOURNAL VOLUME 5, 2009

In analyzing compliance risk of a requirement, one should also take compensating control into account. The concept of compensating control can be illustrated as follows. PCI DSS allows for: Compensating controls for encryption of stored data. Compensating controls may be considered when an enterprise cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints but has sufficiently mitigated the risk associated with the requirement through implementation of other controls. Compensating controls must: 1) meet the intent and rigor of the original stated PCI DSS requirement; 2) repel a compromise attempt with similar force; 3) be above and beyond other PCI DSS requirements (not simply in compliance with other PCI DSS requirements); and 4) be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.17 To be allowed to rely on compensating controls for PCI DSS compliance purposes, companies must first undertake a risk analysis and document legitimate technological or business constraints for not being able to meet specific PCI requirement(s). Managements assurance of control effectiveness must identify why and how compensating controls are reliable in a given environment.18 risk acceptance For intended noncoMpliance oF requireMents When an enterprise decides certain controls are not to be applied or are to be applied only partially, a formal risk acceptance process should be carried out for systematic application of noncompliance. A risk acceptance form should be completed with full risk analysis covering compensating controls, cost-benefit analysis and risk assessment information, such as potential adverse impact on confidentiality, integrity, availability, authentication, access controls, security audit, privacy and nonrepudiation. The decision for risk acceptance should be made after considering cost-benefit analysis, impacts (e.g., regulatory/financial impacts) and past experiences (e.g., reputation impacts of security incidents, external auditor/ regulators reports on risk issues). Management can also consider seeking advice from parties such as auditors and compliance and risk management before making a decision on an application for risk acceptance.

The risk acceptance should be approved by management local business management and IT management (e.g., IT head, chief technology officer [CTO], chief information officer [CIO]) and/or global/regional business/IT/risk management (where applicable). Risk-acceptance approval by overseas management reduces the chance of local management approving an unacceptable level of risk due to self-interest. Management should periodically submit risk acceptance for reapproval to ensure that the risk level appropriately reflects the current situation (e.g., a risk can be increased if the system in question has increased the number of critical functions, such as update functions instead of inquiry functions, and the number of users). Proper tracking should be in place to alert management of the expiration of the approved risk acceptance application(s). If a risk acceptance application is denied (including failed renewal of risk acceptance), local business must bring the noncompliant issue into compliance and the compliance plan must be submitted within a certain period of time. iMpleMentation oF appropriate action(s) For coMpliance issues In any organization, there will likely be compliance gaps, and it is important to focus on the gap that could turn into a material weakness or cause an auditor to determine that an organization is not in compliance with a requirement. In prioritizing compliance remediation, management should take into account the risk(s) and impact(s) of noncompliance (e.g., penalties, withdrawal of license from the regulatory body, reputation risk, public disclosure of material weakness for Sarbanes-Oxley reporting purposes) and the criticality of systems for compliance purposes. A phased implementation can be considered if there are constraints on time and/or resource(s) and it is permissible by the requirement-setting body. New requirements should be updated in policies and procedures. Where applicable, compliance checklists should also be updated and training should be provided. All concerned parties (e.g., overseas offices, relevant user departments, external service providers) should be informed of the new requirements, the effective date of the requirement(s) and/or the transition period (where applicable). For example, users should be informed of changes in password policy and should not claim ignorance of the policy changes as an excuse for noncompliance.

reportinG and MonitorinG Compliance issues can be summarized in a compliance database19 (manual log or a system) for access by various parties such as internal auditors, compliance teams and management. The compliance database would be useful for knowledge management purposes, root-cause analysis, compliance reporting and management. Dashboards can be used to show compliance against policies. Management should develop processes for reporting and monitoring compliance statuses and escalating significant issues to senior management (e.g., CIO, chief risk officer, chief compliance officer, and compliance/risk and control/audit committees). Long-overdue compliance issues should be avoided. continuous iMproveMent Management should continually seek opportunities to improve control environments. For example, management can share compliance issues identified in one country or line of business so that other countries and/or lines of business can take proactive initiatives to remediate issues where applicable. In addition, as a self-improvement initiative, management can proactively extend the scope of the application of controls to other parts of its business and/or overseas countries, where resources and time permit. For example, the IT controls related to financial reporting and in scope for Sarbanes-Oxley testing can be applied to other lines of business and/or countries that are out of Sarbanes-Oxley scope. (Note: The findings related to out-of-scope lines of business and/or countries are excluded from Sarbanes-Oxley reporting for regulatory compliance purposes.) During the compliance process, enterprises may find that the requirements are too stringent. Enterprises can influence the development of requirement(s) at various stages. Before a requirement becomes effective, there can be a consultation period for regulatory/corporate requirements, and stakeholders of the enterprises can voice their concerns. For example, regulatory bodies, such as Monetary Authority of Singapore (MAS), publish consultation papers to invite comments and feedback on their existing or proposed regulatory measures. MAS, for example, also provides responses to feedback on consultation papers.20 This allows enterprises to better understand requirements and what measures are encouraged and not compulsory. Even after the requirement becomes effective, stakeholders can exert influence on the requirements by providing feedback to relevant policy-setting parties (e.g., regulatory bodies,
ISACA JOURNAL VOLUME 5, 2009

industry bodies, authors of corporate policies). For example, based on the recurring approved risk acceptances, management can consider requesting that the author of the corporate policy revise the policy. The policy revision may simply specify different requirements for different types of systems (e.g., a maximum of three invalid logon attempts allowed for critical systems and a maximum of five invalid logon attempts for less-critical systems). Alternatively, the corporate policy can be revised to be less specific to provide flexibility. For instance, when there is no agreement that passwords should expire at any specific length of time, a policy may state that a password must expire within a time frame expected to reduce the risk of exposure.21 conclusion It is important to adopt an integrated approach instead of a silobased approach toward GRC. Implementing well-established frameworks (e.g., CobiT, COSO) for IT processes and controls facilitates management to adopt a holistic, instead of piecemeal, approach toward compliance. In addition, an enterprise should develop a formal and established compliance management process and instill a compliance and risk management culture so that staff adopts a compliance and risk-based approach in its daily decision-making process. By implementing a proper compliance management process, the enterprise stands a better chance of minimizing significant compliance issues. Systems can be used for compliance management purposes. Besides using systems to store all requirements and to act as central repositories of requirements and policies, systems can also be used for detecting compliance violations, reporting and monitoring compliance and/or remediation status. Finally, rather than being focused solely on compliance, enterprises should watch out for emerging threats, evolving risks and attack models to ensure that information security risk is properly managed. Ultimately, an enterprise should avoid security by compliance,22 which is the act of focusing all information protection efforts on requirements established by government and industry regulations (e.g., US SarbanesOxley Act, PCI DSS).23 With the current financial crisis caused by the US subprime crisis, financial institutions have raised doubts regarding the usefulness of the Basel II regulation and whether effort and resources need to be spent on complying with Basel II. Thus, enterprises should not blindly take all corporate, industry and/or regulatory requirements as they are without reflecting on their appropriateness and being open to the possibility of influencing relevant parties to revise the requirements to better suit the current environment and risks 6
ISACA JOURNAL VOLUME 5, 2009

faced by the enterprise, industry and world. endnotes 1 IT Governance Institute (ITGI), IT Control Objectives for Basel II: The Importance of Governance and Risk Management for Compliance, USA, 2007, www.itgi.org 2 Layton, Mark; Rick Funston; The Risk Intelligent Enterprise, Deloitte, 2006 3 Ramirez, David; Streamline ISO 27001 Implementation: Reducing the Time and Effort Required for Compliance, Information Systems Control Journal, vol. 5, 2006 4 Logan, Debra; John Bace; Lane Leskela; Use a Process Framework for Compliance and Think Long Term, DF-22-3035, Gartner, May 2004 5 Mehdizadeh, Yahya; The New Compliance Background, Information Systems Control Journal, vol. 1, 2006 6 Op cit, IT Governance Institute, 2007 7 Micallef, Mario; The New World of Risk-based Regulation (Part 1), Information Systems Control Journal, vol. 6, 2007 8 Pironti, John; Key Elements of an Information Risk Management Program: Transforming Information Security Into Information Risk Management, Information Systems Control Journal, vol. 2, 2008, p. 42-47 9 Ross, Steven J.; Automating Compliance, Information Systems Control Journal, vol. 5, 2007 10 Ross, Steven J.; Compliance and Beyond, Information Systems Control Journal, vol. 4, 2007 11 Bakman, Alex; If Compliance Is So Critical, Why Are We Still Failing Audits?, Information Systems Control Journal, vol. 5, 2007 12 Cerullo, M. Virginia; Michael Cerullo; How the New Standards and Regulations Affect an Auditors Assessment of Compliance With Internal Controls, Information Systems Control Journal, vol. 4, 2005 13 IT Governance Institute, IT Control Objectives for Sarbanes Oxley: The Role of IT in the Design and Implementation of Internal Control Over Financial Reporting, 2nd Edition, USA, 2006, www.itgi.org 14 Op cit, Bakman 15 Ibid. 16 Op cit, Ross, vol. 4, 2007 17 Le Grand, Charles; Dan Sarel; Database Access, Security, and Auditing for PCI Compliance, EDPACS, vol. 37, iss. 4 and 5, April 2008, p. 6-32 18 Ibid. 19 Op cit, Ross, vol. 5, 2007 20 Monetary Authority of Singapore, Response to Feedback

on the Consultation Paper on Guidelines on Business Continuity Planning, June 2003 21 Bayuk, Jennifer; Stepping Through the InfoSec Program, ISACA, USA, 2007 22 Op cit, Pironti 23 Drew, Doug; Payment Card Industry Data Security Standard in the Real World, Information Systems Control Journal, vol. 5, 2008

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal. Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors content. 2009 ISACA. All rights reserved. Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25 per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited. www.isaca.org
ISACA JOURNAL VOLUME 5, 2009