Security audit#

A Security Audit is a generated document that answers "what can this person see, and why?". It is built from the same security checks Reportworq applies when someone signs in, so it describes what each user can actually reach rather than what an administrator intended.

When to use it. For an access review (who could see what on a given date), to explain why a user's report comes back empty or a folder is missing, or to confirm that a change to an entitlement or group did what you meant.

Run an audit of every user#

1. Open Settings > Security. Only system administrators can open this screen.
2. Select Security Audit in the header.
3. In the Security Audit dialog, choose a format: Markdown, PDF or Excel.
4. Leave Include report data (slower) selected to list the runs, output variations and data slices each user can reach in each report. Clear it for a faster sweep of entitlements only; the document states that report data was excluded.
5. Select Generate. A progress message in the header counts through the users, and the file downloads when it is ready.

The audit covers every enabled account, alphabetically, one section each. Disabled accounts are not included. Each user is evaluated as that user, not as you, so an administrator's own bypass is never mistaken for the other users' access. A very large instance is capped at the first 250 enabled accounts, and the document says so in an integrity note.

What the document contains#

• Header. When it was generated and by whom, the scope, how many users were audited, and a reminder that the document shows only what each user can see. Content a user cannot see is absent from that user's section, not listed as denied.
• Global configuration (all-users audit only). The Microsoft 365 and Google Workspace shared credentials, listed by name and identifiers. Secret values are never included.
• Workspace security. For each workspace, the integrations it may use (datasources, report providers, AI connections and distributors) and the name of the credential each one references. See Choose which workspaces see an integration.
• One section per user. Name, email, entitlement, groups and workspaces. System Administrators and Authors are marked as seeing content because of their role, not because of a grant. Then the secured lists that apply to the user (a list with no values mapped to the user is called out, because that is why report output comes back empty), and per workspace the folders and reports the user can see and why.
• Integrity notes. Anything the audit could not verify is recorded as a note rather than reported as a finding.

Choose a format#

Let users audit themselves#

By default only administrators can run an audit. To let everyone else generate a statement of their own access:

1. Open Settings > Configuration, on the Web Server tab.
2. Under Security, select Allow users to perform a security audit and save.

Users then see Security Audit in their account menu (the avatar menu at the top right) and get Markdown or PDF of their own access, with no Excel option. A user's own audit shows their workspaces' integrations and credential names but not the instance-wide credential configuration. The same setting controls whether a user's AI assistant can run the security_audit tool, which requires an OAuth sign-in; it is refused for an instance API key because a key carries no user identity. Administrators are unaffected by the setting.

Notes and limits#

• Each audit you generate is recorded in the System Log, with who ran it, the scope, the format and how long it took. The document itself is not stored in the log.
• The audit is a snapshot. Run it again after you change entitlements, groups, secured lists or workspace integrations.
• The Security Audit button is not offered in recovery (backdoor) mode, because there is no signed-in identity to audit.