Ask anyone who administers Confluence which pages are locked down and they will point at the padlock icon. Ask them who can edit those pages and the answer gets vague fast. In most Confluence sites those are two completely different lists, and the gap between them is where the real exposure sits.
A restricted page is not necessarily a protected one
Confluence gives every page two independent controls: who can view it, and who can edit it. Teams reach for the first one constantly. Someone locks a salary review, a board deck, a security incident writeup, or an unannounced roadmap so that only a handful of people can open it. The padlock appears, everyone relaxes, and the page is considered handled.
But setting a view restriction does nothing to the edit rules. If the page carries no separate edit restriction, then every single person who can still open that page can also rewrite it, move it, or delete its contents. You narrowed the audience and accidentally gave that entire narrowed audience full write access.
For a page restricted to three executives, that is fine. For a page restricted to “everyone in the Leadership space”, which might be forty people, it means forty people can silently edit a document that looks locked.
The inheritance rule almost nobody knows
Here is the detail that turns a small problem into a site-wide one. In Confluence, view restrictions inherit down the page tree, and edit restrictions do not.
Lock a parent page for viewing and every child underneath it inherits that protection automatically. That behaviour is well known and teams rely on it. So an admin locks the top of a sensitive tree, sees the padlock propagate, and reasonably assumes the whole branch is secured.
Edit restrictions behave differently. They apply only to the exact page you set them on. Every child page beneath a carefully edit-locked parent starts life wide open again. The tree looks uniformly protected in the page list, and underneath it is anything but.
This is not a bug and Atlassian documents the behaviour. It is simply invisible in daily use, and it compounds quietly over the years a space has been alive.
Three more things that rot over time
The view-versus-edit gap is the big one, but permissions decay in other predictable ways once a site has a few years on it.
External accounts that were never removed. A contractor, an agency, or a partner gets named on a restricted page for a project. The project ends. Nobody revisits the restriction, because the restriction lives on the page rather than in any list an admin reviews.
Deactivated users still holding grants. Someone leaves, their account is deactivated, and the permission entry naming them stays behind on dozens of pages. Mostly harmless, right up until an identity gets reactivated or recycled.
Pages edit-locked but readable by the entire space. Sometimes deliberate, sometimes a half-finished attempt at securing something. Worth reviewing when the space is big or the content is sensitive.
Why the built-in screens will not tell you this
Confluence has good permission tooling, but it operates at the wrong altitude for this question. Space permissions show you who has access to a space as a whole. Page restrictions show you the rules for one page, in a dialog, one page at a time.
What no native screen gives you is the cross-cutting view: every restricted page across a space or the whole site, with its viewers and its editors side by side, so the mismatches jump out. To assemble that by hand you would open each page, read its restrictions dialog, note who is listed under view and who is listed under edit, and repeat. On a space with two thousand pages that is not a task anyone finishes.
What a real permission audit looks like
A useful audit answers four questions for every restricted page in one pass:
- Where does this page live, by space and full breadcrumb path?
- Exactly who can view it?
- Exactly who can edit it?
- How badly do those two answers disagree?
That last question is what turns a data dump into something actionable. A page that is restricted for viewing but open for editing is a genuine problem and belongs at the top. A page where both view and edit are properly locked is evidence that the control works, and it should be listed so you can prove it was checked, not so you have to do anything about it. A deactivated user on an old grant sits somewhere in the middle.
Sort by that severity and a list of two thousand pages usually collapses into a dozen that actually need a decision this week.
Doing it in one click
This is exactly the job we built PermPilot for. It installs onto Confluence Cloud from the Atlassian Marketplace, and you pick a space or your whole site and run an audit. It walks every page, reads the real view and edit state, and ranks what it finds from Critical down to correctly Locked.
Two properties matter more than the speed. First, it is read-only, so it reports on permissions and never changes them. Second, it runs on Atlassian Forge inside your own tenant, which means no page content and no permission data ever leaves Atlassian. It also runs with your permissions rather than some elevated service account, which is what allows it to evaluate the restricted pages you are entitled to see in the first place.
Auditing one space is free. Auditing every space at once, plus the CSV export with a recommendation per page, is the paid tier.
When the auditor asks
If you are working toward SOC 2 or ISO 27001, or just running an internal access review, the reviewer will not accept “the sensitive pages are restricted” as an answer. They want the list, they want to see who is on it, and they want evidence that someone looked and made a decision.
A CSV with every restricted page, its viewers, its editors, a severity, and a recommendation is that evidence. Producing it in a minute instead of over a week is the difference between doing the review properly and doing it the night before.
The takeaway
The padlock in Confluence tells you a page has a view restriction. It tells you nothing about who can rewrite that page, and because edit restrictions do not inherit down the tree the way view restrictions do, the answer is usually broader than anyone expects. Check the gap between those two lists once, and you will find things worth fixing. Check it on a schedule, and you will have an answer ready the next time someone asks.
Audit your Confluence permissions in one click.
PermPilot shows who can view and edit every page, ranks the risks by severity, and exports an audit-ready CSV. Free for one space.
See how PermPilot works →