Audits
An audit in SolveGRC is one engagement. You can scope it to one of your activated frameworks and record the audit period, the evidence deadline, and your external auditor. Instead of the traditional email-and-spreadsheet scramble, the whole exchange lives in the platform — you collect evidence against requests, your auditor reviews it in a separate portal of their own, and when collection is done you freeze the evidence and export a defensible package.
This guide covers the engagement in three pages:
- Overview (this page). What an audit is and how it moves.
- Run an engagement. Creating the audit, scoping it to a framework, building the evidence request list, and tracking fulfillment.
- Auditor room and export. Inviting the auditor into their portal, what they can and cannot see, and freezing a defensible export.

The lifecycle at a glance
Every audit carries a status badge that walks a fixed path:
Planning → Collecting Evidence → In Review → Submitted → Completed → Closed
You advance (or step back) an audit from the Change Status action on its row — stepping back exists deliberately, so a mis-click or an auditor returning with follow-ups isn't a dead end. In practice the statuses map to four phases:
- Create. Set up the engagement: title, audit type (SOC 2 Type II, ISO 27001, PCI DSS 4.0, and so on), the framework it scopes, the audit period, the evidence deadline, and the auditor firm.
- Collect. Build the evidence request list — generated from the scoped framework's controls, imported from the auditor's PBC list, or added by hand — assign owners, and attach evidence. The bar on the engagement row fills as requests are accepted.
- Auditor room. Invite the external auditor into their own portal, where they review what you submitted, accept or reject it, raise new requests, comment, and keep their workpapers. Everything they do there is recorded. The auditor portal is part of the Enterprise plan.
- Freeze and export. Lock the evidence so nothing changes underneath the auditor's conclusions, and export a package with a manifest.
Before you start
- Access to the module. Audits appears in the sidebar only if your role can read it; creating audits and inviting auditors requires create permission, and freezing requires update permission.
- An activated framework. An audit can exist without one, but scoping to a framework is what unlocks generating requests from its control list and the readiness meter. Activate the framework you are being audited against first.
- Sealed evidence. A request is answered by attaching evidence from the Evidence Library that you have sealed for release, or by uploading a new file. The more sealed, file-backed evidence you already hold, the more requests you can answer by attaching instead of uploading. Evidence linked to a control is not attached to that control's request for you.
The audit's scope is the engagement, not your whole program. If the same firm audits you against SOC 2 this quarter and ISO 27001 next quarter, that is two audits — each with its own request list, portal access, and frozen export.
How this connects
The Audits module consumes:
- Framework scope from Frameworks — the activated framework an audit is scoped to drives request generation and readiness tracking.
- Evidence from the Evidence Library. Requests are answered by attaching sealed evidence you already hold, or by uploading new files.
It produces audit engagements with evidence requests and a defensible frozen export, and it feeds:
- Your auditor's separate portal. The auditor can download only evidence you sealed. Files that came from a vendor submission also stay blocked while their malware scan is pending or if the scan flagged them.
- Rejected evidence back to its owner. A rejection carries the auditor's note. You can turn a rejected request into a risk with Escalate to risk, and the auditor's follow-ups appear under Shared finding follow-ups.
If what you need is a generated summary document rather than an evidence engagement, that is the Reports module.