Most security policies are terrible

Why, and how to make yours better.

After evaluating hundreds of security policies across all different types of organizations here are the top 3 mistakes I see:

1. Stale and static

PDF-formatted policies kept on-the-shelf in a share drive are often just compliance “check the box” artifacts to satisfy auditors.

No one reads or uses them during day-to-day operations.

Build them in:

• Notion

• Confluence

• Google Docs

• A structured database (more on that)

to make sure they don't go out of date quickly. This also provides built-in version control and auditing capabilities.

2. No accountability

Common requirements in security policies include:

• “Vulnerabilities should be patched.”

• “Devices shall be inventoried”

• “Incidents shall be reported.”

Who is accountable for making sure these things happen?

It’s rarely clear.

And if your policy uses the passive voice, it’s likely falling short here.

3. Unclear or no references

Similarly, policies often have parts stating:

• “Data owners are responsible for authorizing release of information.”

  • Where can I look up the data owners? Who owns which info?

• “The risk committee shall approve exceptions to policy.”

  • Who is on the risk committee? How long do they have?

• “Management is responsible for authorizing vendors.”

  • Ok...which person actually needs to sign off?

Embracing policy as (no-)code

The answer to all of this madness?

Write your policies as (no-)code.

It gets rid of many of the problems I mentioned because:

• It’s much easier to update a centralized repository of policies than reverse-engineering a .pdf that no one can find the original word document version for.

• Lack of accountability becomes clearer. If you have a risk_review function that never gets called…you will never have a risk review.

• Unclear references to policies that don’t exist will throw logical or actual errors.

Now, doing all of this can require massive organizational effort. But with new technologies, especially AI-powered ones, proliferating rapidly, you need to keep up.

The good news: StackAware is solving this exact problem.

Our AI governance clients get a custom-built set of policies and procedures that match their business needs and are available in a machine-readable format.

The backend that builds them, though, is StackAware’s policy-as-no-code solution. Check out this video for a demo:

Ready to talk?

---

Appendix: Frequently asked questions

In the LinkedIn post that inspired this expanded article, I got a fair number of comments and questions which I wanted to address here.

Question: aren’t security policies meant to be high-level and not get into the details?

Yes, but there is a major difference between high-level and vague.

• High-level: the Chief Information Security officer shall make risk management recommendations to the business unit General Manager within 5 days of identification.

• Vague: business leaders should seek input from the security team about risks.

The first one is clear and you can build an actionable procedure from it.

The second one is a muddled mess (but quite common).

Question: aren’t policies difficult to change by design?

I don’t think so, at least in most cases. And if they are, this isn’t a great idea considering how fast the technological and business landscape changes.

Policies are difficult to change because there is rarely any sort of procedure (or policy!) developed internally that spells out exactly how to make updates to them. As a result, attempts to change the policy turn into bureaucratic slog whereby whoever champions an update needs to address every single holdout or objection.

A better way to do it is to have a clear method for changing policies, as well as a single accountable decision-maker (CEO or COO are probably most appropriate).