Audits

An audit in SolveGRC is one engagement: it scopes your chosen frameworks and evidence into a single container with a period, a deadline, and an 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:

1. Overview (this page). What an audit is and how it moves.
2. Run an engagement. Creating the audit, scoping it to a framework, building the evidence request list, and tracking fulfillment.
3. Auditor room and export. Inviting the auditor into their portal, what they can and cannot see, and freezing a defensible export.

The Audits module: Dashboard, Engagements, and My Assignments tabs, with the engagements table showing each audit's type, status, auditor firm, evidence progress, and deadline.

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:

1. 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.
2. 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 until the fulfillment bar fills.
3. Auditor room. Invite the external auditor into their own portal, where they review what you submitted, accept or reject it, raise new requests, and comment — all recorded.
4. 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.
• Evidence worth showing. The engagement pulls from the evidence you already have. The more your Evidence Locker and Documents already hold, the more requests you can satisfy by linking rather than hunting.

One engagement per audit, not one audit per framework

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 Locker — requests are fulfilled by attaching or linking evidence you already hold.

It produces audit engagements with evidence requests and a defensible frozen export, and it feeds:

• Your auditor's separate portal — with downloads gated so nothing unreleased or unscanned reaches an outside party.
• Findings back into your registers — what the auditor rejects or flags returns as work in your own modules.

If what you need is a generated summary document rather than an evidence engagement, that is the Reports module.