Mitigating Catastrophic Risks of Smart Meters

I posed a question on quora.com about whether it was feasible to design smart meters so that the power couldn’t be entirely shut off by remote control. In particular, I wanted to know if some small portion of the power could be on a separate mechanism that would require a physical visit by the utility company to shut it off.

The question received an articulate, passionate, and well-reasoned response that explained why such a design should not be pursued. The author made good points about motor burnouts, damaged equipment, and so on - it was apparent that he was familiar with the topic of electricity. He also implied that my design suggestion was downright dangerous, and perhaps indicated a lack of thoughtfulness on my part for even considering such a design.

I explained that I was concerned that a cyber attacker could remotely shut off power to tens or hundreds of thousands of electrical utility customers and then brick (render inoperable) the remote control unit. This of course would require the utility company to physically visit every customer to restore power. This would especially affect those who need power for medical devices.

The passionate respondent replied:

"That’s a good point, I never thought of that."

This is the nature of risk in complex systems: risks have a tendency to emerge from unexpected places when evaluated solely by experts in specific domains. Experts tend to bring specific training, specialized ethics, implied goals, and certain types of experiences. This narrow focus is good for daily work, but can negatively affect risk assessments. In the case of the passionate respondent it's clear that the electrical system and equipment were front and center, perhaps summarized by a mantra of "don't damage equipment!" However, in the broader context, this important principle/ethic was too narrow to address broad needs and stakeholder expectations. In this case it came down to a framing issue. 

How should risk assessments be designed so that they avoid the issues of being too narrowly focused? Here are a few ideas:

1. Define the target of the risk assessment in terms that have relevancy to stakeholders.
2. Invite stakeholders who can, as directly as possible, represent the interests and perspectives of the diverse set of groups who derive benefits(1) from the target.
3. Solicit these stakeholders to identify their key benefits or needs relative to the target.
4. Focus the risk assessment on risks to benefits rather than on technical risks. 
5. Assume that intellectually "ideal" technical solutions are probably flawed from various non-technical perspectives, and elicit those flaws from all participants (especially the non-technical and non-experts).
6. Design the process and conduct the assessment so that unpopular or unorthodox ideas are not unduly suppressed or swamped.

To risk assessors everywhere: happy hunting!

(1) Benefits in this context is meant to be all-inclusive, but could be substituted with value, dependencies, goal achievement, meeting objectives, accomplishing mission, and so on.  

What is a "Leading" Compliance Function?

A friend ask me not too long ago: “How do you measure the maturity of a compliance function?”

As I think of an organization "leading on compliance," ironically, I think of the compliance function as following not leading, and being concerned more with risk than compliance.

Let me explain. Compliance covers some things, and organizational need covers some things. In the most mature organizations, I think that 90-95% of compliance needs are covered if the organizational needs are being met with efficiency and effectivness. In contrast, if compliance needs are covered, it can bear little or no relation to the business needs, the degree to which this occurs is highly dependent upon industry, specific regulation, and company operating behaviors. This is not meant to diminish the importance of compliance, or security, or HR, or any other function, but these functions are all small rocks. Business is the big rocks. For everything to fit into the jar, the big rocks have to go in first. (http://www.appleseeds.org/Big-Rocks_Covey.htm) So, frustratingly, to achieve the highest maturity of compliance, you need the organization to be operating at the highest levels of maturity as well. Otherwise, compliance before business could cause the business to decrease the size of a business rock, or simply not attempt to get one more business rock into the jar.

So the question I like to ask is: how does the compliance function operate in a way that encourages the organization to recognize and act on what it needs to do from a larger organizational perspective, *while* allowing compliance to focus on the specific things it needs to do to fill in with compliance between the bigger business rocks? Note: If you can do this, not only will you be meeting all your obligations, but people will also like you a lot more.

Culture and processes and collaboration are core, for both compliance and risk management . GRC for me is about efficiency, and some enablement. You can’t get to the highest levels of maturity without GRC, but if you lead with GRC, it’s unlikely you’ll get to even the mid-levels of maturity without going back and doing the organizational steps and then re-working GRC, likely taking more time and incurring greater cost, and making people more unhappy.

In regards to risk management… there are definitely differences with compliance. Here’s the crux: Compliance serves those outside of the organization with usually a pretty narrow view of what they want from your organization. Risk management serves your organization and (ideally) does so with the most complete view as reasonable. Specifically, risk management facilitates the allocation of resources towards low risk high profit activities and away from high risk low profit activities (there are definite exceptions, like bold business moves that are long bets but could be highly profitable). Compliance can be viewed as avoiding fines, business interruption due to court orders or withdrawal of licensure or certification, and a few other very specific things; compliance is one type of risk among many.

 

Here’s how I think about it: Formal risk management is decision support, and should be a core element of decision making organization wide. In reality, risk management already is at the core of every decision, but it’s not usually formal. Compliance is a double check. 

In regards to compliance, here are some things that I would consider in determining maturity:

• Is compliance viewed as a trigger for the business to think about risk (of which compliance is a subset) 
• Does compliance have a view into business processes and understand the business context
• To what degree does compliance talk about risks of non-compliance (vs. taking a there-is-no-choice approach)
• Does compliance collaborate on solutions driven by operational needs, with compliance merged in? Or does compliance dictate solutions where compliance trumps regardless of operational perspectives or priorities or feasibility or cost? Is compliance as flexible as it reasonably can be?
• Does compliance seek out the larger problem? For example, does compliance require that the instance they find of an issue be fixed (this is usually an audit perspective as well), or do they seek root causes and process improvement? Let’s face it, no one wants to spend 100 hours to fix what they know is 60% of the problem, when they can spend 130 hours fixing 98% of the problem (you know: actually really solve problems)
• How well does compliance surface issues to the people who are accountable for certain types of compliance? (i.e. HIPAA security officer, HIPAA compliance officer, chief legal council, etc.) (also, this is where GRC helps)
• How strategically aligned is Compliance to the other risk functions such as Internal Audit, Risk Management, Information Security, IT Audit/Compliance, and possibly others? How tactically aligned are they? Is annual planning done together (e.g. divide and conquer, no overlap, etc)? Are major findings shared?
• Does compliance adopt business language and align where possible to business measures, or operate as an island unto itself (again, a little bit of that there-is-no-choice, compliance-is-it’s-own-thing attitude)?

Although Norman Marks is fairly widely respected, I don’t always agree with him. However, this post on GRC is worth a look, https://iaonline.theiia.org/blogs/marks/2015/trends-in-grc, especially the links, specifically to items from OECG like this: http://www.oceg.org/lesson/principled-performance-and-grc/ (I watched this for the first time tonight, after writing all of the above, and it echo’s many of the things I say above and adds to it), and the blog he links to, yogrc, looks like a pretty good take specifically on GRC http://yogrc.typepad.com/.

I look forward to your comments and feedback.