Governance, Risk, and Compliance Framework

GRC is a strategy, not a tool or a solution. It is a meta-process for managing a series of important and interrelated sub-processes in the modern corporation. GRC isn’t merely about following rules and checking boxes. Its overarching purpose is protecting the organization, managing uncertainty and empowering leaders to make the best possible decisions.

GRC stands for governance, risk and compliance. There’s a tendency to perceive GRC as an overly complicated set of administrative tasks, but that’s like calling a recipe for a great meal a boring list of ingredients and cooking instructions. When people enjoy a wonderful dining experience, they’re usually not thinking about the work that went into preparing it.

Rather than thinking about GRC simply as a path to compliance, it makes more sense to see it as an essential strategy for safeguarding the overall health of the organization. Today’s economy is global and interconnected. Modern markets are complex, dynamic and volatile. They evolve rapidly, presenting business leaders with constantly shifting landscapes.

New challenges and problems arise with astonishing speed, requiring immediate attention. Yet each new decision has a ripple effect, which makes it difficult to predict results with absolute certainty. One of the main benefits of GRC is that it enables the corporation to make business decisions based on clear-eyed appraisals of risk, instead of making guesses and hoping for the best outcomes.

GRC helps us deal with the ever-present uncertainty of the 21^st century. Think of it as a shield against chaos, or as a proactive methodology for managing risk in turbulent times. No matter how you describe it, GRC is essential to the survival and success of every business in the digital age.

‘Test Once, Comply Many’

A good working relationship between the security team and the GRC team is imperative. The security team is responsible for ensuring that the company’s digital assets and processes are safe and secure. Additionally, the security team is responsible for providing evidence to the business units (and to other functions, such as legal and HR) that required security measures are being followed consistently and properly.

From a security perspective, GRC responsibilities become more challenging when the company lacks a unified compliance framework. A unified framework is necessary to prevent the business from peppering security with endless requests for evidence of compliance with security control regulations and requirements. For someone who has never participated in a GRC process, this might seem like a trivial matter. But it is critical, and here’s why: There are dozens of security control frameworks.^[1]  

In addition to frameworks such as Sarbanes Oxley Section 404 (SOX 404), ISO 27000 Series, the NIST Cybersecurity Framework (NIST-CSF) and the Personal Information Protection and Electronic Documents Act (PIPEDA), there’s also the Federal Information Systems Management Act (FISMA), the HIPAA Security Rule (HSR), Cloud Security Alliance (CSA), NERC CIP, DFARS and the Security Controls Framework (SCF).

And there’s also the Federal Risk and Authorization Management Program (FEDRAMP), the Payment Card Industry-Data Security Standard (PCI-DSS), the Gramm-Leach-Bliley Act (GLBA), the EU’s General Data Protection Regulation (GDPR) and the NYCRR 500 regulation created by the New York State Department of Financial Services.

There is a dizzying array of frameworks – too many to keep track of, really. Even though some of them may be irrelevant to your organization, you cannot ignore their existence.

As a security leader, in fact, you should be advocating strongly for a unified approach to compliance. To do otherwise would be inviting an endless stream of grunt work as you dutifully respond to demands for evidence of regulatory compliance from numerous stakeholders.

Ideally, you will create a single framework that takes all of your compliance requirements into account and effectively consolidates them. Then, as the saying goes, you can “test once, comply many.”  Remember, GRC is not intended to be a system for creating meaningless work – it is a strategy for helping the business thrive.

Moreover, GRC is an ongoing strategy, not a once-and-done affair. Ideally, your GRC processes should be running continually in the background, like white noise. The continual nature of GRC makes it a perfect candidate for automation. The more GRC processes and controls you can automate, the better off you will be. Our advice is to make GRC automation a priority.

A Lens for Focusing on What Matters

As we’ve suggested earlier, GRC is a lot more than a random collection of rules and regulations. World-class security leaders leverage GRC principles to develop a better sense of the company’s overall strategy, and to improve their communications with the board-level directors and C-suite.

Viewing the business through the lens of GRC can help you frame conversations with senior executives more effectively. For example, instead of talking about “securing endpoints,” it might be better to position it as a conversation about protecting IP and preventing the loss of important company data.

High-profile incidents and attacks have raised awareness of cyber risks, and senior executives will be more likely to engage if you frame the discussion around the potential business impact of a particular security issue rather than focusing on the technical details.  The net takeaway here is that senior executives will be more willing to listen when you use the language of business to make your points.

Building Bridges Between Multiple Stakeholders

GRC ranges far and wide. Different industries have different sets of GRC use cases. For example, GRC use cases within the financial services industry would likely include compliance management, audit management, risk management and policy management. Use cases within the manufacturing industry might include third-party management, resiliency management, issue management and requirements change management.

It’s also important to remember that GRC processes involve multiple stakeholders, each with their own priorities and obligations. In a typical enterprise, GRC stakeholders would include legal, cybersecurity, human resources, sales, marketing, finance, risk, audit, compliance, customer care, IT and other functional areas.

Again, it’s helpful when looking at GRC to view it as a realm of opportunity, rather than as a burdensome set of chores. For instance, when a company has multiple stakeholders using disparate processes, there are bound to be inefficiencies and waste. GRC can serve as a bridge between stakeholders and as a driving force for harmonizing processes across the company.

Frankly, we find it beneficial to regard GRC as a powerful lever for positive change. GRC can be used to increase the efficiency and consistency of virtually every essential process in the modern organization, and to streamline the flow of information for improving business decisions.

Rules of Engagement

Because GRC involves numerous stakeholders, you need a set of rules for determining who is responsible for doing which tasks and a process for monitoring the status of those tasks to make certain they are performed properly. In other words, you need a governing structure for your GRC strategy. Typically, a company creates a GRC steering committee made up of senior executives who oversee several working committees that are responsible for executing assigned tasks and reporting back to the steering committee on a regular schedule.

The steering committee has the budget and the clout to provide resources and guidance for the working committees. It also serves as a judge and jury, resolving conflicts and mediating disputes between stakeholders.

Each committee will have its own RACI chart or matrix so that all the stakeholders know precisely who is responsible for performing the various tasks and activities required. RACI is an acronym for “responsible, accountable, consulted and informed,” and it’s a useful method for spelling out roles and responsibilities.

The key goal is clarity of purpose. The steering committee provides vision and leadership, while the working committees focus on the nitty-gritty details and make sure that nothing slips between the cracks.

When setting up the committees, take care to ensure that all GRC stakeholders are represented. In addition to obvious players such as legal, finance and HR, make sure that functions such as risk management, vulnerability management, compliance management, third-party risk management, privacy management, breach response, and business continuity all have a seat at the table.

GRC in the Software Development Life Cycle

A recurring theme in this book is the idea that security should not be an afterthought, and that it should be baked thoroughly into the software development life cycle. The same can be said for GRC. Rather than seeing governance, risk and compliance as tasks that are appended to the end of a business process, GRC should start at the beginning and continue until the end of every business process. In brief, it must be integrated into processes, rather than added onto them.

One of the most critical processes in our modern digital economy is the software development life cycle. Several of our esteemed co-authors have already noted that software has achieved a level of power in human culture that would have been difficult to imagine a few decades ago. It’s safe to say that software is – and will continue to be – a prime driver of wealth and prosperity in markets all over the world.

Considering the power and influence of software over our lives, doesn’t it make sense to build governance and controls into the software development process from the very beginning? As the lines between software and operations become less distinct, doesn’t it make sense to apply GRC principles to the SDLC?

From a practical perspective, GRC should be integrated with SDLC processes and workflows. Regardless of which methodology you are using to develop software (Waterfall, Agile, hybrid, etc.), there should always be some form of governance (e.g., budget, planning, management, requirements, change management), risk management (threat modeling, code analysis, testing, architecture and security reviews), and compliance (controls testing, bug tracking, change management).

At the risk of overstating the case, it seems obvious that business is becoming software and software is becoming business. Let’s not wait until the two phenomena have fully merged before we decide to act. Now is the time to embed GRC principles and processes into the SDLC. That is our opinion; we look forward to hearing your responses and engaging in spirited conversations with you.