Security Policies: When Did We Decide They Had to Be Boring and Written by Lawyers?

Let's talk about something that's surprisingly overlooked in security: how we write our policies. While my previous article focused on keeping things simple, this one dives into the science and art of making policies both professional and readable.

While researching this I came to a shocking conclusion: Nobody else seems to focus on this (except a few. You know who you are!).

The Power of Inclusive Language in Security

Security policies have a reputation for being dry and disconnected from reality. There's a reason for that. That's often because we write them in a way that makes security feel like something that happens TO people rather than WITH them.

Look at these two approaches:

The System Administrator shall enforce password requirements for all users.

or

We protect our systems by using strong passwords.

Notice the difference? Same message, but one treats people like participants in security rather than subjects of it. That matters. Read on and you'll understand why. I promise!

Getting Your LIX Score Right

Assuming we're all familiar with LIX as a readability measure (if not, ask Wikipedia), let's focus on something more interesting: how dramatically different the same security incident policy can be at various LIX levels. Here's what I mean:

Complex Version (LIX: 55)

In the event of any security breach, the Data Protection Team must be contacted immediately. The Team will make the necessary decisions to ensure the proper handling of the security breach and the management team must be kept up to date throughout. The IT department identifies, assesses and documents risks based on inputs from the organisation, external audits and other external factors. The IT department manages all risks in a manner that ensures that the cause of the risks is exposed and eliminated or, at least, reduced to an acceptable level.

I don't know about you but I almost get dizzy just by reading it. And I'm a trained security professional. Just imagine what an ordinary employee at the office or at your production line thinks when they read this. Oh. My. God.

How about this instead?

Professional But Accessible (LIX: 38)

Security Breach Protocol:

1. Contact Data Protection Team immediately
2. Team handles the incident
3. Management stays informed
4. IT assesses and documents risks
5. Problems get fixed or contained

A lot better. And formatting the policy as a list make sentences short and easy to read with a great overview.

Simplified Version (LIX: 42)

Report all security breaches to our Data Protection Team right away. They will handle the breach and keep management informed. IT will assess the risks, find their cause, and work to fix them or reduce their impact.

See what I did there? I used the word 'our'. That's inclusive. It's not THE Data Protection Team. No, it's OUR Data Protection Team. We're in on this security thing together. Also, I used full sentences. That makes it easier to write inclusive and engaging and not just listing things. If that's all you do in a policy it can seem a bit monotonous and discouraging to users.

Too Basic (LIX: 25)

Tell our Data Team right away if something goes wrong. They will:

• Handle the problem
• Tell managers
• Find the cause
• Fix it

The thing with LIX scores is that when they get too low, the language seems to basic and somehow childish. To me this language is too simple.

That being said, it might work on a poster where you want to explain what someone should do using as few words as possible. But that's a rabbit hole to jump into another day.

Finding Your Audience's Level

Companies and cultures differ. One tone of language works in one company and not in another. And different teams need different approaches to ensure they are comfortable with the language and don't feel they are being patronized. Here's what I've found works:

• Technical teams: 40-50 LIX
• General office staff: 35-45 LIX
• Public-facing documentation: 30-40 LIX

The trick isn't hitting exact numbers - it's about finding what resonates with your specific audience while maintaining professional standards.

Let's Look at Another Example: Access Control

Now let's talk about Access Control policies. Here's how another example could look.

Complex Version (LIX: 54)

Access to organizational systems and data shall be governed by role-based access control mechanisms wherein personnel are granted minimum necessary privileges required for their designated functions. Authentication shall be validated through multi-factor verification protocols prior to system access being granted.

Wow. Dizzy again!

Let's try something else.

Well-Balanced (LIX: 40)

System Access Requirements:

1. Use your designated login credentials
2. Complete two-factor authentication
3. Access only systems needed for your role
4. Report any access issues to your friends in IT Security

Regular access reviews ensure appropriate system permissions.

Here it's a list and since there're many excuses to use inclusive language (which I've taken), it seems way more manageable than the list from the previous example. I even managed to hint that the colleagues in IT security are friendly and helpful. Oh, such joy!

Too Basic (LIX: 25)

To use our systems:

1. Log in with your password

2. Use your phone to verify

3. Only look at what you need

4. Tell IT if something's wrong

Here, on the other hand, language is getting too basic. It would work great on a poster though.

Making It Work in practice

Creating effective security policies requires balancing multiple factors:

Organizational Culture

• What's your company's communication style?
• How technical is your workforce?
• What's worked (and failed) in the past?

Technical Requirements

• Mandatory terminology
• Compliance language
• Industry standards

Practical Considerations

• Multiple language versions?
• Different audience needs?
• Update frequency?

The Reality Check

Here's something many security professionals (or lawyers, for that matter) don't want to admit: The most technically precise policy isn't always the most effective one. What matters is creating policies that people can understand, remember, and actually follow.

Think about it - what's better?

• A perfectly detailed policy that sits unread in a drawer

or

• A well-balanced policy that people actually use

I'm a very practical guy so I'm definitely a fan of the latter.

Moving Forward: Try it out yourself!

The future of security documentation lies in finding that sweet spot between technical accuracy and human readability. It's about respecting both the complexity of security and the intelligence of your readers.

A few key points to remember:

1. Match your LIX score to your audience
2. Use inclusive language that engages rather than dictates
3. Keep technical precision while maintaining clarity
4. Test with real users before implementing

Security policies don't have to be a choice between being technically precise and being understandable. They can be both. It just takes more effort to write them that way. But in my mind there’s no doubt that it’s a good investment.

And remember: Please reach out if you struggle with this or anything else in relation to making security understandable. This is what I do (among other things, of course).