Confluence auditor access: what you are actually setting up
Every audit reaches the same moment. The auditor sends a request list, most of the answers are pages in your Confluence site, and someone has to decide how an outsider gets to them. Setting up Confluence auditor access well comes down to four questions:
- How does the auditor get in? A guest account, a regular account, a link, or files you send them.
- What can they see? Only the spaces and pages in scope, not your whole site.
- What can they do? Read and, at most, comment. Never edit evidence.
- For how long, and who knows about it? Access with a start date, an end date and a record.
Get these right and the access itself becomes good evidence: an auditor testing your access controls will notice how you set up theirs.
Four ways to share Confluence with an external auditor
Confluence Cloud gives you a few options, and several depend on your plan.
| Option | What the auditor sees | Main limits |
|---|---|---|
| Guest account | One space you assign, live, including page history | One space at a time; guest access is set per person, not through groups |
| Regular account in a view-only group | Whatever spaces the group can view | Uses a paid seat on a paid plan; on Confluence Free it can edit everything |
| Public link | A single page, current version only | Paid plans only; anyone with the link can open it; no page history |
| Exports (PDF or Word) sent or shared | A snapshot of the pages you chose | Copies you can't take back; no live version history |
Confluence guest access
Guests are Confluence's built-in way to bring in people from outside your organization. An organization or site admin invites them from Atlassian Administration with the Guest role, and a Confluence admin then assigns them to a space. Atlassian includes guests at no charge up to five per paid user, and the total still has to fit within your site's user limit. Check your plan before you count on them.
What makes guests a good fit for auditors:
- A guest can only access one space at a time, so they can't wander into the rest of your site.
- Guests can't browse the people directory or search for users.
- They can't be given the Space admin, Export space or Restrictions permissions.
- They see live pages, so they can open the page history and check which version was approved.
Two things to watch. First, by default a guest can add pages, comment and add attachments, not just view. If you want read-only access, remove the add and attachment permissions for that guest in the space's permissions. Second, Atlassian manages guests' space and page access per person, not through groups. If some evidence sits on pages with view restrictions, a group listed on the restriction may not open those pages to a guest. Test with the auditor's account before fieldwork starts, not on the morning of the first walkthrough.
The one-space limit is one more reason to keep audit evidence in a single compliance space (see running a SOC 2 program in Confluence).
A regular account in a view-only group
The other common route is a normal Confluence account for each auditor, added to a dedicated group (for example external-auditors) that you give view-only access to the spaces in scope. With space roles, that means the Viewer role, which can view and comment. This works across several spaces and lets you manage access by group membership.
The trade-offs: on a paid plan the account uses a paid seat, and the auditor is a full user. If new accounts land automatically in a group that can see every space, so does the auditor, so check their group memberships.
Important: Confluence Free has no space permissions or page restrictions. Everyone who can log in can view, add and edit everything. On Free, an auditor account is an editor of your whole site, so send exports instead.
Public links
On paid plans, a page can get a public link that anyone on the internet can open without signing in. That is rarely right for audit evidence. Public links ignore page and space restrictions, anyone you send the link to can forward it, and the viewer sees only the current version of that one page: no page tree, no comments and no page history. An auditor checking which version of a policy was approved needs exactly the history a public link hides. If you use one at all, keep it to a single non-sensitive page and turn it off after the audit. Space and site admins can turn public links off.
Exports by email or a shared drive
Some auditors prefer files in their own portal. Confluence can export a page to PDF or Word for anyone with the export permission who can view it, and a space admin can export a whole space or a selection of pages. Exports are simple, but they are copies: you can't revoke them, and they show the page as it was at export time. Note in your access record what you sent and to whom.
Least privilege for auditor access
Whichever route you choose, treat it like any other access request:
- Scope it. Only the space or spaces in scope for the audit. Not the whole site, not HR, not sales.
- Read only. Viewer access, or a guest with the add and attachment permissions removed. An auditor should never be able to change evidence.
- Named accounts. One account per person, never a shared login for the audit firm.
- Time-boxed. Set an end date when you grant access, usually the end of fieldwork plus a short buffer for follow-up requests. Put a reminder on the calendar.
- Removed on schedule. For a guest, unassign them from the space or remove their Confluence access. For a regular account, remove them from the group and revoke product access.
If you run a periodic user access review, include auditor accounts in it. A leftover auditor account from last year is an easy finding to avoid.
Keep a record of auditor access
Write down what you granted. A short table on a page in your compliance space, or a ticket per audit, is enough. For example:
| Field | Example |
|---|---|
| Auditor and firm | Lead auditor, external audit firm |
| Account type | Guest |
| What they can access | Compliance space, view only |
| Approved by | Head of engineering |
| Granted on | First day of fieldwork |
| Planned removal | Two weeks after fieldwork ends |
| Actually removed | Date, and who removed it |
| Files sent | List of exports, date and recipient |
Fill in "actually removed" when you remove the access, not when you planned to.
What auditors typically need to see
Your auditor's request list is the authority here, and the scope, format and sample sizes are theirs to set. For a SOC 2 audit the requests commonly cover:
- Policies, with who approved each version and when, and the review history.
- Policy acknowledgements: who accepted which policy version, and when.
- Evidence of recurring controls: access reviews, vulnerability scan reviews, backup restore tests and similar, for each period in the audit window.
- Populations for sampling, such as lists of new hires, leavers or changes, from which the auditor picks samples.
- An index that maps each control to where its evidence lives.
The index saves the most time: an auditor who can find things alone sends fewer follow-up requests. For how to organize the evidence itself, see SOC 2 evidence collection, and for the steps before fieldwork, the readiness checklist.
Avoid over-sharing in Confluence
Read-only access to a space is still access to everything in it. Before the auditor's first login, walk through the space as if you were them.
- Restrict sensitive pages. On paid plans, a view restriction on a page also applies to every page below it. Use that for pages the auditor doesn't need, such as HR cases or draft incident write-ups.
- Check attachments. An attachment is only as private as the page it sits on. Spreadsheets exported for an access review often hold names, emails and roles; screenshots can show customer data or secrets. Redact what the auditor doesn't need, or move it to a restricted page.
- Check comments and page history. Something pasted and later removed may still be in an older version.
Auditor access with Compliance in a Box
Compliance in a Box runs a SOC 2 program in one Confluence space and writes its records into ordinary Confluence pages there. Under an Evidence & Reports section it generates a Policy Approval Log, a Policy Acknowledgement Report, an Activity Completion Report and monthly Audit Log pages, and next to them a Controls Matrix that shows each SOC 2 criterion with its mapped policies and activities. That gives the auditor the index described above, built from the app's own records. See the generated pages in the guide.
Because those pages show sensitive detail, such as who hasn't acknowledged a policy yet, they are view- and edit-restricted to the Compliance Admins group and the app. To let auditors read them, a Compliance Admin sets an optional Auditors group:
- Create a Confluence group for your auditors and add their accounts to it.
- In Compliance in a Box, open Settings and find the Access section.
- Under Auditors group (optional), choose the group and click Save auditors group. The app applies the page restrictions in the background, and the change is recorded in the audit log.
- Give the group view access to the compliance space in Confluence. The Auditors group setting only opens the report pages; it doesn't add the group to the space.
Members of the Auditors group can view the report pages and the controls matrix but not edit them. They need no role in the app: they work in Confluence, read the policy and evidence pages like any other page, and follow the version links in the reports to the exact page version that was approved or acknowledged. Every page the app manages is edit-restricted, so auditors can't change any of them. If your auditors join as guests, have one of them open the Controls Matrix before fieldwork to confirm the access works for their account.
When fieldwork ends, clear the Auditors group field and save to make the reports visible to Compliance Admins only again, then remove the group's space access. The app never removes space access it didn't grant, so that last step is yours. Details are in Set up the Auditors group and the Access settings.
Before the auditor looks, click Refresh now under Settings > Evidence & Reports so the pages are current. If the auditor wants files instead of access, they can export the pages with Confluence's own export, and the version links in a PDF still work for anyone with access to your site. The guide's audit preparation checklist lists which page answers which question.
Note: on Confluence Free there are no page restrictions, so the report pages are visible to everyone who can view the compliance space. Settings and the Dashboard warn when this applies.
FAQ
Can I give an auditor access to Confluence without paying for a seat?
Often, yes, as a guest, depending on your plan. Atlassian includes up to five guests per paid user at no charge, within your site's user limit. A guest is limited to one space at a time, so plan your evidence around that.
When should I remove auditor access?
Shortly after fieldwork and follow-up requests end, on a date you set when you granted it. Record the actual removal date, and check for leftover auditor accounts in your next access review.
Is sending PDFs safer than giving access?
It exposes less of your site, but you lose control of the copies and the auditor can't check page history themselves. Live, read-only access to a single space is often the better balance. Your auditor may have a preference, so ask.