If you have ever been asked "who can see this space?" during a SOC 2 or ISO 27001 review, you will have discovered that Confluence Cloud has no straightforward answer. There is no built-in report showing user access across all pages at space or global level. On Server and Data Center you could run a SQL query against the database. On Cloud that door is closed, and Premium only adds a single-user permission inspector, which answers "what can Anna see?" one person at a time, not "who can see this page?" across a space.
This post covers what you can actually do natively, where those methods stop working, and the one inheritance behaviour that quietly breaks most access reviews.
The trap: view restrictions inherit, edit restrictions do not
This is the part worth knowing even if you read nothing else.
In Confluence, view restrictions cascade down the page tree. Restrict viewing on a parent page and every child below it inherits that restriction, whether or not you touch the children.
Edit restrictions do not cascade. They apply only to the page you set them on.
The consequence: you can have a page that is correctly hidden from most of the company, while everyone who can still see it is also able to edit it. In the UI it looks locked down. There is a padlock. An auditor glancing at it would tick the box. But the page is editable by every person in the inheriting audience.
Concretely:
Handbook (view restricted to: HR group)
└── Compensation Bands <- inherits the view restriction, no edit restriction set
└── 2026 Salary Review <- same
Everyone in HR can see those pages, which is intended. Everyone in HR can also silently rewrite the salary bands, which usually is not. Nobody set that up deliberately, it is just what inheritance does by default.
This is also the mechanism behind CONFCLOUD-5095, the long-running request for edit-permission inheritance, which has accumulated a large vote count over many years.
What you can do natively
1. Per-page check. Open a page, three dots menu, Restrict Permissions. This shows the view and edit lists for that page, and tells you if restrictions are inherited from an ancestor. Accurate, and fine for a handful of pages.
2. Find the ancestor a restriction comes from. Confluence tells you a page is inheriting, but not from where. Walk up the tree: start at the space home, open Restrictions on each ancestor going down. The first ancestor with a view restriction is the one propagating.
3. Search for what you can reach. In a space, search spacekey: ~me to list pages you have browse or edit access to. Useful, but note the limits: it reflects your access, so it cannot tell you what a colleague sees, and it does not separate view from edit.
4. Premium user inspector. If you are on Premium, you can inspect an individual user's permissions. Good for "does Anna have access she should not?", not for "who has access to this?"
5. Audit log. Confluence Cloud audit logging now covers permission changes, including page-level privacy changes. This tells you what changed, which is valuable for investigations, but it does not give you the current state. An audit log answers "who changed this and when", not "what is the situation right now".
Where the native methods run out
All of the above are per-page or per-user. None of them produce the thing an access review actually needs, which is a table: page, path, who can view, who can edit.
Once a space is more than a few dozen pages, checking each one by hand stops being realistic, and the manual pass is exactly where mistakes survive. The inheritance trap above is invisible unless you compare the view list and the edit list side by side for every page.
A practical access review checklist
Regardless of tooling, these are the things worth checking:
- Pages restricted for viewing with no edit restriction. The trap described above. Highest value check, and the one most often missed.
- Restrictions naming deactivated accounts. People leave, restriction lists do not update. Stale entries make a review look thorough while being inaccurate.
- Guest and external accounts on restricted content. Especially after any period of heavy external collaboration.
- Anonymous access and public links. Public links in particular survive later restriction changes, so a page can be locked down and still publicly reachable by URL.
- Individual users where groups should be. User-level restrictions cannot be copied when onboarding and rot when people leave. Mirror them into groups, verify, then remove individuals.
Migrating from user-level to group-level restrictions
If your restrictions were set per user, the fix is worth doing before your next review:
- Create groups that mirror the access patterns you already have in practice.
- Add the groups to the restrictions alongside the existing individuals.
- Verify access still works for everyone who needs it.
- Remove the individual entries.
Doing it in that order means nobody loses access mid-migration.
Closing
Everything above is native Confluence. No add-ons required, and the manual methods are real methods, they just stop scaling somewhere around a few dozen pages.
Full disclosure on where I am coming from: I am the founder of Stackedboost, an Atlassian Marketplace Partner, so Confluence permissions are something I spend an unreasonable amount of time inside.
If you have found a cleaner way to handle the view-versus-edit inheritance problem at scale, I would genuinely like to hear it. It is the part that still has no good native answer, and I have not seen anyone solve it with built-in features alone.
