Risk and Compliance Management: Differences, Similarities, and How to Integrate Them
We often hear risk and compliance management bundled together as a single discipline. While it’s true that risk…
“Did I forget to update that document?” - A compliance practitioner’s recurring nightmare.
As the year kicks off in earnest, a good portion of Information Security, Legal, and HR teams are taking a moment to take a deep breath and be happy that year-end close has wrapped, budgets have been approved (maybe not to your complete satisfaction), auditor requests have been closed, and policies have been reviewed and reshared with the organization.
As a member of one team in that exact situation, I recognize that discussing policies might be the last thing you want to do in a new fiscal quarter. However, if you’ll indulge me, I’d love to take the opportunity in this two-part blog series to spend some time talking about methods we’ve used here at LogicGate to make that process less painful and more insightful to those involved in policy management.
This first blog post will explore the principles of policy management, and part two will focus on how to operationalize those principles to make the policy management process more efficient.
Fundamentals of a Policy Management
A policy should consist of six (sometimes seven) key aspects:
- Owner: The individual responsible for enforcing the policy and keeping the policy updated.
- Review Details: When the policy was last updated and by whom (and hopefully, some versioning information).
- Scope: Who or what the policy covers.
- Roles & Responsibilities: Identifying who is responsible for doing each task.
- Obligations: What specifically someone SHALL do and how often they SHALL do it.
- Compliance: What happens if someone fails to meet those obligations.
- References (Optional): Where to go if you have more questions about how to do something in the policy.
We’ll reference these policy aspects in the three principles we’ll cover in the following sections.
Principle 1: Roles & Responsibilities are Keys to Success
In a prior role, I was working with a company to get policies aligned to an annual review cadence. They had last been updated three years ago. Unfortunately, we didn’t set ourselves up for success, and what was supposed to be three months of work ended up extending to 15 months to get the policies where they needed to be. Why did they take more than a year? The policies spent 60% of the time in stakeholder review, sitting in an inbox not being touched and 30% of the time in legal review, being picked apart. To put it lightly, not enjoyable for any party involved.
While most teams I’ve worked with spend the majority of time on those SHALL statements, I’d argue that you are already setting yourself up for failure on your policies if that’s your focus on day one. This is due to one important fact—no one at your company besides Legal is really reading your policies.
It’s a tough pill to swallow, I know. I’ve spent too much time writing policies and getting them approved. The reality in practice is, policy obligations are there not as much to define what you do but to prove in the future that people are doing their jobs.
What can we in the GRC space do with this information? Sell the heck out of the Roles & Responsibilities section. Trust me, a table with your title and a superb summary of what an IT Director is in charge of will be read and will set the tone on whether the person is going to glance at the rest and give a thumbs up, or ignore the email and require hounding.
This first principle is to not only ensure your obligations are accurate but that you spend more time than you think is necessary making sure that those R&R’s look and sound amazing. You win or lose your policy review battle within thirty seconds of that person opening your document.
Principle 2: Depth Not Breadth
A few years ago, I was working with a company with 50+ policies—just around Information Security and supporting areas. There was a policy for anything and everything. I hate to say it, but despite being responsible for aspects of a large number of those policies, I never read them. I never referenced them to teams. Not once. There was not enough context and they were too minute in their detail to be useful in my role in selling WHY we were doing something.
The most effective obligation management structure I’ve worked in was:
- Umbrella policy: We have a jumping policy that documents our jumping obligations
- Nested policy referenced in the top-level policy: All employees shall jump directly up to the required height captured in Standard
- Standard referenced in the nested policy: The correct height to jump vertically
The reason for this structure is that Microsoft, Google, Atlassian, etc. have made it extremely easy to reference various documents and update wording across documents. By leveraging this nested structure, your policies rarely change, but when they do, you don’t need to re-architect them again.
An added bonus of this structure is that each nested policy, standard, etc. can be owned by someone closer and closer to the actual do-er’s and not require the same overhead to change because the impacts are minimalized.
We’ll also spend more time in part two of this series on other reasons this structure is advantageous!
Principle 3: Construct Your Obligations to Help Future You
Very early in my policy writing life, I had senior leadership spend weeks and many review cycles on policy statement writing guidance (basically changing SHALLs to MUSTs). We were then told to realign all policies to this guidance and push them through the process. The net result produced zero meaningful changes for end-users but several weeks of review cycles with stakeholders and Legal.
Please stop using SHALL statements and other legalistic stylings in your policies—the future you will thank you.
Why? By making a policy obligation a SHALL statement, you are raising the table stakes of the policy and reducing its approachability—and by extension, decreases the likelihood of compliance with the policy. We already have hit on it, but no one is going to read your policy or the perfect shall statement within it. By making the language less approachable, you will run into one of two situations when you actually need your policy in two years:
- You will need to wave the policy to get someone to do something they don’t want to do
- You will need to haggle over what you really meant when you wrote that obligation
In either scenario, the best situation for you as the enforcer of a policy is to have the most clear-cut and direct statements.
Think less “End-user MUST sign policies annually” and more “End-Users sign policies annually.”
While policies are almost a version of a contract, using legal language in them will end up having people treat them as legal language and start playing “armchair lawyer” to prove themselves right in the “court of not wanting to do something.”
So help future you, get rid of those SHALL statements and all those perfected pieces of language and make direct actionable statements for your future self’s benefit.
Closing Thoughts
These are just a few principles that you can leverage to start to make your policy management process a bit more efficient and effective. Even if you don’t leverage these principles, stay motivated and take solace in those policy reviews with the words of former Deputy Attorney General Paul McNulty:
'If you think compliance is expensive—try non-compliance.”
If you are on the fence about these principles, we’ll have a second blog in this series where we’ll spend more time talking through the application of these principles and how to leverage them operationally to your future self’s benefit.
About Heath Anderson (He/Him)
As the Director of Information Security & Technology at LogicGate, Heath enjoys the opportunity to take on the challenge of building a thoughtful and proactive security and data-driven culture at a scaling tech company and learn from customers and their approaches to GRC. In past lives, Heath spent time consulting, deploying, and operating InfoSec programs for various Fortune 1000 companies as well as working in the Air Force to design, test, and integrate security into awesome new software for our growing Space effort.
