JOnline: Compliance Management: A Holistic Approach 

Download Article

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

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.

Figure 2

Good governance addresses deficiencies such as inadequate understanding of risk and behavior, poor information flows, and poor communication. Enterprises that create a culture of compliance and risk management throughout the organization to emphasize the importance of compliance have a higher chance of success in compliance. Compliance needs to be seen less as a function and more as an institutional state of mind, helping organizations to anticipate risk as well as to avoid it.7 One way to demonstrate management’s emphasis on compliance is to include compliance in performance appraisals and discipline staff members who have noncompliance incident(s).

A crucial element in compliance is staff. Processes should be in place to ensure that all personnel are properly briefed and/or trained in requirements (including new requirements) 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 compliance management process involves the following, which will be described in more detail in subsequent sections:

  • Identification of requirements
  • Interpretation of requirements and impact analysis
  • Scope determination
  • Data collection and identification of compliance issue(s)
  • Risk analysis
  • Implementation of appropriate action(s) for compliance issue(s)
  • Reporting and monitoring
  • Continuous improvement

Throughout the compliance management process, there should be early involvement of and continuous communication among relevant parties to avoid a silo-based approach to compliance. Management can also use an information system in the compliance management process for defining, collecting, reporting and monitoring compliance information.

Enterprises can establish metrics for ongoing compliance measurement and management. Potential key performance indicators (KPIs) for management to monitor include cost of compliance, financial impact of noncompliance incidents (e.g., fines/penalties paid to regulators/customers), number of incidents of noncompliance, number of audit findings and number of incidents of risk acceptance approved. Management can analyze KPIs to create actionable reports about the risk posture of the organization and provide insight into the effectiveness of the risk management program8 and compliance.

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.

Figure 3Scope 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 company’s 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 Sarbanes- Oxley 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 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

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). Management’s 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/ regulator’s 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, 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


It is important to adopt an integrated approach instead of a silo-based 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 Sarbanes- Oxley 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 faced by the enterprise, industry and world.


1 IT Governance Institute (ITGI), IT Control Objectives for Basel II: The Importance of Governance and Risk Management for Compliance, USA, 2007,
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 Auditor’s 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,
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

ISACA Journal, formerly Information Systems Control Journal, is published by ISACA, a nonprofit organization created for the public in 1969. 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.

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.

Subscription Rates:
US: one year (6 issues) $75.00
All international orders: one year (6 issues) $90.00
Remittance must be made in US funds.