Building GRC on a Cybersecurity Foundation

Businesses are drowning in a deluge of three things: cybersecurity risk, regulatory compliance demands, and risk management frameworks. So when I moderated a webinar recently on how you could simplify all that effort by building your GRC program on a foundation of strong cybersecurity, I took lots of notes.

First, what do we even mean by “building your GRC program on a foundation of strong cybersecurity?” Let’s consider an example: multi-factor authentication.

“MFA” is foremost a cybersecurity control: users must enter a password to log into an account and have a physical device (a phone, usually) that receives a confirmation code from the system; only then can you gain access to the IT system to do your thing. A company might implement MFA for access to important systems or privileged user accounts, or for any remote access at all.

Except, MFA is also a requirement in numerous regulations and standards, such as the New York Cybersecurity Regulation, the PCI-DSS standard for credit card security, and the FedRAMP rules for cloud services at government agencies. It’s a standard demand in security-related enforcement actions from the Federal Trade Commission and other agencies, too. 

So a company could take a compliance-focused approach to MFA, where it says, “Oh crap, we need to implement six different frameworks that all mention MFA somehow!” Then you painstakingly work through one framework after another, making sure those MFA controls are properly implemented according to each framework’s dictates. 

Or the company could take a risk-focused approach to MFA, where it says, “Oh crap, we have sensitive accounts all over the place! Let’s implement MFA to protect our most critical assets from unauthorized access.” That approach won’t necessarily satisfy all your regulatory requirements for strong security, but it will make your efforts to fulfill those compliance obligations much easier as said obligations come along.

That’s the theory, at least. So how can all that work in practice? 

Strategy and Alignment, Not Technology

One point that came up a lot in our webinar: that this is a challenge of strategy and alignment so that everyone understands how and why your controls might be changed; not a challenge of technology to do the actual changing. 

Go back to our MFA example. If you want to implement MFA for all remote access to the network, that’s going to be a pain for First Line teams trying to access data from the road. So before you implement MFA, you (the compliance team and IT security team) need to win over leaders of the First Line operating units to the importance of that change.

I’m sure everyone reading the above paragraph agrees with the theory of it — but consider how you’d make it work in practice. You can’t simply assign a junior-level IT whiz to the project (“Let’s put Joe on that GRC project, he’s good with computers and needs something to do”) because that junior-level specialist won’t know or appreciate the consequences of overhauling your controls. He won’t be respected by the head of sales or R&D or product development or whatever, when he tells them that their teams now need to take extra steps to log into data they need.

“You can’t treat this as a side project,” one webinar speaker said. “Alignment is key, but it’s alignment across multiple business teams with deep-rooted processes. They don’t want to be disrupted.” 

If you want to streamline your GRC program and shift it to a cybersecurity foundation, you’ll need a team of more senior people who understand the company’s operating processes and objectives. Moreover, those people will need to be senior enough to make actual decisions, and whose decisions will be respected. 

Two more thoughts here. First, all this underlines the importance of the board and senior management making cybersecurity a top strategic priority. If they don’t give their imprimatur to this effort, then the compliance, IT, and security leaders won’t have that authority to make and enforce decisions that we just mentioned. When you hear that cliché best practice, “The board needs to take cybersecurity seriously!” — this is what that means.

Second, what happens if you don’t put strategy and alignment first; and let junior whiz kid Joe run the project? You’ll end up with more controls for control’s sake, with little actual purpose. One webinar panelist referred to them as “zombie controls.” 

We all know what happens next: employees in the First and Second line teams spend their time developing work-arounds to avoid the zombie controls, and good luck capturing that “work-around risk” in your risk assessment. You’ll be spending more time and money on more control activities, without reducing risk — in fact, you’ll be introducing more risk as employees develop work arounds — and lord help you when a disaster still happens after all that, and senior management is looking for scalps. 

But the Technology Stuff…?

OK, let’s assume senior management does support a project to reframe your GRC program as one based on cybersecurity, with strategy and alignment secured. What then? What do you, the compliance or GRC leader, actually do? 

In broad strokes, you want to… 

• Identify all your organization’s cybersecurity risks, tons of which will relate to poorly designed access control; 
• Identify all your security-related regulatory compliance obligations, from Sarbanes-Oxley to the New York Cybersecurity Rule to PCI-DSS and the scads of privacy laws out there;
• Perform… 

Wait — you were expecting that third bullet point to be something like, “Perform a gap analysis to see which controls you do or don’t already have that match those regulatory requirements,” weren’t you? 

Not quite. You certainly can and should take that step, but tread carefully here. You might find lots of holes in that analysis, where you’re missing a needed control; but that doesn’t automatically mean you should add a new control to seal up that gap. In fact, automatically slapping in additional controls is exactly what we warned about before: more controls for control’s sake. 

Somewhere in our incomplete list of bullet points above, you need to include, “Consider how you could design the control to simplify the burden on users while strengthening cybersecurity.” 

Again, multi-factor authentication is a great example here. The ideal is that you have fewer, stronger access controls: multi-factor authentication used with single sign-on — so that employees are hassled only once, but hassled thoroughly; then they can access their systems without further hindrance. 

Re-imagining the design of controls is the exercise here. Technology is indispensable to all that. AI in particular can help you to automate control-mapping, regulatory change management, and gap analysis. But you’ll still need the human element to reach consensus on strategy and to make decisions on control design. 

That’s enough for today, and we can unpack much more about  “cybersecurity-grounded GRC” in the future — but don’t let the technology terms fool you. As always, the success of GRC depends upon the human element.