This is part of my ongoing series “Unraveling the Mysteries and Complexities of NERC Compliance.” Read the previous part here: Step Four – Design Great Internal Controls.
Isn’t it wonderful? You’ve designed an amazing controls framework with an awesome set of controls. Victory! Right? Wait. Not so fast. There’s one more piece, it must be deployed!
When controls are deployed they introduce something new into the organization. If you’ve been part of the project you know what the controls are and what’s behind their design. You understand how they work and why they work the way they do. The problem is, the people you expect to use these controls don’t know what you know!
People require information to make decisions and choose actions. To use the controls, each person must know what their role or roles are within the controls program. They must also know how to do the work their role or roles are responsible for.
I must now introduce the term alligator into our discussion. No, I’m not talking about the reptile. In this case, an alligator is a problem waiting to happen, typically something easy to overlook even though it has potentially dire consequences. Here’s the challenge.
We’ve already got Roles and Responsibilities for the people in our organizations aligned to the job they perform. No problem, right? We just map those Roles over to our compliance control framework, and bingo, it’s a perfect world. Right?
Ok, so what’s the problem? Those Job Roles aren’t going to map cleanly over to compliance roles. For example, with Patch Management we need someone to collect patches from monitored sources, evaluate them, deploy them, and review compliance for the entire control. Let’s take deployment. What if we have Windows, Linux, and Unix systems, and we need to assign patch deployments to people in each of those groups. We now have at least three (3) different Job Roles for one task (Patch Deployment).
How do we map that? We don’t, we map the people instead.
The best control framework will have its own, clearly defined, compliance roles. People will be assigned to those compliance roles just as people are assigned to job roles. People are the common denominator, not Job Roles or Compliance Roles. This approach avoids assigning multiple Job Roles to Compliance Roles and it addresses the issue where not all people in those Job Roles are responsible for the compliance tasks.
User experience keeps coming up, and it should. This is a critical part of the program and directly affects deployment.
Keeping that user experience simple and consistent is the key to successful controls program training. When UX is designed properly, the majority of the training needing to be done is the SAME FOR EVERYONE.
Instead of training people on each control, a properly designed controls framework will enable generic training on how the system works. This will apply to everyone and is the essential information they need to understand how to perform the work assigned to them.
The basic training is followed up by individual sessions on each control. Each control session includes all the people with a Compliance Role in that control. The training should walk through the Control, ideally mimicking a production scenario and should include concrete examples of compliance evidence.
Because even with the best controls, if you aren’t collecting the proper evidence then it’s going to be very hard to demonstrate compliance, which leads me to my next blog…
Have I piqued your interest? Then drop me a line or head over to the Contact Us page and fill out the form there. I would love to show you how we’re simplifying evidence management in our new controls-based model.
Enjoying my ongoing series “Unraveling the Mysteries and Complexities of NERC Compliance”? Subscribe to the Qualtrax blog to be notified when ‘Step Six – Demonstrating Compliance’ comes out.