Skip to main content

Policies and Procedures

A policy says what your organization requires; a procedure says how you carry it out. Together they're the documents an auditor reads first.

Almost every framework asks for the same thing: written policies, approved by someone accountable, reviewed on a schedule, and actually available to your people. Keeping them in Openlane means the document, the controls it maps to, and the revision history live in one place: no hunting for final_v3.docx across shared drives mid-audit.

Policies also do real work outside the audit: they tell employees exactly what's expected and who to report to when something goes wrong. A policy nobody can find, or nobody reads, fails both jobs.

Policies vs. Procedures​

A policy sets the requirement ("production access requires multi-factor authentication (MFA) and quarterly review"); a procedure describes the steps to meet it (how to request access, who approves it, how the review runs). Openlane stores them as separate document types, but you work with them the same way: same editor, same import options.

How Many Policies Do You Need​

You likely need fewer than you think. A handful of well-scoped documents (information security, acceptable use, access management, incident response, business continuity, change management, data classification and retention, vendor management) covers most frameworks; the policies to framework mapping shows exactly which policies each framework expects. Your industry and jurisdiction may require more (privacy, health and safety, anti-bribery); verify with legal counsel rather than a template list. For what the continuity documents should actually contain, see the best-practices guides on business continuity and disaster recovery.

When deciding whether to consolidate or split:

  • One policy can map to multiple controls. Evidence may differ per control even when the policy is consolidated, so grouping costs you nothing at audit time.
  • Group until the concepts truly diverge. If the audiences or use cases are different, split: an IT security policy can cover a wide range of general user guidance, but infrastructure change management usually belongs on its own.
  • Favor fewer, clearer documents. Policies only work when people read and follow them, and a smaller set is easier to keep consistent and current.

Writing Policies That Hold Up​

A section skeleton that works for nearly every policy: Purpose, Scope, Roles and Responsibilities, Policy, Enforcement, Definitions. Auditors know this structure, and it forces you to answer the questions they'll ask anyway: who does this apply to, who owns it, what happens when it's violated.

Two habits that pay off:

  • Be vague about individual systems, but specific about scope and cadence. "Access reviews run quarterly across all production systems" survives a tooling migration; naming the specific tool means a policy update every time you switch vendors.
  • Keep a modification history table at the top: dates, edits, approvals. Openlane keeps revisions of your documents on your behalf, but an in-document history is standard industry practice and lets the reader understand the document's history without walking every revision.

The editor supports most native markdown (type ## for a heading), and cmd+shift+v pastes with formatting intact.

Getting Existing Policies In​

If you already have policies written, there's no need to retype them. You can bulk-import markdown, Word, or text files from the console, or set up a continuous sync from a GitHub repository so the repo stays your source of truth. The import guide covers both.

Keeping Policies Current​

The lifecycle is straightforward: draft with input from the stakeholders the policy binds, get approval from someone with authority to enforce it, publish it where employees will see it, make sure staff read and acknowledge it, then review on a schedule; annually or semi-annually is typical. Enforce with technology where you can, and retire policies that no longer apply: a stale policy that contradicts current practice is worse in an audit than no policy at all.

FAQ​

Do I need a separate policy for every control?

No, one policy typically satisfies many controls. Map the policy to each control it supports and collect control-specific evidence separately.

Who should approve policies?

Someone with the authority to enforce them: typically an executive or department head, not just the person who drafted them. Record the approval in the modification history.

How often should policies be reviewed?

Annually is the common baseline, plus whenever something material changes: a new system, a reorganization, a new regulation.

What format should policies be in?

Markdown works best in Openlane, but you can import Word and text files too. If your policies live in Git, the GitHub sync keeps them updated automatically.