Better security policies
Security policies are the backbone of information security programs. They define commitments to leadership and communicate objectives to staff. They’re valuable evidence of an effective risk mitigation program for auditors and potential customers.
If you look for examples of security policies on the internet, you’ll find Word files lacking interconnectivity and structural consistency. Useful information is buried in boilerplate. They don’t yield to automation for change management, assurance, and compliance operations. Their rigidity prevents effective integration into a modern security program.
We can redefine security policies to be more software-centric. Better security policies are parseable, linkable, metadata-enabled, and source-controlled.
Parseable
Security policies aren’t just documents — they’re data. Policies should separate content from presentation, and be structured to support programmatic access. This capability is crucial for using policy data in automation.
Markdown’s simplicity and readability make it an excellent choice for writing documents that need to be both human-readable and machine-parseable. For example, Tailscale’s security-policies can be viewed in Github or locally with a Markdown reader like Obsidian. Because they are parseable, these policies can be programmatically combined by a GitHub Action to a single PDF — which may be useful when providing evidence, for example during a SOC 2 audit.
Significantly, a parseable policy structure should give each policy statement (e.g. 7.2 Use phishing-proof MFA for corporate systems) a heading/anchor which makes these statements linkable.
Linkable
An isolated information security policy lacks context. It must be carried around in someone’s brain to be considered in other, useful contexts. If policies can be interlinked with related documentation, they become more powerful — think Wikipedia.
If a policy statement can be directly linked (e.g. Tailscale’s MFA policy), it can be represented as a “node” in a semantic web style graph. This is an important capability for automating compliance efforts, as policies can be linked to compliance objectives as well as their underlying security controls.
As an example, I forked Tailscale’s policies and annotated them with links to relevant SOC 2 objectives. I did the analysis using a script that sent the policy body to an LLM-based backend. This takes advantage of my graphgrc open-source project, which applies the concepts here (parseable, linkable, etc.) to compliance frameworks.
Metadata-enabled
Some inherent data about a security policy should be captured as metadata:
- Owner — who is responsible for this policy?
- Audience — who does this policy apply to?
- Version — what version of the policy is this?
- Review — who reviewed this policy? When was it last reviewed?
It’s not just enough to have this data for each policy — the metadata should be accessible programmatically. For instance, Markdown-based policies can specify metadata using YAML frontmatter. Policy metadata can enable valuable automated use cases:
- Enforce documentation standards to prevent invalid metadata, broken links, typos, etc
- Keep track of when your policies were last reviewed, and validate that none of them go out of date
- Track required policy acknowledgment as part of ongoing security training
Source-controlled
Documentation gets stale. Contributors come and go, and information becomes out-of-date. Source control is the best way to reverse this entropy. One reason is that it’s clear how to ask for feedback on changes, using pull requests. You can see who made a change, and when. Understanding the context of a change can help make future changes easier, and prevent security policy drift and bloat.
There’s a tremendous opportunity to improve security by bringing engineering to GRC. Better security policies are a great starting point for organizations designing a scalable security program that treats GRC as a first-class objective. Are you working to make security policies better? Let me know on LinkedIn or Mastodon.
