Ensuring Compliance Within GRC

In this article we will be looking at Compliance within GRC. Our broad definition of compliance is ensuring that a series of controls are established that ensure that decisions are made and are prioritised in accordance with accepted policy.

We have included the decision-making process that is consequential to ‘being in accordance with’ as a necessary condition because compliance from our earlier definition (see Article 2 in this series) includes manage risk, deliver measurable benefit and standards.

If compliance is not properly managed even well-designed regulatory, legislative and standards management may lead to dysfunctional organisational responses. It is necessary to establish an organisational approach that encourages compliance and provides the relevant internal and external compliance structures with information regarding compliance assessment outcomes. The compliance approach should ensure that individuals, teams, business units or organisations that are not complying are identified. Those who do comply should not be subject to unnecessary compliance costs.

Compliance Obligations

Compliance obligations are sourced internally and externally to the organisation. Those external typically fall into 3 areas:

  • Legal and Regulatory Obligations
    • Typically mandated by law and therefore an enterprise must comply or face serious consequences
  • Industry Standards
    • Established by industry bodies and are then selected by IT for adoption
    •  Industry standards offer potential for interoperation and sharing across the organisation, but also fall outside of the control of the organisation and must therefore be actively monitored
  •  Organizational Standards
    • Set within the organization and are based on business aspiration
    • Organizational standards require processes to allow for dispensations and standards evolution.

Compliance is the mechanism that ensures that the guidance and direction of experts external and internal to the organisation are adhered to. The author’s observation of compliance with internal standards is not always treated with the same discipline as with external compliance obligations. Whether this is because the sanctions that can be applied for non-compliance with regulation and legislation can be punitive in the extreme (fines and potentially prison sentences) while non-compliance with internal standards, policies etc. are often perceived as not significant transgressions is not clear.

Another mechanism that is beginning to makes its mark in the compliance space is the principle1. This is essentially a statement of guidance and direction without having to have the full text of all the rules and regulations. For example the FCA (Financial Conduct Authority) in the UK has taken a position in favour of principles-based regulation.

Principles-based compliance can be just as, if not more, robust than a rules-based compliance framework and is better equipped to adapt effectively to continuously changing circumstances. However to implement such an approach requires highly skilled and competent supervision.

Compliance Lifecycle

Every organisation will experience changes to its compliance obligations on an ongoing basis – and most of the time changes in the regulatory and legislative areas do not follow any particular schedule.

compliance-life-cycle (done)

 

This constant change requires that compliance is lifecycle managed within the organisation. We propose a simple 5-step process:

  • Compliance Source Monitoring:
    • This requires (a) the identification of all relevant compliance obligation that the organisation must meet (internal and external) and (b) a monitoring and scanning capability that will alert the GRC function to any changes that impact our compliance landscape
  •  Policy, Procedure and Standards Management
    • All policies, procedures and standards will have to be registered, assessed for relevance and validity before being taken-on (adopted) by the organisation – and equally when the compliance material is to be withdrawn this must be done under formal change management
  • Controls Management
    • As a result of the take-on of compliance obligations it is necessary to assess the controls landscape and adjust as necessary – timing, ownership, events causing the control to execute etc.
  • Compliance Assessment
    • During the life of the organisation, programmes and projects it is necessary specific activities are undertaken to assess compliance – typically these are manual activities and extend the compliance capability of the organisation by introducing internal compliance obligations as well
  • Compliance Reporting
    All compliance activities must be reported as due process and best practice

This simplified view of the compliance lifecycle must necessarily be extended, implemented and deployed depending on the organisational context and the content of the compliance material – typically this will fall under the remit of the GRC organisation/practice.

Managing Compliance

Generally when compliance is achieved this is seen to be a good thing, however there are cases when our projects, programmes etc. are not compliant – is this bad? What do we do? We have a number of options:

  1. Ignore the non-compliance
  2. Grant a waiver or exception
  3. Stop the project or programme

None of these is optimal for different reasons – (1) and (2) can set unwanted precedents that others might follow, while (3) may not be possible politically or from a project delivery perspective.

From a GRC perspective we prefer to deal with non-compliance through the mechanism known as a dispensation. This is structurally similar to (2) above with the following 2 important features:

  • It is time-bound within the current cycle of compliance activities – meaning that the dispensation is only valid for a given window of time
  • The risk-profile of the programme or project must be assessed and a accepted formally by a risk owner (typically in IT projects this is the project sponsor)

The dispensation is a very useful and proactive mechanism in that it allows us to manage programme/project compliance as well as the political implications – often projects cannot be stopped for various reasons e.g. because of the down-line effects on shareprice where announcements have been made to shareholders, dependencies of other areas of the business on the current project.

Compliance should support a number of benefits such as:

  • Confidence in IT and other areas under control
  • Transparency of cost, risks and benefits
  • Probability of selecting IT investments with the best potential
  • Accountability of identified parties and management in the organisation
  • Compliance with internal and external obligations
  • Requirements for audit, assurance, monitoring and reporting performed by the compliance function with input from business areas.

Standards Framework

As part of the compliance capability of GRC we need to investigate standards through the mechanism of a standards framework.

standards framework

The framework we propose is based on three fundamental concepts – a taxonomy, a set of processes and a mapping. The standards managed within this framework form a key portion of the compliance obligations mentioned above.

Standards are often mandated through use of policy and in turn can be used to identify specific mandatory controls – all of which help to ensure consistency across the organisation and usually contain controls relating to the implementation of specific technology, hardware, software or services.

Takeaway messages …

Compliance is a both a requirement and a necessary evil – however as a structural capability within GRC it is a powerful mechanism for ensuring that the organisation processes and structures follow best-practice direction and guidance.