The generated pages
Compliance in a Box writes its records into ordinary Confluence pages in your compliance space. Auditors can read them like any other page and export them with Confluence's own export, for example to PDF. Nothing leaves Atlassian: the pages are built inside your site from the app's own records.
The pages live in two places in the compliance space's page tree:
- Controls Matrix — SOC 2, directly under the space home page, next to Policies and Recurring Activities.
- The Evidence & Reports section, which holds four reports. Each report has an index page, with one child page per period below it.
| Report (index page) | Period pages below it | A period holds |
|---|---|---|
| Policy Approval Log | Policy Approval Log — 2026 | Submissions made in that calendar year |
| Policy Acknowledgement Report | Policy Acknowledgement Report — 2026 | Acknowledgement campaigns opened in that calendar year |
| Activity Completion Report | Activity Completion Report — 2026 | Activity periods due in that calendar year |
| Audit Log | Audit Log — September 2026 | Audit log entries recorded in that month |
A few things are true of every generated page:
- Periods are calendar years or months in UTC, even if your fiscal year starts in another month. Activity period names inside the reports still use your fiscal-year labels, such as "FY2027 Q2".
- Each page starts with a short header saying it was generated by Compliance in a Box, that edits are overwritten, and the date and time (UTC) of the newest record it shows ("Data as of …").
- Very large periods are split across numbered pages, such as "Policy Approval Log — 2026 (2)". The index page links every part.
- People appear as plain-text names, looked up when the page is generated. The app stores only Atlassian account IDs, never names or emails, so a renamed person shows their new name after the next refresh. A person whose Atlassian account was closed appears as "Former user".
The Evidence & Reports section also holds the Weekly compliance summary page (unless an admin turned it off), which has the same restricted visibility. It is covered in Dashboard, tasks and reminders.
What each report contains
This section lists what you will find on each page. For how approvals, acknowledgements and activity periods work, see Policies and approvals, Policy acknowledgements and Recurring activities.
Policy Approval Log
The index page lists every policy with its status, its current approved version, the date it was approved, who approved it, its owner and its next review date. The Approved version column links to exactly the page version that was approved. Self-approvals are marked "(self-approved)", and a version approved only by its owner or submitter is flagged "No independent approver". A policy past its review date shows "Review overdue".
Each yearly page lists every submission made that year, oldest first: when it was submitted, the policy, the submitted version (linked), who submitted it, the change summary, whether it was a material change or a review only, each approver's decision with the date and any comment, and the outcome. A cancelled submission says why, for example "the page was edited after submission" or "withdrawn".
Policy Acknowledgement Report
The index page shows each policy's current acknowledgement campaign: the audience, the version people must acknowledge (linked), when the campaign opened, the due date, and how many people are required, have acknowledged, are overdue or are not required, with the percentage complete.
Each yearly page covers the campaigns opened that year. It starts with a summary table of the campaigns, then lists every person asked: why they were asked (the campaign, or joining the audience later), their due date, their status, when they acknowledged and which page version they acknowledged. People who are no longer required show the reason, such as "left the audience", "excused by an admin" or "policy retired". A campaign replaced by a later one is marked "Superseded" and its records stay on the page as evidence.
Activity Completion Report
The index page lists every recurring activity with its cadence, owner, last completed period, the date it was completed, a link to the approved evidence page version, the next due date and how many periods are overdue.
Each yearly page lists every activity period due that year, by due date: its status, every submission round (who submitted which page version and when, plus each approver's decision), a link to exactly the evidence page version that was approved, and the reason and person for any skipped period. "Overdue" means past its due date and neither approved nor skipped.
Audit Log pages
The Audit Log index lists each month with its number of entries. Each monthly page shows that month's entries, oldest first, with the time (UTC), who made the change, where it came from (the app, a page byline, the daily job, a background job or install/upgrade), the action, the subject and the details. It is the same log as the in-app Audit Log tab, except that the entries recording the report refresh itself appear only in the app.
Controls Matrix
The Controls Matrix lists every SOC 2 criterion in the categories you selected, grouped by heading. For each criterion it shows the policies and recurring activities mapped to it, each with a link and its current status, and an overall status for the criterion:
| Status | Meaning |
|---|---|
| Covered | Every mapped policy is approved, and every mapped activity has an approved period with nothing overdue. |
| Attention | Work in progress: changes pending, awaiting approval, a skipped period, or no period due yet. |
| Gap | A mapped policy was never approved or is overdue for review, an activity period is overdue, or nothing is mapped to the criterion. |
The top of the page totals how many criteria are covered, need attention or are gaps. Custom policies are not mapped to framework controls, so they don't appear in the matrix (see Importing and custom policies). The full list of mappings is in the SOC 2 content reference.
Note: the control mappings are a starting point, not audit advice. Have them reviewed by your auditor.
How the pages are refreshed
The app rebuilds the report pages and the controls matrix from its records once a day, automatically. A Compliance Admin can also refresh them at any time. A refresh only writes a page whose content changed, so unchanged pages don't collect extra versions in their page history.
Refresh the pages now
- Open Compliance in a Box and go to Settings.
- Scroll to the Evidence & Reports section.
- Click Refresh now. A progress bar shows how many pages have been checked.
- When it finishes, the section shows "Last refreshed" with the time and how many pages were updated, created or unchanged.
The same section lists every generated page with a link, its number of rows and when it last changed. While a refresh is running, Refresh now is unavailable until it finishes. The Dashboard also shows when the pages were last refreshed. Each manual refresh is recorded in the audit log.
Refreshing works even when the app's license is inactive, so you can always bring your evidence up to date.
Don't edit the generated pages
The app owns these pages. Any change made by hand, including a new title, is overwritten by the next refresh, and the refresh summary counts the "hand edits overwritten". The pages are also edit-restricted, so only Compliance Admins and the app can change them. To add context for an auditor, write it on a separate page, or use Confluence comments.
If a page can't be refreshed
The Dashboard shows a warning when pages couldn't be refreshed, and the Evidence & Reports section in Settings lists each failed page with the reason. The most common ones are:
- The page is in the trash or was deleted. Restore it from the space's trash. The app doesn't create a replacement.
- Another page already has the title. Rename or move the other page.
- The parent page is missing. Restore it from the trash.
If Confluence itself returned an error, the next refresh tries again. See Troubleshooting and FAQ for more.
Who can see the reports
Some reports hold sensitive information, such as which people have or haven't acknowledged a policy. So the report pages and the controls matrix are view- and edit-restricted:
- Members of the Compliance Admins group can view them.
- Members of the optional Auditors group can view them, but not edit them.
- The app itself can view and update them.
Everyone else, including employees, owners and approvers, can't open them. The Evidence & Reports section page itself is not restricted, but the reports under it are.
Important: Confluence Free has no page restrictions. On Confluence Free the reports are still generated in full, but they are visible to everyone who can view the compliance space. Settings and the Dashboard show a warning when this applies.
Set up the Auditors group
- Create a Confluence group for your auditors and add their accounts to it, as you would for any other group.
- In Compliance in a Box, go to Settings and find the Access section.
- Under Auditors group (optional), choose the group.
- Click Save auditors group. The app applies the page restrictions in the background shortly afterwards. The change is recorded in the audit log.
- Make sure the group can also view the compliance space. The Auditors group setting only opens up the report pages; it doesn't add the group to the space. Give it view access in the space's permissions in Confluence. The app never removes space access that it didn't grant.
To make the reports visible to Compliance Admins only again, clear the field and save.
What auditors can and can't do
Auditors work in Confluence, not in the app. Being in the Auditors group gives no role in Compliance in a Box. With view access to the space, an auditor can:
- Read the report pages and the controls matrix, and export them with Confluence's export.
- Follow the version links in the reports to see exactly what was approved or acknowledged.
- Read the policy pages and activity evidence pages, which are ordinary pages in the space.
Auditors can't edit any managed page, because every page the app manages is edit-restricted to its owner, the Compliance Admins and the app. An auditor who isn't also an employee, owner, approver or admin sees "You're not part of this site's compliance program" if they open the app. That's expected: everything they need is in the space.
The Audit Log tab
The Audit Log tab in the app is visible to Compliance Admins only. It lists every change recorded by Compliance in a Box, newest first, 25 entries at a time; click Load more to see older entries. Each entry shows:
- When
- The time of the change, in your browser's local time. The generated Audit Log pages use UTC.
- Who
- The person who made the change, or "System" for the app's own scheduled work.
- What
- The action, such as "Policy submitted for approval", "Policy acknowledged", "Activity period skipped" or "Setting changed".
- Subject
- What the change was about: a policy, an activity, a setting, the compliance space and so on.
- Details
- The specifics, for example a setting's old and new value.
The tab has no search or filters. For a month at a time, or for an auditor, use the generated Audit Log pages. Every user can see their own history in My Tasks.
What is recorded
Every state change writes an entry, including:
- Policy submissions, approvals, rejections and cancelled submissions, policy pages edited after approval, and review dates coming due.
- Acknowledgement campaigns opening, each acknowledgement, people joining an audience, and acknowledgements that are no longer required.
- Activity periods opening, evidence submissions, approvals, rejections and skips, and schedule changes.
- Settings changes, owner and approver changes, and permission changes the app applied.
- Creating the compliance space, generating pages, managed pages moved to the trash or restored, and framework updates.
- Policy imports, custom policies created or retired, reminders sent, and evidence refreshes.
The log is append-only
Entries can't be edited or deleted, by anyone, and the log is never pruned. The one exception is privacy erasure: when Atlassian reports that a person's account was closed, the app removes their identity from its records, including the audit log. The entries stay, so counts and timelines are intact, but the person is shown as "Former user".
The app stores only account IDs, never names. Names in the Audit Log tab are looked up live when you view it, so they always show a person's current name.
Why the evidence holds up
Every approval and acknowledgement is bound to an exact version of a Confluence page. When someone submits a policy or evidence page, the app records the page version number and a fingerprint of the page content. If the page is edited before every approver has decided, the submission is cancelled and has to be submitted again, so an approval always covers exactly what the approvers saw.
This is what makes the reports useful to an auditor:
- Each "Version N" link in the reports opens that exact version from the page history, even if the page has changed since. The links are full addresses, so they still work in an exported PDF for anyone with access to the site.
- Acknowledgements record which page version each person acknowledged.
- Apart from a policy import that a Compliance Admin starts on purpose, the app never edits a policy or evidence page after creating it, so the page history shows who changed what.
Preparing for an audit
Before the audit window, work through this list:
- Close the gaps you can. Open the Dashboard for overdue items, and the Controls Matrix for criteria marked Gap or Attention. If the Dashboard warns that work was approved without an independent approver, decide whether to add an approver and resubmit, or be ready to explain it.
- Refresh the pages. Go to Settings > Evidence & Reports, click Refresh now, and check that no page failed.
- Give the auditors access. Set the Auditors group and give it view access to the compliance space.
- Point the auditors to the right pages for the audit period:
- the Controls Matrix, for coverage of each criterion;
- the Policy Approval Log, for who approved which version of each policy and when;
- the Policy Acknowledgement Report, for who acknowledged which version and when;
- the Activity Completion Report, with links to each approved evidence page version;
- the Audit Log pages for the months in scope.
- Export if needed. If the auditor wants files rather than access to your site, export the pages with Confluence's export. Refresh first so the exports are current.
Tip: the yearly pages follow calendar years in UTC. If your audit period crosses a year boundary, give the auditor both years' pages.
Before uninstalling
If you uninstall Compliance in a Box, your Confluence pages stay in the space, including the Evidence & Reports pages and the controls matrix. They keep the evidence as of their last refresh. The app's own records (approvals, acknowledgements and the audit log) are deleted by Atlassian after a retention period.
- Go to Settings > Evidence & Reports and click Refresh now.
- Wait for the refresh to finish and check that no page failed.
- Uninstall the app.
The app also tries a last refresh when it is uninstalled, but that is best effort and limited to under a minute, so don't rely on it. Reinstalling starts with empty records. If you uninstalled by mistake, contact support within 21 days.