Raise your hand if people tell you what to do. Keep it up if they also try to tell you how to do it. Is it ever challenging to extract the details that would make it easier for you to offer and defend different compliance options?
Here’s an easy-to-remember method you can use to guide a compliance negotiation to the conclusion that maybe you should be the one to decide how to comply. It’s based on the WHO-WHAT-WHEN-WHERE-WHY model we’re all familiar with.
In this technique, we start with the word WHY. When you’re told you need to do something, ask for the underlying objective. For instance, let’s assume you’ve been told to implement a specific control. Why? You’re told it’s to ensure that confidential customer data will adhere to privacy rules.
Great. That’s a clear objective, assuming you have access to those rules. Your next question is WHO this applies to—who must implement the recommended control. But don’t stop with a simple question. Pick two sets of criteria and two options for each criteria. Arrange them in a grid, and use that grid to determine whether the situation includes one, two, three, or four sets of circumstances.
The following is an example of a WHO grid.
Your goal is to know whether this specific suggestion or requirement applies to groups other than yours, and whether it’s an IT-focused activity or something that also applies to business users. This is important to know because it tells you whether there’s the possibility of flexibility; for example, will other groups satisfy compliance in a manner different from you? Next, ask WHAT the requirement applies to (see below).
Will this activity take place infrequently during planning and alignment, or is it a recurring operational activity? If the scope is both formal and informal activities, can a single option actually satisfy every requirement?
Next, ask WHERE the activity must be performed (see above). Is this control applied only to the mainframe, or also within other systems? Is it applied at a field-level, at the repository-level, or something in between? At this point, you’re going to have some insight that your order-giver might not have. You know that applying controls to individual fields often requires a different approach than implementation at higher-granularity levels.
Finally, ask WHEN the activity should take place (see above). Is it one time, ongoing, or both? Will it be part of planned processes, ad hoc activities, or both?
By now, you should have the WHO-WHAT-WHEN-WHERE-WHY information you need to understand your stakeholders’ actual needs. You’re in a better position to suggest a HOW that will meet those needs and satisfy your own, as well.