How To Tailor Key Risk Indicators (KRIs) To Your Organization’s Specific Threats
Every organization faces risk each day, but no two organization’s risk landscapes look exactly the same. It’s the…
“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.
A policy should consist of six (sometimes seven) key aspects:
We’ll reference these policy aspects in the three principles we’ll cover in the following sections.
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.
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:
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!
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:
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.
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.
Every organization faces risk each day, but no two organization’s risk landscapes look exactly the same. It’s the…
Maybe your organization has been the victim of a supply chain attack, or saw one of your major…
Many cybersecurity professionals, if not all, have experienced that “after the breach” feeling — the moment you realize…
Join us as we celebrate Women’s History Month with five women working at the pinnacle of the risk…
Anticipate risk events, make better risk decisions faster, and provide context for your decisions to key stakeholders with…