How Confluence space permissions work today
Confluence space permissions decide who can see a space and what they can do in it. They sit between global permissions, which Confluence admins set for the whole site, and page restrictions, which narrow access on individual pages. For a sensitive space, the space layer does most of the work, so it is worth getting right.
Confluence Cloud now manages space access with roles. Instead of ticking individual permissions for each person or group, you give them a role, and each role maps to a fixed set of permissions. There are four default roles:
| Role | What it allows | Typical holder in a sensitive space |
|---|---|---|
| Admin | Everything in the space, including its settings and who has access | A small admin group |
| Manager | Managing people and content, but not the space settings | Rarely needed; treat it like admin, because it can manage people |
| Collaborator | Adding and editing content | The people who write and maintain pages |
| Viewer | Viewing and commenting | Everyone who needs to read the content |
Confluence admins can also define a few custom roles, which space admins can then assign. Use them sparingly: every extra role is something to explain and review later.
Role-based access is the default for new Confluence sites, and older sites have been moving over in stages. During the transition, access that doesn't match a role yet is kept as what Confluence calls custom access. If your space settings still show a grid of permission checkboxes, your site hasn't switched yet. The principles below apply either way.
One rule shapes everything else: permissions are additive. If someone has access through two routes, for example their own entry and a group, they get the sum of both. You can't reduce a person's access by giving them a lower individual role while their group holds a higher one. To take access away, you remove it at the source that grants it.
Who gets into a new space by default
When someone creates a space, Confluence offers the site's default access configuration as the starting point. A Confluence admin sets it in the product settings, under the space permissions defaults, and it can include groups and user classes with a role each. It is a recommendation, not a limit: the creator can choose different access, and space admins can change it at any time afterwards. The default configuration also controls whether public links are allowed in new spaces, and Atlassian ships new sites with that switched on.
For a sensitive space, the defaults are the first thing to check. If they give a broad group or a user class such as All Confluence users a role, a new HR or security space starts out open to the whole site until someone narrows it. Decide the access before you create the space, not after the first sensitive page is in it.
Tip: on Confluence Free, space permissions can't be customized and there are no page restrictions: everyone who can sign in can view and edit every space. A space for sensitive content needs Confluence Standard or above.
Groups, teams and individuals
You can give a space role to individual people, groups, teams, apps and user classes. For a space that has to stand up to scrutiny, use groups wherever you can. "HR team: Collaborator" explains itself, while twenty names with assorted roles don't. When access follows group membership, your onboarding and offboarding process keeps the space correct without anyone editing its settings, and a review covers a handful of group grants instead of every individual entry.
Individual grants still have a place, such as a named owner who needs to edit. Keep them few, and record why each one exists.
Anonymous access, public links and guests
These are the three ways people outside your normal user base can reach a space.
- Anonymous access lets anyone on the internet read a space without signing in, and search engines can index it. It needs to be switched on for the site by a Confluence admin and then for the space by a space admin, and it is all or nothing for that space. It isn't available on Confluence Free. A compliance, HR or security space should never have it.
- Public links share a single page with anyone who has the link, no sign-in needed. If your site allows them, check that they are turned off for the sensitive space.
- Guests are external people, such as contractors or auditors, invited to collaborate in one space at a time. On paid plans a number of guests per paid user are free of charge. A guest can see everything in the space they are assigned to unless page restrictions stop them, and a guest can also view any space that allows anonymous access. Guests are a good fit for an external auditor who needs to read a compliance space and nothing else.
Keep the space admin list short
Space admins control the space: its settings, its roles and who has access. In a sensitive space they matter even more, because a space admin can see a list of the restricted pages in the space and remove those restrictions, even pages they can't open themselves. Anyone with space admin can therefore undo the page-level protection you add.
So keep space admin to a small, named group, and don't hand out the Manager role casually, since it can manage people too. Remember also that Confluence and site admins can always recover admin access to any space (Confluence records this in its audit log). That helps when the only space admin leaves, but it means you can't hide a space from your site admins.
Page restrictions sit underneath all this. On Standard and above, a view restriction hides a page (and its child pages) from people who can see the space, and an edit restriction limits who can change it. Use them for the few pages more sensitive than the rest, not as your main control.
A permission model for a private space in Confluence
Here is a model that works for most compliance, HR and security spaces. Adjust the group names to your own.
| Who | Space role | Page-level rule |
|---|---|---|
| Readers (for a policy space, every employee; for an HR space, perhaps only HR and managers) | Viewer, given to a group | None needed |
| Space admins (two to four people) | Admin, given to a dedicated group | Can edit everything |
| Page owners | Collaborator | An edit restriction on each page, so owners can edit only the pages they own |
| External auditors | Viewer, as guests or through a dedicated group | View restrictions keep them out of pages outside the audit |
| Anyone else | No access | No anonymous access, no public links |
To set it up:
- Create the groups first in Atlassian administration: readers (or an existing employees group), a small admin group and, if needed, auditors.
- Create the space without broad defaults, or remove the broad grants straight away.
- Give each group its role in the space settings, and give owners Collaborator plus edit restrictions on the pages they own.
- Check that anonymous access and public links are off.
- Write the model down: who has which role and why. It is the baseline you review against.
An access control policy should describe this kind of rule in general terms. If you are writing one, the access control policy guide covers what it should say.
Review who has access, regularly
Permissions drift: someone is added "just for this week", a group grows, a space admin changes teams. A periodic review catches it. Quarterly suits most sensitive spaces, and it fits into a wider user access review.
- Start from the space's user list. In the space settings, the users page lists every individual, group, team, app and user class with a role. Compare it with the model you wrote down.
- Check individual people when in doubt. Searching for a person in that list shows their own entry plus every group or user class that gives them access, which is their complete access to the space.
- Review group membership too. A Viewer grant to the right group is only correct if the group's members are right. Membership lives in Atlassian administration, not in the space.
- Read the audit log. On paid plans, Confluence admins can see space permission changes, content restriction changes and public link changes in the audit log. It keeps a year of entries by default and can be exported to CSV if you need a longer record.
- Record the review. Note the date, who reviewed, what you found and what you changed. For SOC 2, the record of the review is the evidence, not the fact that permissions happen to be right today.
How Compliance in a Box sets up a compliance space
If the sensitive space you're designing is a compliance program, Compliance in a Box applies this model for you. It keeps the whole program in one dedicated compliance space and manages that space's permissions from the app.
In the app's Settings, you choose three things from your existing Confluence groups: the Compliance Admins group, one or more Employee groups, and an optional Auditors group. The app then creates the space already locked down: the app and the Compliance Admins group are space admins, and the employee groups can view the space and comment (or view it, where your site has no commenter role). If your site doesn't let apps create spaces, you can create an empty space yourself, give the app space admin, and hand it over. The getting started guide walks through both.
From there the app keeps permissions in step with each person's role in the program:
- Owners edit only what they own. A policy or activity owner gets edit access to the space while they own at least one item, and every page the app manages is locked with an edit restriction to its owner, the Compliance Admins group and the app. When you change an owner, the lock follows. When someone stops owning anything, the app removes the edit access it gave them.
- Reports are restricted. The generated report pages and the controls matrix are view- and edit-restricted to the Compliance Admins group, the Auditors group (view only) and the app, because some of them show who has and hasn't acknowledged a policy. You still give auditors access to the space itself in Confluence.
- Drift is put back. The app re-applies permissions after changes and once a day, so a page lock removed by hand comes back, and the change is recorded in the app's audit log. Access you granted by hand, for example to auditors, is never touched.
If your site doesn't let the app set space permissions, Settings lists the access to apply by hand. Roles and permissions in the user guide has the full table, and Who can see the reports covers auditor access. For the bigger picture of running a program in Confluence, see how to run a SOC 2 compliance program in Confluence.
FAQ
How do I make a Confluence space private?
Remove every broad grant from the space (such as a user class covering all users, or a site-wide group), give the Viewer role only to the group that should read it, and check that anonymous access and public links are off. Because permissions are additive, check every group that still has a role, not just individual entries.
Can I hide a space from Confluence admins?
Not completely. Confluence and site admins can always recover admin access to a space, and the recovery is recorded in the audit log. Treat your site admins as people who can reach any space, and keep that list small.
What is the difference between the Viewer and Collaborator roles?
Viewers can read and comment. Collaborators can also add and edit content. In a sensitive space, give Viewer to readers and Collaborator only to people who maintain pages, ideally with edit restrictions so they can only change their own.