Most Confluence spaces start open: everyone in the space can read and edit everything. That works until a page needs to be different. A policy only its owner should change, an HR page only a few people should see, a document that isn't ready to share. Confluence page restrictions handle all three, as long as you understand their rules and check on them now and then.
What Confluence page restrictions are
Confluence Cloud has three layers of access. Global permissions decide who can use the site at all. Space permissions (or space roles, on sites that use them) decide what someone can do in a space. Confluence page restrictions sit at the bottom and apply to a single page.
The most important rule: a restriction can only narrow access, never widen it. Space permissions set the ceiling. If someone's space role doesn't let them edit, adding them to a page's edit list doesn't change that. If they can't view the space, a page restriction won't let them in. Restrictions are a way of saying "fewer people than the space allows", not "these extra people".
Restrictions need a paid plan. On Confluence Free you can't restrict content, so anyone who can edit the space can edit every page in it. Standard, Premium and Enterprise all support them.
Space permissions themselves are a bigger topic: who gets which role, groups versus individuals, and how to set up a space before you start restricting pages inside it. This article stays at the page level.
View restrictions vs edit restrictions
A page can be restricted in two ways. An edit restriction leaves the page readable by everyone who can view the space, but only the people and groups you list can change it. A view restriction hides the page from everyone except the people and groups you list, and you choose whether each of them can view or also edit.
At the time of writing, Confluence Cloud manages this from a page's Share dialog, under General access, which has three settings:
| General access | Who can view | Who can edit | Typical use |
|---|---|---|---|
| Open: anyone can edit | Everyone the space allows | Everyone the space allows | Most pages (the default) |
| Open: anyone can view | Everyone the space allows | Only the people and groups listed | Policies, procedures, anything with an owner |
| Restricted: only specific people | Only the people and groups listed | Listed people given edit access | HR, legal, security details, unfinished work |
You can list both individuals and groups. Prefer groups wherever you can: when someone joins or leaves a team, you update the group once instead of hunting through every page that names them.
People who hit a restriction can ask for access from the page. Anyone who can edit the page and manage restrictions in the space can approve or deny the request. That is convenient, and it is also one of the ways restrictions quietly widen over time (more on that below).
How restrictions affect child pages
This is where most surprises come from, because the two kinds of restriction behave differently.
- View restrictions are inherited. If someone can't view a parent page, they can't view anything nested under it. Restrict "HR" to the people team and every page beneath it is hidden from everyone else, including pages added later.
- Edit restrictions are not inherited. Restricting editing on a parent page does nothing to its children. A child page under an edit-restricted "Policies" page is still editable by anyone the space allows, unless you restrict that child page too.
A child page can also carry its own restrictions on top of what it inherits. Someone then needs to pass both: they must be able to view the parent and be on the child's list.
Important: If you want a whole section of pages locked against editing, restricting the parent is not enough. Each page needs its own edit restriction. This is the most common gap in a "locked" policy area.
Who can restrict a page
Whether someone can add or change restrictions is controlled by a space permission. Atlassian calls it the restrict content permission; on sites that use space roles it appears as the permission to manage access to individual content. Of the default space roles, Admin and Manager include it, while Collaborator and Viewer don't. Your site may have custom roles, so check what yours grant.
Two details catch admins out:
- Space admins aren't automatically exempt. If a page is view-restricted and a space admin isn't on the list, they can't open it. They can, however, see a list of restricted content in the space and remove restrictions.
- Organization admins on Premium and Enterprise can use admin key to temporarily bypass restrictions on a page. Its use is recorded in the audit log and the page's owner is notified, so it is a recovery tool rather than a way around the rules.
Common setups
Lock a policy to its owner
To restrict editing in Confluence for a policy, set General access to "Open: anyone can view" and give edit access to the policy's owner plus a small group of program admins. Everyone else keeps reading it. Because edit restrictions don't inherit, repeat this on every policy page. Confluence policy management covers what else a policy page needs beyond the lock.
Hide a page that isn't ready
For a draft policy or a restructuring proposal that should stay private for now, set "Restricted: only specific people" and list the authors and reviewers. Remember to open it up when it is ready, and check that any child pages you created under it are meant to become visible too.
Restrict an HR or legal section
Create one parent page (for example "People team"), view-restrict it to a group, and put sensitive pages under it. Inheritance does the rest. If some pages under it also need tighter editing, add edit restrictions to those pages individually.
Protect evidence and reports
Compliance evidence can include names, access lists and screenshots of admin consoles. View-restrict those pages to the people who run the program and, during an audit, the auditors. The user access review is a typical example: its evidence lists who has access to what.
How Confluence page restrictions drift
A restriction is set once by a person and then left alone. Over months, the page's real access moves away from what anyone intended:
- People add themselves. Someone with the right space permission adds their own name to fix a typo, or an access request is approved without much thought. They are still on the list a year later.
- Owners change. The policy owner moves teams or leaves. The restriction still names them, and the new owner can't edit the page until someone notices.
- Restrictions get removed. Someone opens a page up to collaborate on a rewrite and never restricts it again.
- New pages miss the lock. A child page is added under a locked section. Because edit restrictions don't inherit, it is open.
- Individuals instead of groups. Pages that name people rather than groups go stale every time the team changes.
None of this is visible from the page itself unless you open the Share dialog. For a compliance program, drift matters: if your access control policy says only the owner can change policies, an auditor may ask how you know that is still true.
How to audit page restrictions
A short review once a quarter catches most drift. Here is a workable routine:
- List the restricted pages. In the space settings, under Content, the Restricted view lists the restricted content in the space.
- Check each one against its intended owner. Keep a simple table of which pages should be restricted and to whom. Compare it with the list and note every extra name, missing name and unrestricted page that should be locked.
- Check the pages that should be restricted but aren't. The restricted list won't show what's missing. Walk your policy and evidence sections and confirm each page is locked.
- Read the audit log. On paid plans, Confluence admins can see an audit log that records content restrictions added or removed, filter it by keyword and date, and export it to CSV. Entries are kept for a limited period (up to a year, depending on your settings), so export what you need for an audit period.
- Fix and record. Remove extra names, replace individuals with groups, re-add missing restrictions, and note what you changed and when.
Tip: When you change a policy's owner, change the page restriction in the same sitting. Treat the two as one task, or put "update the page lock" on your owner-change checklist.
Locking compliance pages with Compliance in a Box
Compliance in a Box is a Confluence Cloud app that runs a SOC 2 program in a dedicated compliance space. Locking is built in, and the app keeps the locks in step with who owns what, so you don't have to audit them by hand.
- Every managed page is locked. Each policy page, activity page and evidence page carries an edit restriction for its owner, the Compliance Admins group and the app. Section pages, the controls matrix and the report pages are locked to the Compliance Admins group and the app. Everyone else who can see the space can read the pages but not change them. See Who can edit a policy.
- The lock follows the owner. When a Compliance Admin changes an owner in Settings, Owners & approvers, the page lock and the owner's access to the space move to the new owner in the background. For an activity, that includes its evidence pages.
- Drift is repaired daily. If someone removes a page's lock or adds an extra editor to it, the app's daily check restores the lock to the owner, the Compliance Admins group and the app, and records the change in the audit log. A Compliance Admin can also click Re-apply permissions in Settings to repair straight away. See How the app keeps permissions in step.
- Reports are view-restricted. The report pages and the controls matrix can be viewed only by the Compliance Admins group, an optional Auditors group and the app. View restrictions you add yourself to policy, activity or evidence pages are left alone.
- Edits still go through approval. Because only the owner and admins can edit a policy, and every approval is tied to an exact page version, the approved text can only change through a new version that someone has to approve again.
Page locking needs Confluence Standard or above. On Confluence Free the app still works, and Settings warns that pages can't be locked. For the wider setup, see how to run a SOC 2 compliance program in Confluence.
FAQ
Can a page restriction give someone more access than the space allows?
No. Restrictions only narrow access. Someone whose space permissions don't allow editing can't edit a page, even if they are listed on its edit restriction.
Do child pages inherit Confluence page restrictions?
View restrictions are inherited: if someone can't view a parent page, they can't view the pages under it. Edit restrictions are not inherited, so each page you want locked against editing needs its own restriction.
How do I lock a Confluence page so only I can edit it?
Open the page's Share dialog, set General access to "Open: anyone can view", and make sure you (and ideally a backup group) have edit access. Everyone else can still read it. You need a paid plan and the space permission to restrict content.
Can I use page restrictions on Confluence Free?
No. Confluence Free doesn't support restricting content, so every page is open to everyone the space allows. Restrictions are available on Standard, Premium and Enterprise.