Who Are Security Policies For? (A Primer On Writing Policy For People)

Last verified Nov 18, 2021

As the Risk and Compliance Manager for Guru, I spend a good bit of my time using the Guru app to create and organize the policies that govern our company's security practices.  You know...dotting I’s...crossing T’s...updating words and such.  In the security world, it’s the thing to do, right?  Policy is an essential part of just about any compliance program.  Without rules, we’re all just a bunch of kids running recklessly around the proverbial pool.   

Recently, I had to rethink my well-ordered routine as a compliance manager and consider the bigger picture. A co-worker of mine suspected he might not be fully following a particular security practice, so he reached out to say he couldn’t find the policy on vendor management. 


I was taken somewhat aback, as I had gone to great lengths to write a perfectly serviceable policy on “supplier relationships” and post it in Guru for all to read.  I mean, come on, what’s not to get, right?  Vendor?  Supplier?  Relationships? And, well, uh...      

Okay, point taken.  In fact, his question was something of a wake-up call for the ivory-towered compliance guy who feels that we have clear and compelling policies for all to read.  In this existential moment, I reflected on the fact that my online library is full of jargon-tinged language.

If people can’t relate to the words, how can they be guided by them?

This got me thinking about better ways to organize policy within Guru. We need a compliance program that not only meets the formality required by auditors, clients, and partners but actually serves the people to whom it applies.  It prompted me to embark on a slow campaign of adding relevance to policy, an undertaking that rests on three improvements: tagging, linking, and simplifying policy with plain language.             

The lost art of tagging

The process of creating a Guru card is pretty simple, but there’s a little left-brain consideration that goes into organizing that card and setting it up for discovery--which collection, which board, etc.  As the policy creator, I’m somewhat at an advantage in that my cards are hierarchical and organized in a self-evident way.  But that’s also a recipe for isolation, a stovepipe if you will, that exists for its own sake and not for dissemination among the readers.

I put myself in the cyber shoes of anyone who might be curious about their security responsibilities, assuming their Guru search would likely include “security policy.”  Eyeballing one of my policies at random, I quickly discovered I hadn’t even added this simple phrase as a tag; hence, a search would return anything from “vacation policy” to the engineering group’s “content security policy.”  I added the words as a tag, and, like magic, my policies rose to the top of the search results.  Thanks, tags! 


Guru is full of anything and everything a person needs to do their job.  I sometimes find myself browsing other collections only to trip over cards that look and smell like security policy, and my parochial inner self frets over the fact that it’s not organized in my security collection. 

I’ve come to realize that in the compliance world, rules are a great thing no matter where they live.  The onus is on me to make them relevant to policy and link them to keywords in “my” cards.  

For example, if there’s guidance from the IT Manager about how to update one’s operating system on their Guru-issued laptop, I should tie it back to my “workstation policy” through a simple hyperlink.  This step aligns everyone’s contribution and makes policy more inclusive, aligning the planets, as it were, to reveal a common security solar system.  

Plain Language

You didn’t hear this from me, but policy people tend to overcomplicate language when they can. Take this little snippet from an industry compliance requirement that shall remain nameless:  “The information security program, in relation to protecting personal information, should include communications management and operations management.”


Yikes.  That may mean something to the author and a few security purists charged with enforcing it, but the layperson could be left scratching their head.  Communications management?  Operations management?  Could it be that maybe, just maybe, that same mandate could be simmered down into something simpler, like, “We will secure personal data by implementing procedures we must all follow?”  

There.  We just ratcheted down the rhetoric and didn’t lose anything in the process.  Believe it or not, less can actually mean more in a compliance program where people just want to know what it is they’re supposed to do.  Compliance types like me should avoid the temptation to parrot regulation and package it up in cards.  If we don’t get it ourselves, how can we expect others to carry it out?  

The Work Never Stops  

Tagging, linking, and simplifying security policy aren’t things to be done once and forgotten.  This is a journey, an ongoing investment of time and thought for the compliance manager.  With a little critical thinking, policy authors can leverage Guru to house enforceable policy that not only satisfies regulators and customers but speaks to the people who matter most: those who must execute it.