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
| You want to… | Use… |
|---|---|
| Respond to an “auditor asked for X” item | Audit Requests |
| Track a finding you have to remediate | Compliance Issues |
| Capture a quarterly access-review attestation | Access Reviews |
| Define the audit window, scope, and Type 1/2 | Audit Periods |
Request types
| Type | What it represents | Typical evidence |
|---|---|---|
| Document | A policy, contract, log export, screenshot, signed acknowledgment | Files or links attached directly to the request |
| Test | A control test result — e.g. “show me 5 randomly sampled new-hire access reviews from Q1” | Linked test results + sampling notes |
| Observation | The auditor needs to watch the control operate (live screen share, walkthrough recording) | Calendar invite + recording link |
| Inquiry | A question the auditor wants answered in writing | Reply text + supporting attachments |
Status workflow
Every request moves through a five-state machine. Three are working states; two are terminal.| Status | Who sees it | What it means |
|---|---|---|
| NOT_READY | Operator only | Just created; the owner is still gathering evidence. Auditor cannot see the request. |
| INTERNAL_REVIEW | Operator only | Evidence is attached; a second person on the customer side is checking it before sharing. Still hidden from the auditor. |
| AUDIT_READY | Operator + auditor | Visible to the auditor through their token-scoped portal. Auditor reviews; their decision is the next status. |
| APPROVED | Operator + auditor | Terminal accepted state. The auditor signed off and the request is closed. |
| FLAGGED | Operator + auditor | Auditor needs more or different evidence. The request loops back to the operator with the auditor’s comment as the reason. |
Cadence (recurring requests)
Requests can be one-time or recurring:| Cadence | Use case |
|---|---|
| ONE_TIME | The default — “show me the most recent BCP test result” |
| MONTHLY | Continuous-monitoring evidence — “monthly user-access review attestation” |
| QUARTERLY | Quarterly access reviews, change ticket samples |
| ANNUAL | Annual penetration test, annual policy review attestation |
Creating a request
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.
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.
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.
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.
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
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
| Transition | Who can trigger |
|---|---|
NOT_READY → INTERNAL_REVIEW | Owner or any compliance team member |
INTERNAL_REVIEW → AUDIT_READY | Compliance Admin / Compliance Officer (the “second pair of eyes” role) |
INTERNAL_REVIEW → NOT_READY | Same — sends it back to the owner with comments |
AUDIT_READY → APPROVED | The external auditor through their portal |
AUDIT_READY → FLAGGED | The external auditor through their portal |
FLAGGED → NOT_READY or INTERNAL_REVIEW | Operator side — restart the loop with whatever the auditor asked for |
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
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
What's the difference between a FLAGGED request and a Compliance Issue?
What's the difference between a FLAGGED request and a Compliance Issue?
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.
Can I bulk-import an IRL from a spreadsheet the auditor sent me?
Can I bulk-import an IRL from a spreadsheet the auditor sent me?
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.
What happens to a recurring request when the audit period ends?
What happens to a recurring request when the audit period ends?
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.
Can the auditor see who on my team uploaded each piece of evidence?
Can the auditor see who on my team uploaded each piece of evidence?
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.
A request was approved by the auditor. Can I edit it?
A request was approved by the auditor. Can I edit it?
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.