How to audit who can view and edit every page in Confluence Cloud

[#1]

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:

1. Pages restricted for viewing with no edit restriction. The trap described above. Highest value check, and the one most often missed.
2. Restrictions naming deactivated accounts. People leave, restriction lists do not update. Stale entries make a review look thorough while being inaccurate.
3. Guest and external accounts on restricted content. Especially after any period of heavy external collaboration.
4. 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.
5. 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:

1. Create groups that mirror the access patterns you already have in practice.
2. Add the groups to the restrictions alongside the existing individuals.
3. Verify access still works for everyone who needs it.
4. 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.

[zoltanersek _outpostlabs_dev_]

Nice summary. I

think the biggest takeaway is that Confluence's native tools answer either "What can this user access?" or "What restrictions does this page have?", but not "Who has access to all sensitive content?"

Once a space grows beyond a few dozen pages, that becomes a challenge. That's why I also like your recommendation to standardize on groups instead of individual users.

[Peter Hallander _Stackedboost_]

That is a clearer way of saying it than I did in the article. The native tools only focus on one aspect: one user or one page. The key question during an audit is about the intersection. Unfortunately, there is no way to ask it without creating the table yourself.

The group point is the one I would push hardest. Individual user restrictions tend to linger. No one goes back to remove a name from a restriction list when someone leaves. As a result, a review might seem complete while being misleading. Groups at least fail in one place instead of hundreds.

[Jamie Knight]

I ran into the issue where edit restrictions don’t inherit, and honestly, it’s been really frustrating. 

The specific scenario included 50+ pages so doing it one by one would be very time consuming. Checking all options, I asked Rovo whether it could help update the permissions under a specific parent, and it seemed like it could. I didn’t move forward with that approach, but I’ve added it to my to-do list to look into further.

[Peter Hallander _Stackedboost_]

On the Rovo question, worth checking carefully before you rely on it. Rovo can update
Confluence pages, but that runs through a Rovo Agent with the "Update Confluence Page"
action, and that action edits page content rather than restrictions. Restrictions are a
separate object in the API. So it may well have told you it could help without actually
having a path to do it, which is a common failure mode when you ask an assistant whether
it can do something instead of watching it do it.

Two things also worth separating, because they get conflated constantly:

Bulk space access, under Confluence Administration then Permissions, does exist and works
well. But it changes space permissions, not page restrictions. Different layer, and it will
not touch your 50 pages.

Page restrictions have no native bulk editor at all. That is the honest state of it on Cloud.

The routes that actually work are the content restriction REST endpoints, which you can
script in a loop per page, or an app that does the same thing with a UI on top.

One thing that is native and worth switching on regardless: Automation has "Page restriction
added" and "Page restriction removed" triggers at space level. That will not fix the existing
50, but it stops the next 50 accumulating silently, and it gives you a record for the next
review.

Whatever route you take, capture the before state first. Permissions are the worst place to
find out a bulk write half succeeded.

[Jamie Knight]

Thanks, Peter. I plan on testing it before relying on it for mass changes. 

[Peter Hallander _Stackedboost_]

Good call testing first. One thing that saves pain: run it on two or three throwaway pages before any loop, and diff the before/after restriction state on each. The content-restriction endpoints are unforgiving about inheritance, so a change that looks right on one page can behave differently on a child page. Capture the before state either way. Happy to share the shape of a safe test if useful.