Part I - Have you identified “Federated Controls" in your Organization?

Part I - Have you identified “Federated Controls?

Outsourcing has significantly changed the way the enterprises used to operate their businesses and today its an accepted fact that they no longer can have a complete control over their business & operating environment.

In other words, enterprises have to trust their service providers to protect their sensitive data or comply with regulatory requirements and most of them are getting this assurance by adopting a reactive approach i.e. thru third party assessments or leveraging SAS70 / SSAE 16 reports rather than thru a proactive collaborative approach. Moreover, the ground reality is that most of these enterprises do not even have a repository of controls that are mapped to the controls being implemented and operated in their service provider’s environment to protect against the compromise of sensitive data or meet regulatory requirements.

As the world is fast moving from outsourcing to cloud computing, there is an increased need for the enterprises to move from a reactive approach to proactive approach (i.e. collaborative in nature) to facilitate each other in protecting themselves against the compromise of sensitive data or meeting their regulatory requirements i.e. the Service Providers and Service Users should trust with each other to form a Federation, map their common controls and collaborate with each other to effectively implement and operate these controls.

To enable this, let me coin the new concept and name it as “Federated Controls”. The concept of Federation is relatively old in Information Security world (Federated Identify is the well known concept) but relatively new Risk & Control world.

“Federated controls are the set of controls that an enterprise relies on their service provider (third party) to implement and operate in the service provider’s environment in order to protect against the compromise of their sensitive data or meeting regulatory requirements”

Enterprises should start categorizing the controls against which they trust their service providers to implement and operate effectively as “Federated Controls” and consolidate them to develop a Federated Controls Matrix (FCM).

FCM will help the enterprise to have a holistic view of set of controls that are implemented and operated by their service providers and in obtaining the assurance on their design and operating effectiveness. ,

Part II – Developing a Federated Control Framework follows…

Compliance Calendar / Dashboard – A missing component of GRC Tools / Evangelists

One of the key drivers of GRC is compliance to ever growing number of regulations by the organizations.

These regulations require organizations to perform certain internal procedures and submit various reports / documents or make certain disclosures to authorities within stipulated timelines.

No doubt these requirements have lead to increased cost of compliance and at the same time, any non-compliance will result not only in attraction of fines etc but also the imprisonment of senior executives...

That’s why today’s mantra of most of the GRC evangelists is “Test once; comply with all”

I think most of the GRC tools as well as consultants are more focused to facilitate the testing and reporting of the compliance requirements by the assurance functions of an enterprise but what seems to be missing is the Prospective (requirements) of the Top Management (In fact, there is always a gap between what management wants and what assurance function provides especially from a value on GRC investment prospective)

For instance, the management can see more value, when they can get a compliance dashboard which will show all the regulations (single view) that the enterprise need to comply along with due dates and their compliance status where as most of the GRC tools / consultants focus to deliver the individual regulation wide status (say SOX compliance is giving a report on SOX, Privacy on GLBA / HIPPA etc separately) which does not give a holistic view of compliance status across enterprise (management need to move between different solutions / reports to get the status, certainly an irritating factor).

In my opinion, the GRC solution providers as well as the preachers should focus on the providing solutions from a top down regulatory approach so that the management can view the compliance status from compliance dashboard and at the same time can drill down to record level details, if required.

Not only has the management, even the compliance owners (control owners) sometimes frustrated because they are not aware of the compliance requirements scheduled for different regulations or the impact of non-compliance on various regulations (of these regulations).

I hope in the near time, the GRC solution providers / consultants start focusing to develop compliance based calendar with a “Due Date” based workflow & console view across all levels of organization hierarchy to comply, test and report on the compliance to regulatory requirements.

What makes a Risk "RISKY"

It’s evident from the recent debacles in banking sector in US & across globe that most of these companies failed to manage & address risk in spite of having full-fledged risk departments and have implemented best practices in risk management…


This phenomenon is true not only for the above said companies, but equally applicable to each and every other organization because at some of time they would have experienced the occurrence of risk events in spite of control in place and operating effectively…

“Where did it go wrong” … This is the question that lingers almost in the minds of every one and that’s where a thought comes to mind “what makes a Risk “Risky”?”

I am sure the answer this question from most of the individuals will be either lack of adequate controls or existing controls not operating effectively and I agree with them but there is one more dimension that most of us (individuals or even the risk managers) tend to ignore is “Risk Measurement”…

Risk Measurement (i.e. risk rating) is a significant activity of risk management which most of the organizations including risk management professionals tend to pay lesser attention to it and do it as an eye washing exercise.

What we tend to ignore is that risk rating is the process of mapping the “Risk Appetite & Culture” of the organization to risk management as well as forms a basis for defining the controls to be in place. In other words, risk measurement has a significant role to play in occurrence of risk event and has a significant impact on the cost of managing risks as well as the return on investment in risk management…

For instance, if an insignificant risk is rated as “Critical / High”, obviously controls will be designed and implemented to mitigate the same… Any control implemented in the organization is cost (direct or indirect) to the organization…

Therefore, a bulk of unnecessary / redundant controls will significantly impacts both the design and operating costs of managing controls and thereby impacting the return on risk management…

Take the same example, if a significant risk (critical risk) is rated as “low” risk, obviously less or no controls in place. This is what comes out as “Risk Events” in the organization and surprises every one…

In other words, it’s clear that risk measurement plays a critical role in entire risk management. Having said that, no doubt I agree that risk measurement is not a simple task as being looked on the face of it…

Risk Measurement, apart from rating levels, requires normalization of the impact of risk appetite of the individuals involved in rating the risk, as well as providing objective (historical data / artifacts) data to support risk rating…

The Risk Managers as well as Risk Assessment Tools should include techniques such as “Delphi Technique” etc to normalize the impact of risk appetite of the individuals rating the risk and to set the process for collecting, analyzing and providing objective information for effective risk rating.

It is only then; we can address one of the significant dimensions of the risk and make it “Less Risky”…

GRC Initiative - is it a Project or Program or a Function?

GRC gained momentum in the assurance world... Today across globe the organizations moving towards initiating GRC... what confusing is the difference in the way the "Initiative" is referenced by various groups... some call it as "Project", some refer it as "Program" and some as "Function"...


So what's the best way / approach to jump start GRC?

If GRC as a Project, who should initiate the same? is it ERM or Internal audit, Compliance Groups?

If GRC as a Program, who should initiate and who all should be involved? Who will drive and manage the entire program? Is it requiring a separate program office? If so what their role and responsibilities? etc

If GRC as a Function, who should initiate and how this should be structured in the organizational hierarchy? is this an independent function co-exist with other assurance groups such as internal audit etc or a super function sitting on top of other assurance groups? What will be the impact?

These are some of the questions that lingering in the minds of many on GRC...

In my view, the GRC initiative in an organization is more than a "Project"... Though it has some ingredients to be qualified as project, keeping in view the involvement required from various stakeholders, it will definitely fit to be qualified as "Program". in other words, the entire GRC initiative consists of multiple projects to be implemented across groups, long period of time in order to achieve its objectives and enjoy the benefits of GRC.

Ideally the GRC initiative should start with creating a GRC program group drawing representations from the various assurance groups as well as from the senior management within the organization. The GRC program group should set the vision, expectations, measures and metrics of the program. in reality, most of the times the group plays a role of coordinator role (as it does not have hierarchical identity) resulting the delays or cost overruns and ultimately jeopardizing the very objectives of the program itself...

Another dimension of GRC program can be a Function... GRC can be set as super function sitting on top of all other assurance groups... this results not only unification at governance, risks & controls front but also at resources front (most the times, the individuals part of various assurance groups do have overlapping skills... these skills can be effectively utilized). Of course on the other hand, it is difficult to set up due to several issues that may emerge due to merger of assurance groups within the organization apart from challenges on change management & transition...

So what’s the best approach? In my opinion the GRC should start as a "Project" and mature to the next level as "Program" and ultimately mature to become a "Function" within the organization...