Skip to main content
The Audit Requests module is Regentra’s Information Request List (IRL) workflow — the inbox-style queue auditors and operators use to work through every “send us X” ask during a fieldwork window. Each request is a discrete piece of evidence collection with a status, an owner, a deadline, and an audit trail.

​
Finding it in the sidebar

Open the Compliance module and click Audit Requests in the left sidebar. Direct URL: /compliance/audit-requests. The Compliance sidebar is long. Audit Requests sits below the controls section under a small uppercase caption that reads EVIDENCE & REPORTING — the caption is a visual divider, not a clickable group. The siblings under the same caption are Control Tests, Audit Periods, Issues, Reports, Evidence Collection, Questionnaires, and Audit Trail. If you can’t see Audit Requests at all, you’re probably in the PSA module — switch to Compliance in the top-left module switcher.

​
When to use this vs. compliance issues

Audit Requests live underneath an Audit Period, and an individual request may pull evidence from any of the others. They are the operational surface for “what does the auditor want next?”

​
Request types

​
Status workflow

Every request moves through a five-state machine.
The “INTERNAL_REVIEW before AUDIT_READY” step is the same idea as PR review on a code change — your second pair of eyes catches “this screenshot has another customer’s name in it” before the auditor sees it. It is optional but strongly recommended. A FLAGGED request is not a finding. It is a retry — the auditor said “that’s not quite what I asked for; try again” and the customer can push it back to AUDIT_READY (or INTERNAL_REVIEW first) and continue. Findings live on Compliance Issues.

​
Cadence (recurring requests)

Requests can be one-time or recurring: Cadence is a tracking field you set when creating or editing a request — it labels how often the ask recurs (e.g. “this is a monthly attestation”) so your team knows to expect it again. The app does not currently auto-generate a new request each cycle; when the next instance comes due, create it yourself (or reuse the CSV import for a batch of recurring asks).

​
Creating a request

1

Open Audit Requests

Compliance → Audit Requests in the sidebar, then click New request.
2

Link to an audit period (recommended)

Pick the audit period this request belongs to. The period scopes deadlines against the audit window so dashboard counters are accurate. Leave blank for internal prep work outside any active audit.
3

Optionally tag the auditor invite

If the request came from a specific external auditor, link their invite. The request will become visible in that auditor’s portal once it reaches AUDIT_READY.
4

Capture the request metadata

  • External ID — the auditor’s reference (e.g. IRL-042). Not unique in Regentra because the same code may recur across audits.
  • Title + Description — what the auditor wants.
  • Type — Document, Test, Observation, or Inquiry.
  • Cadence — one-time or recurring.
  • Owner — the operator responsible for gathering the evidence.
  • Due date — for SLA tracking.
5

Link controls (optional but high-value)

Tag every internal control the request evidences. Linking controls means the same evidence shows up on the control card, in the evidence map, and on cross-framework reports — without a second upload.
6

Save in NOT_READY

The request lands in the NOT_READY column. The owner is notified.

​
Supporting a request

A request doesn’t hold its own file uploads. Instead, put the context the auditor needs into the Description field, and link every internal control the request evidences — that’s what ties the request to your compliance record and to Evidence Collection for that control. Use comments (below) to add updates, links, or notes as you work the request.

​
Comments and the back-and-forth

Each request has a comment thread visible to both sides once the request is AUDIT_READY. Internal comments (visible only to the customer side) are also supported for the back-channel “is this the right version?” conversation that should not be in the auditor view. The thread is preserved when a request is FLAGGED → re-attached → pushed back to AUDIT_READY, so the auditor sees the full history of the loop.

​
Status transitions and who can drive them

The auditor never directly authors evidence; they only approve or flag what’s been shared. This separation is what makes the audit trail defensible.

​
What the auditor sees

External auditors interact with Audit Requests through their token-scoped portal at /audit/{token} — they never receive a login to the main Regentra app. Through that portal they can:
  • See every request currently in AUDIT_READY, APPROVED, or FLAGGED (NOT_READY and INTERNAL_REVIEW requests are hidden — they’re customer-side prep)
  • Read the request’s description, linked controls, and any evidence already linked to those controls
  • Comment on a request
  • Approve the request, or flag it with a note explaining what’s needed
  • Download the org’s portal-scoped CSV exports (controls, policies, vendors, incidents, training, risk assessments) and the full audit-package ZIP
The audit-package ZIP they download is the same artifact your team can generate from the admin side (the Export Audit Package button on the Reports page), scoped to the auditor’s token.

​
Status dashboard

The Audit Requests page surfaces a Total count plus a count tile for each of the five statuses (NOT_READY, INTERNAL_REVIEW, AUDIT_READY, FLAGGED, APPROVED); clicking a tile filters the list below to that status. A search box filters by title, external ID, owner, or linked control.

​
Frequently asked questions

A FLAGGED request means “auditor wants different evidence” — you iterate inside the request. A Compliance Issue means “auditor found something wrong with the control itself” — you remediate the underlying control, then evidence that remediation in a separate request.
Yes. Click Import CSV on the Audit Requests page and upload a CSV with external_id, title, type, description, owner_email, due_date, evidence_capture_date, cadence, and framework_codes columns (header row required, 500-row cap). You can optionally link the import to an auditor invite. Rows with an unrecognized owner email or framework code still import, with a warning, so you can fix them afterward.
It’s a label — ONE_TIME, MONTHLY, QUARTERLY, or ANNUAL — that records how often this ask recurs, for your own team’s tracking. It does not create the next cycle’s request automatically; when it’s due again, create (or re-import) a new request.
Yes. Every comment shows the author’s name and timestamp in the auditor portal (unless it’s marked internal-only, which hides it from the auditor entirely) — that’s part of what makes the audit trail defensible.
The title, description, owner, and other fields can still be edited after approval. The auditor can also reopen an APPROVED request back to FLAGGED if something needs revisiting. If a material change happened (a policy version, a new screenshot), it’s still good practice to note that in a comment so the change is on the record.