Run an engagement
This page covers the internal half of an audit: creating it, scoping it, and collecting evidence until the request list is fulfilled. The external half — the auditor's portal and the frozen export — is the next page.
Create the audit
Click New Audit (top right). The form asks for:
- Title and audit type. The type comes from a standard list — SOC 2 Type I and Type II, ISO 27001, PCI DSS 4.0, SOX, HIPAA, FedRAMP, and others.
- Framework. Optional but consequential: scoping the audit to one of your activated frameworks is what lets you generate evidence requests from its control list and track readiness against it.
- External auditor. Firm, contact name, and contact email.
- Audit period and evidence deadline. The deadline turns red in the table once it passes with the audit still open.
- Description and internal notes. Notes stay internal to your team.
Only Audit Title and Audit Type are required. Click Create Audit to save. The form notes before you save that your auditor works in a separate portal with clean-gated downloads: creating an audit starts an exchange with an outside party, not just a record.
Find your way around
The module has three tabs. Dashboard is the roll-up view across engagements. Engagements is the working table — search matches title, firm, or description, and the status and type filters narrow the list. My Assignments shows only the evidence requests assigned to you, which is the tab most of your team will live in.
Clicking an engagement row expands its working panel. From top to bottom it holds Framework readiness, the Coverage rollup, the evidence request table, Shared audit workpapers, Reviewed delivery records, Shared finding follow-ups, the Evidence Freeze and Evidence Packages controls, and External Auditor Access with the Auditor activity log. The workpapers, delivery records, and follow-ups are read-only on your side: your auditor writes them in the portal.
Build the request list
Evidence requests are the unit of work: each one names a thing the auditor needs, and the engagement is done when they are all accepted. Three ways to build the list:
- Generate requests from the framework panel — one request per applicable control of the scoped framework, in a click. Controls with an approved "not applicable", "scoped out", or "retired" disposition are skipped. New requests are Pending and unassigned, and clicking the button again only adds requests for controls that do not have one yet. The readiness meter then tracks how many applicable controls have accepted evidence.
- Import PBC — bulk-load the provided-by-client list your auditor sent, as a CSV, XLSX, or PDF file of up to 10 MB. In Route imported PBC requests, give each row a category, an owner, its applicable business units, and an evidence rule before you create the requests, so set the audit scope first (see below). Imported requests start as Assigned to the owner you chose. They carry the control reference as text, so they do not count toward the readiness meter.
- Add Request — one at a time, for anything else.
Use them in any order. If a row in an imported PBC list carries a reference another request in the audit already uses, the import preview gives it the next free number and keeps the file's reference in its description, so nothing in the list is dropped. Rows an earlier import of the same list already created are listed and left out.
Auditors can also raise requests themselves from their portal once invited, so the list stays live during fieldwork.
Assign, attach, track
Assign each request to an owner — it appears in their My Assignments tab. Assigning an owner does not change the request's status.
Owners answer a request by attaching evidence from the Evidence Library or by uploading a file. Only evidence that has been sealed for release can be attached, and files uploaded straight into a request are sealed for you. Evidence already linked to the request's control is not attached automatically: the owner attaches it. Attaching evidence moves the request to Submitted.
The auditor then marks the request Accepted or Rejected in their portal. Your team can also set either status with Change Status on the row, or with the bulk Accept and Reject buttons, which is how you record decisions when the auditor is not using the portal. A rejection carries a reason, and the request goes back to its owner, who can move it to In Progress and attach something better.
Two progress signals tell you where the engagement stands:
- The fulfilled/total bar on the engagement row — requests accepted versus requested.
- The framework readiness meter in the expanded panel — applicable controls with accepted evidence, including how many are requested and still awaiting.
Scope by business unit
If your organization has business units and the audit covers only some of them, click Set audit scope and choose the units. The selection is saved with the audit, even if your organization's structure changes later. Each requirement then gets an evidence rule: Shared evidence (one answer covers every unit) or Evidence per business unit. Use Route coverage on a row to set the units a requirement applies to.
A scoped audit shows a Coverage rollup above the request table, with Audited units, Submitted, Accepted, and Missing. Requests in a scoped audit are answered through Add evidence, where you pick sealed items or upload files, map each one to the units it covers, and click Submit for review. Requests without unit routing use Manage evidence instead, which attaches evidence directly.
Advance the status
As phases complete, move the audit forward from the row's actions menu: Planning → Collecting Evidence → In Review → Submitted → Completed → Closed. Each step can also go one step back, so reopening for auditor follow-ups doesn't require deleting anything.
A frozen audit cannot be deleted. Unfreeze it first — with a recorded reason — if you genuinely need to remove it.