GRC Programming: The Third-Party Security Web


Posted on by Roderick Chambers, CISSP, CISM

 

Governance, risk management, and compliance (GRC) are growing disciplines with continuously changing identities. As time goes on and more scrutiny and regulations emerge, leadership teams and boards realize they don’t fully grasp their information security maturity level and how to raise their level to meet various compliance standards and mandates.

 

One of the many challenges GRC practitioners encounter is third-party risk management. When thinking of GRC, it may be viewed as a web of networks and connections. In the center of the web is the glowing, thriving heart of the organization. Where does GRC fit into a web of third-party connections? The role of GRC is to ensure that these extended enterprise relationships share the same values and commitments to integrity that define the core organization.

 

Because organizations have expanded their reliance on third parties, some have unknowingly created a dangerous web of third-party relationships that appears to have no boundaries. Managing this web is challenging, as the organization must manage the performance/objectives, risk, and compliance at the relationship level and the contract, facility, and service levels.

 

The Unknown Risk

Expansion from mergers and acquisitions, reaching a new customer base, and even creating global operations have created operational silos. The IT security team has processes and technologies focused on security, and the corporate compliance and ethics teams are concerned about anti-money laundering laws and corruption. Each business unit has its procedures for managing third-party relationships. For those old enough to remember the Enron scandal, accounting has the Sarbanes-Oxley (SOX) Act of compliance mandates spawned from the scandal. These silos result in not viewing the full spectrum of the risk and exposure in these relationships. A web expansion of this size, complexity, and criticality to business operations often relies on a once-per-year audit or security questionnaire. Often, what is missing is the governance of these relationships. While organizations focus on the silos of risk, they often forget to put in context how these third-party relationships deliver on performance and objectives.

 

Silo Breakers—Holistic GRC Programming

To transform with a focus on third-party GRC programming, there needs to be a strategic purpose and direction clearly outlined. In a holistic program, third-party GRC is the ability to reliably achieve objectives [GOVERNANCE] while addressing uncertainty [RISK MANAGEMENT] and acting with integrity [COMPLIANCE] in and across the web of the organization’s third-party relationships. When evaluating this model, each relationship has a purpose. But how will organizations move beyond a partial view of their third-party risk?

 

Start to mature and transform programming by baselining and standardizing Key Performance Indicators (KPIs) and Key Risk Indicators (KRIs). For those unfamiliar with these terms, KPIs measure the performance and effectiveness of third-party GRC functions and processes. KRIs determine how much risk the organizations are exposed to and what risk treatment plans to apply.

 

Some metrics that are best practices for measuring are quantified and balanced risk profiling, vendor threat intelligence, context-driven compliance, and global and local view of the supplier’s coverage. With quantified and balanced risk, organizations can analyze and understand the risk of doing business with this supplier and associated mitigations.

 

Vendor threat intelligence is collected through open-source intelligence data on the supplier base. Mean time to acknowledge (MTTA) is an example used by internal account managers after threat intelligence reveals an adverse event. Context-driven compliance builds on understanding the context and commitments of the third party. How compliant are my suppliers with the organization’s internal control environment?

 

Last, build a global view and local lens of the third parties. The organization must ensure they know the global supplier footprint. Has the organization created a profile of the full coverage of the supplier footprint, and are they tiered appropriately for GLOBAL business?

 

Why Advocate Meaningful Metrics?

How organizations report that risk to business stakeholders is as significant as capturing and quantifying the risk. The value is negated if the reporting is complex, challenging to understand, and not placed in context. A mature program evolves from spreadsheets to purpose-built platforms that provide the required multi-stakeholder lenses on the data. The security team alone is not responsible for reducing supply chain risk; organizations need meaningful metrics to inform the rest of the stakeholders of their required actions to manage risk collectively.

 

The inclusion of meaningful metrics allows for the maturity of GRC programming to move from reactive to proactive security posture. Many organizations stay between reactionary stages of the headaches and pains, with GRC practitioners juggling emails, spreadsheets, SharePoint, and other point tools. Eventually, the program moves to programmatically onboard and score vendors for prioritized risk management. However, this process is static, point-in-time, and very manual. With metrics, programming can move out of spreadsheet jail and automate vendor assessments according to the standards that matter to the organization, validate estimates with external, continuous cyber, business, and financial risk monitoring intelligence.

 

Solutions That Deliver

While throwing more technology at a problem is not the only solution, we need technology and tools that can aggregate the data and those meaningful metrics. Tools can also break down silos by standardizing how organizations challenge GRC. Only a few software-as-a-service (SaaS) third-party risk management tools are designed to facilitate third-party risk management. While not leaving the organization in a hopeless state, GRC practitioners are encouraged to utilize the Open Compliance and Ethics Group’s OCEG Red Book—a well-received common industry framework. Last, consider building a roadmap that includes technology and programming. A multi-year security roadmap considers where an organization needs to go in implementing security programs while closely aligning with business objectives. The roadmap consists of an organization’s existing security programs and where those programs need to advance but have the foresight and agility to include tools and technologies that may not yet be invented.


Contributors
Roderick Chambers, CISSP, CISM

Information Security and Intelligence Advisor, New York State Department of Financial Services

Risk Management & Governance

supply chain risk management compliance management policy management governance risk & compliance

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment.  Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA® Conference, RSA Security LLC or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.


Share With Your Community