Confluence policy template: build one your team will reuse

What a Confluence policy template gives you

Most teams write their first policies one at a time, each in whatever shape the author had in mind. By the fifth policy, one has an owner at the top, another buries it at the bottom, a third has no review date at all, and nobody can say which sections a policy is supposed to have. A Confluence policy template fixes that at the source: every new policy page starts with the same header fields, the same sections in the same order, and short instructions telling the author what belongs where.

That consistency pays off in three places. Authors write faster because they fill in a structure instead of inventing one. Reviewers and approvers know where to look for scope, exceptions and enforcement. And when an auditor or a customer's security team reads several of your policies, they see one program rather than a pile of documents.

A template is a starting point, though, not a control. It shapes pages at the moment they are created, and that is all it does.

Space templates vs global templates in Confluence Cloud

Confluence Cloud has two kinds of custom content template. Which one you want depends mostly on where your policies live.

If all your policies sit in one space (the easier setup to control and audit), a space template is enough, and it keeps the policy template out of everyone else's gallery. Choose a global template only if policies are genuinely written across many spaces, and accept that you then need a Confluence admin for every change to it.

How to create a template in Confluence for policies

The steps below are for a space template. A global template is built in the same editor; you just start from Confluence administration instead of the space settings.

1. Open the space's templates. As a space admin, open the space settings and go to Templates, then create a new template.
2. Name it plainly. "Policy" or "Policy page" is easier to find than something clever. Add a short description too, so people browsing templates know when to use it.
3. Build the header and sections. Lay out the structure described in the next section. Use a real heading for each section, not bold text, so every policy has the same outline.
4. Add variables for values the author must supply. In the current editor you type /variable and choose a type: Text (one line), Multi-line Text, or List (a drop-down with options you define). When someone creates a page from the template, Confluence asks them to fill in a form with these values and puts the answers into the page. A List variable works well for something like the review cadence.
5. Add placeholder text for instructions. Type /placeholder to add guidance such as "Describe who and what this policy covers". Placeholder text shows while the page is being edited and doesn't appear on the published page.
6. Add a label. Labels on a template are applied to every page created from it. A label such as policy gives you a reliable way to find and list every policy later.
7. Save, then promote it. Space admins can promote a template so it appears near the top of the template list in that space.

Two practical notes. Templates can't hold images or attachments, so link to a logo or diagram rather than embedding it. And if you want a "New policy" button on your policy index page, the Create from template macro adds a button linked to your template, which saves authors from hunting through the template browser.

A policy page structure that works for every policy

The same skeleton fits an access control policy, a backup policy and a code of conduct. Start with a short header, then seven sections.

The header

Put a small two-column table at the top with the facts a reader or auditor checks first:

• Policy owner: the person accountable for the content.
• Approver(s): who signs off each version.
• Effective date: when the current version took effect.
• Next review date: when it must be reviewed again, usually a year after the last approval.

If you plan to list all your policies in one table later, a two-column table inside a Content Properties macro (previously named Page Properties) lets a report macro on another page pull these fields from every page with your policy label.

The seven sections

Numbering the policy statements matters more than it looks. It lets a reviewer, an exception request or an audit finding point at "statement 4" without quoting a paragraph. For what to actually write in each section of your main policy, the information security policy outline walks through it section by section, and the SOC 2 policies list covers which policies you need in the first place.

Instructional text vs real content

The most common template mistake is example text that looks finished. If the template says "Access to production systems requires MFA" as a sample statement, sooner or later someone publishes a policy containing it without checking that it is true. A policy that describes controls you don't run is worse than a short one, because an auditor will test what it says.

Keep the two kinds of text clearly apart:

• Instructions go in placeholder text. They guide the author while editing and vanish from the published page, so they can't be mistaken for policy.
• Values the author must supply (company name, owner, cadence) go in variables, so the creation form asks for them up front.
• Sample statements, if you include any, should be obviously incomplete, for example "[System] access requires [control]", so nobody can publish them as written.
• A visible draft note at the top, such as an info panel saying the page must be tailored before approval, makes an unreviewed policy easy to spot. The author deletes it as the last step before submitting the page for approval.

Keeping all your policies consistent

The template gets new pages into shape. These habits keep the whole set in shape over time:

• One parent page. Create every policy under a single "Policies" page, so the page tree is the list of policies.
• One naming pattern. "Access Control Policy", "Backup Policy": same word order, no dates or version numbers in titles.
• The label on every page. The template adds it, but check pages created before the template existed and add it by hand.
• Plain section names. Don't let authors rename "Exceptions" to "Deviations" on one page. Consistent headings are what make the set readable as one program.
• Related Documents kept current. When a policy is renamed or retired, search for it in the other policies' Related Documents sections.

What a template can't do once pages exist

Here is the limit that catches people out: once a page has been created from a template, it isn't linked to that template any more. Editing the template changes what the next page starts with. Every policy page that already exists keeps whatever it was created with. You also can't apply a template to an existing page to restructure it; switching templates starts a new page, and the content you had doesn't carry over.

So if you add an eighth section, or rename a header field, you have to update the existing policies by hand, one page at a time. Keep a short note on the template page of what changed and when, and work through the list of policies until each one matches.

A template also does nothing after creation. It doesn't record who approved a version, doesn't notice when the next review date passes, and doesn't keep the header table true: if the owner leaves or the review is late, the header says otherwise until someone edits it. Those jobs belong to your approval and review process, which policy version control and approvals covers in detail.

Ready-made policy templates with Compliance in a Box

If you are writing policies for a SOC 2 report, Compliance in a Box can save you building the templates and the pages yourself. It is a Confluence Cloud app that turns one dedicated Confluence space into a SOC 2 compliance program, and it creates the policy pages for you from ready-made templates.

• Up to 24 policy pages. When a Compliance Admin generates the pages, the app creates one page per policy for the Trust Services Categories you chose: 20 policies for Security alone, 24 with all five categories, all under a single Policies page. The SOC 2 content reference lists every one.
• The seven sections, every time. Each policy has Purpose, Scope, Roles & Responsibilities, Policy Statements, Exceptions, Enforcement and Related Documents, followed by an effective date.
• Your details filled in on creation. The company name and security contact from the company profile in Settings (and the effective date, if you set one) are written into each page when it is created. Set them before you generate the pages: the app never rewrites a policy page afterwards, so later changes don't reach existing pages. See Fill in the company profile.
• A note to tailor before approval. Each policy opens with a short note that it was generated from a template and should be reviewed and tailored to your company before approval. You delete the note when you're done.

The header fields are handled differently too. Instead of a table in the page body that someone has to keep current, the owner, approved version and next review date are kept by the app and shown in the policy page's byline, and each approval is tied to an exact page version. On Confluence Standard and above, policy pages are locked so only the owner and Compliance Admins can edit them. The Policies and approvals chapter shows what the byline displays, and Confluence policy management covers the wider workflow.

FAQ

Who can create a template in Confluence?

Space admins can create and edit templates for the spaces they administer. Global templates, which are available in every space, can only be created and edited by Confluence admins.

Do changes to a Confluence template update existing pages?

No. A page created from a template isn't linked to it afterwards, so edits to the template only affect pages created from then on. Existing pages have to be updated by hand.

Should policy templates include sample policy text?

Only if it is obviously incomplete. Put guidance in placeholder text, which doesn't appear on the published page, and avoid finished-looking statements that could be published without being checked against what your company actually does.

Should I use a space template or a global template for policies?

If your policies live in one dedicated space, use a space template there. A global template only makes sense when teams write policies in many different spaces.

← All articles