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. Three are working states; two are terminal.
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 add evidence, push it back to AUDIT_READY, and continue. Findings live on Compliance Issues.

​
Cadence (recurring requests)

Requests can be one-time or recurring: A recurring request automatically respawns a NOT_READY copy on its cadence so the owner can begin collecting next cycle’s evidence without the auditor having to re-issue the ask.

​
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.

​
Attaching evidence

Evidence is added inside the request:
  • Files — direct uploads (PDFs, screenshots, CSV exports)
  • Links — URLs to dashboards, monitoring tools, or live runbooks
  • Existing controls’ evidence — reference an evidence record that is already attached to a linked control (no second upload)
  • Existing test results — pull a control-test run directly into the request
Every attachment carries the uploader, timestamp, and a (server-side) hash, so even if the file is replaced later, the audit trail shows what the auditor saw at each status transition.

​
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)
  • Download attachments
  • Read the linked controls and their evidence
  • Comment on a request
  • Approve or flag the request
  • Download a per-request CSV and the full audit-package ZIP for the audit period
The audit-package ZIP they download is the same artifact your team can generate from the admin side, scoped to the auditor’s token. See the audit-package builder for the file inventory.

​
Status dashboard

The Audit Requests page surfaces five lanes (NOT_READY, INTERNAL_REVIEW, AUDIT_READY, APPROVED, FLAGGED) with counts and a list of requests in each. Filters: by audit period, by owner, by cadence, by type, by “overdue only”. A request is “overdue” when its due date is past and its status is NOT_READY, INTERNAL_REVIEW, AUDIT_READY, or FLAGGED — APPROVED requests never show as overdue regardless of their original due date.

​
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.
Not yet — bulk import is on the roadmap. For now, paste each row into a New Request form. The auditor’s External ID, title, and description fields are designed to mirror the columns of a typical IRL spreadsheet, so the data maps cleanly even when typed manually.
Recurring requests keep respawning on their cadence regardless of audit-period status — they’re tied to continuous monitoring, not a single window. Stop the recurrence by flipping the cadence to ONE_TIME on the most recent instance.
Yes. Every attachment shows the uploader’s name and timestamp in the auditor portal — that’s what makes the audit trail defensible. If you have a privacy concern, use a service account for sensitive uploads.
No — APPROVED is terminal and the attached evidence is locked. If something changes (a policy version, a screenshot), open a new request that supersedes the old one and reference the original in the description.