Information technology risk teams know well that the scope of IT risks can be very broad – ranging from technical security risk, to IT operations risk, through to operational risk and enterprise risk. IT risk teams typically have deep skills in risk identification and analysis of information technology components, and many are also quite skilled in making recommendations on risk treatment options. But their scope and point of view is typically limited to technology applications and infrastructure. As the enterprise becomes increasingly complex, and extends out with deep interlocks to customer and supplier eco-systems, IT risk teams’ core competencies need to evolve.
When IT risk teams are effective, they’ve formed partnerships with other risk stakeholders across the organization – business leaders, the chief risk officer, internal audit, information and physical security teams, business resilience groups and vendor management. They understand how IT is linked up the stack to the business, press to get risk appetites defined, and are able to translate risk appetite into acceptable thresholds that IT operational teams can work with.
Here are four critical core capabilities, identified by Yo Delmar, vice president of GRC solutions at MetricStream, that IT risk teams need to develop in order to be truly effective in working with the business.
Click through for four critical core capabilities IT risk teams need to develop in order to be truly effective in working with the business, as identified by Yo Delmar, vice president of GRC solutions at MetricStream.
It’s not just a myopic view from IT anymore – the IT risk team needs a broader purview of the organization, and partnerships with the business, to understand just how closely IT relates to and impacts the business – sales, revenue, reputation, product quality and legal obligations. A critical success factor in building partnerships across different stakeholder groups is to understand what they are trying to achieve through the business process itself – and recognizing that each brings mature disciplines with valid and varied approaches to risk management.
For example, the enterprise risk function will be looking at a different set of risk factors than, say, the operational risk function, audit function, project management office (PMO) or security team. The PMO may be looking at project delivery risk in terms of budget, timelines, resources and third-party suppliers. In parallel, operational risk teams may analyze risks in terms of probable loss, and focus on severity, frequency and velocity. IT risk teams need to be conversant with different approaches to risk management and need to always be digging deeper to see how threats, vulnerabilities and exposures in the IT ecosystem can be woven into risk factors in a meaningful way.
What to do: Be curious, ask questions about how risk is measured, educate yourself and your teams, and reflect back to your stakeholders on how IT components figure into the risk equation.
In many ways, a well-defined risk appetite is both the beginning and the end of good risk management. It always comes back to appetite, and how much risk the organization is willing to take on. Remember: It’s not IT teams that own the risk, it’s the business. Even when we are looking at a granular technical risk on a server or an application, for example, it’s about the business process that technical component is supporting and the real impact or magnitude of a loss that is of interest to the business.
It’s all about managing risks in the context of what the business is trying to achieve – launch or grow a new product or service line; gain consistency in the rollout to a new geographic region; lead a successful merger or acquisition. We have to make sure risk tolerances are mapped to policies that will ultimately govern the behavior of people, processes and systems. Policies, controls and analytics can be calibrated to feed the right key performance and risk indicators that will help leadership make decisions to avoid, treat or transfer risk efficiently and effectively.
What to do: Press leadership to set risk appetites, and get business leaders to help translate these into thresholds, policies and controls.
Risk teams across the organization strive to converge on a common risk and control framework, supported by a common issue and remediation process that supports a wide variety of individual taxonomies, processes, metrics and workflows. This is called federation. Building a federated capability involves understanding what is important to the organization – what truly needs to be considered “common” in order to improve business performance, and what can or must remain federated, but rationalized through a roll-up, in the context of the organization as a whole, its strategic objectives, legal obligations and risk appetite.
For example, a highly distributed organization with very distinct businesses may need to design a broader degree of federation than a global organization that is highly regulated and needs to establish greater consistency and predictability across the business. It’s important to understand your organization’s vision, what is truly important to your organization’s performance and how global and local operations are designed to support core businesses, partners, suppliers and customers.
What to do: Focus on what part of the risk management framework needs to be common, report risks in a holistic way to key stakeholders such as the board or leadership team. Understand how risks roll up. Most importantly, be accepting of differing opinions and perspectives throughout the process.
Technology is essential in building a foundation for a flexible, but common, data model that supports the definition of organizational entities, as well as libraries of policies, risk, controls and assets that everyone shares. This is what we call achieving ‘a single version of the truth.’ Combined with role-based access that permits users to see only that which they are authorized to see, a governance, risk and compliance (GRC) technology platform consolidates and rationalizes information and processes in a way that single solutions cannot.
Furthermore, a GRC platform can reach into the technology ecosystem and pull information in from business, IT and security monitoring systems in order to provide a near-real-time view of risk and compliance. Having information in one centralized place means the organization can slice and dice information to provide analytics and true insights into when and how to take on risk. All of this is essential to moving up the maturity curve to risk intelligence.
What to do: Understand your organization’s GRC ecosystem and leverage what may already be there at the enterprise level, and also extend it into IT.
When an organization has a vision for a collaborative risk management program – integrated where it needs be, yet federated to accommodate unique approaches when it comes to identifying and analyzing risk, the payoff can be enormous in terms of both loss avoidance and agility to pursue new opportunities. Establishing the right foundation by building common objectives with key stakeholders will help IT risk teams strike the right balance that supports the maturity, readiness and strategic intent of the business. It takes a series of successes to create the contagion – the groundswell of support – to have leadership recognize that this collaboration between risk teams requires strategic investment, interlock and infrastructure.
In conclusion: Be an advocate for your organization’s success. Eventually, as IT and business risk management teams build a successful partnership, risk management will be driven into the operational fabric of the organization, and will become the lifeblood of superior performance.