If you’ve read the first two posts in this series (here and here), you realize that for these posts I’ve tried to forget everything I know or have written about CIP-013, and just work through the words of the requirements (and the Purpose statement at the beginning of the standard). My goal has been to mine what is actually written in the requirements and get it all out on the table. The reason I’m doing this is because nothing is binding on the auditors (and therefore on the NERC entity) except what is in the requirements. So it’s important to put in a lot of effort to pull apart the requirements to find everything that’s possible to find in them – before we start going beyond what the wording says and start to think about the best way to actually comply with the requirements.
In our last episode, we wallowed in R1 and found – to my genuine surprise – that there is something important missing from R1.1: While this requirement mandates that the NERC entity “identify and assess” cyber security risks in the supply chain, it doesn’t require them to do anything about them! Of course, this is clearly just a mistake, and I highly recommended that everyone assume the word “mitigate” is also in there, whether or not this problem ever gets fixed in a formal manner.
Now we’re ready to go on to R2, which on the surface seems quite simple:
R2. Each Responsible Entity shall implement its supply chain cyber security risk management plan(s) specified in Requirement R1.
Is this really that simple? Yes and no. It isn’t simple because of what I just pointed out about R1.1: Your supply chain cyber security plan must include mitigation of the risks you’ve identified and assessed, even though that step isn’t included in the requirement part; so you need to mitigate risks when you implement the plan as well. But it is simple because it doesn’t mandate anything about how the plan needs to be implemented.
It seems you’re on your own in this requirement. You have to implement the plan, but you might take one year or 50 years. You might complete one part before starting on the next one, or you might address all parts simultaneously and try to complete them all at the same time. You might prototype your plan in one part of the company before moving it to others, etc. It seems the details are all up to you.
Indeed, this idea is reinforced in spades by the Implementation Guidance document put out by the CIP-013 drafting team last year. The document says literally nothing about what must be done to implement the plan, beyond repeating the substance of the note that appears below R2, emphasizing that the entity isn’t required to renegotiate or abrogate existing vendor contracts. It seems the drafting team couldn’t think of anything important to say about implementation.
However, let’s be realistic: The details of implementing a NERC CIP standard are never up to you. Last fall, I looked at the industry’s early experience with audits of CIP-014; like CIP-013, this standard requires the entity to develop a plan (in this case, a physical security plan for key substations) and then implement it. In two posts (here and here), I told several stories that point to the same conclusion: Even though R2 lacks any details about what constitutes a good vs. a bad implementation, the auditors are going to have their own ideas, and they won’t hesitate to make these known to the entity if they think they haven’t done a good job of implementation[i]. They hopefully won’t actually issue a Potential Non-Compliance (PNC) finding, as they did to one of the entities discussed in the second post. But they will very likely identify an Area of Concern and require the entity to fix the problem identified.
So what are the auditors going to look to when they decide whether or not an entity has properly implemented their supply chain cyber security risk management plan from CIP-013 R1? Darned if I know, but there is one thing of which I’m sure: I’m sure that auditors will look at the actual timeline for completing the implementation, and how that compares with what is in the plan.
Say your plan lays out a two-year implementation schedule, and your next audit is scheduled for about 1 ½ years after you start the implementation. If the auditors show up on that date and decide there’s no way your implementation can be completed by the two-year mark, they will very likely issue an Area of Concern, meaning you will need to develop a new plan with a realistic implementation date. And you’d better make that new date, or you’ll be in trouble three years later at your next audit.
So what does this mean for your plan? Should you always sandbag the finish date in the plan, making it at least a year or two after the date you think you’ll really finish? I don’t really think this is a great idea. I think you should include in your plan what you honestly believe is the date you will finish your implementation. However, I also think you should keep very close tabs on the implementation. Whenever it begins to look like you will not be able to meet your original finish date, you should immediately revise the plan to reflect the new date (of course, you should have change control to document that you made this change. You certainly don’t want to be in the position of needing to convince the auditor that the revised plan was actually the original one!).
Of course, if the auditor doesn’t agree with your excuse for why the implementation date had to be moved back (e.g. “My dog ate our supply chain cyber security risk management plan and we didn’t have any backup. This forced a six-month implementation delay as we re-drafted the plan from scratch.”), they may disagree with you. But IMHO there is no way they can issue you a PNC because of this, since R2 is completely silent on what characterizes a good vs. a bad implementation.[ii]
What’s the moral of this story? Even though R2 looks like it’s wide open to whatever interpretation you might want to give it, this doesn’t mean you should simply do whatever you want when you implement your supply chain cyber security risk management plan. The auditors will always have their idea of how a plan should be implemented. It is almost certain that they will make their ideas clear to you in your audit, even if – hopefully – they don’t resort to a PNC to do that.
But what if it didn’t need to be this way? What if there were a way you could get your auditors (or at least your Regional Entity) to weigh in on whether and how your plan should be changed, before you started to implement it? That is the question I discussed in this recent post. There needs to be some way a NERC entity can get their CIP-013 R1 plan reviewed by their Region before they embark on implementing it. Moreover, there needs to be some way the Region can check in on the implementation of that plan as it is in progress, to make sure the entity hasn’t made some big mistake that might force it to re-do some or all of what it has already done.
The post described, with the assistance of an auditor, the Entity Development teams that are already implemented in one NERC Region and being implemented in another. The members of these teams aren’t auditors, but they help entities comply with the NERC CIP standards (and possibly other NERC standards). It seems to me that these teams would be the ideal organization to review an entity’s CIP-013 R1 plan as well as its implementation, before the entity has invested a sizable sum in implementation of what could turn out to be a flawed plan
I believe that some mechanism like this needs to be in place, in order for CIP-013 (as well as other plan-based standards like CIP-014 and the upcoming CIP-012, along with plan-based requirements like CIP-003 R2 and CIP-010 R4) to be successful. I hope you agree with me on this (and if not, that you’ll let me know). I hope NERC does, too!
If you would like to comment on what you have read here, I would love to hear from you. Please email me at email@example.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. You can email me at the same address or call me at 312-515-8996.
[i] To be honest, the auditor issues in the second of the two posts cited (i.e. Part 3 of the series on lessons from CIP-014) had to do mostly with the plan itself, not with its implementation. But that is just because of timing: The two audits discussed in that post both occurred before the entity had even been able to start to implement their plan. Of course, this was very beneficial, since – had they implemented the plan, which was later determined to be insufficient, they might have been forced to re-do some or all of their implementation, using a new plan that was deemed sufficient.
[ii] They might conceivably issue you a PNC for violating CIP-011 R1.2, since the plan presumably included BES Cyber System Information and you obviously didn’t have a very good plan for protecting BCSI from your dog.