RLCM: support reference¶
Internal. The customer-facing explanation is in the screen reference and Configuring risk.
RLCM is a control-assessment module rather than a vulnerability module, and it has a three-role review model nothing else in the product uses. Almost every ticket is a question about whose turn it is.
Compliance and TPRM are the same screens¶
Internal compliance audits and third-party (TPRM) audits share their control-status and risk screens. The audit's type decides which set of controls is loaded and which breadcrumb appears.
Two practical consequences:
- A caller describing "the audit status screen" may be on either. Establish the audit first.
- A screenshot or a link taken from one looks identical to the other. Compare the audit name, not the screen.
The three roles¶
A control passes through a POC who answers it, a reviewer who accepts or returns it, and an approver. Pending On names whose turn it is, and it is the answer to most "nothing is happening" tickets.
An audit can be configured with the reviewer step disabled. Where it is, controls move straight from POC to final state, and a customer expecting a review stage that never appears has that configuration rather than a defect.
Mandatory answer, comment and evidence¶
Each control can independently require an answer, a comment and evidence. These are enforced at save time rather than announced beforehand, so the usual report is "it will not let me submit" with no visible reason.
Check the control's own requirements before treating it as a bug. The same audit can have controls with different requirements.
Status flags decide behaviour¶
Statuses are configured per deployment, and four flags on each decide what it does:
| Flag | Effect |
|---|---|
| Comment Required | Will not save without one |
| Auditor Required | Needs an auditor assigned before the status can be set |
| Evidence Required | Needs an attachment |
| Closed Type | Whether it stops the item counting as open |
| Is Exception | Marks an agreed exception rather than a resolution |
Is Exception is the one that matters for reporting: it separates "we fixed it" from "we agreed not to". A customer whose compliance percentage looks too good may be counting exceptions as closures.
If a customer's counts behave unlike this documentation, their configured statuses are the first thing to read — the flags are data, not fixed behaviour.
CCF frameworks: what cannot be changed, and what the percentage means¶
- System Framework and System Requirement rows are shipped with the product. Edit and Delete are absent on them by design; a caller asking to correct one should be told to add their own framework alongside rather than raise a defect.
- Compliance % on the framework list is mapping coverage — requirements with at least one mapped control, over all requirements. It is not an assessment result and does not move when controls are answered. A customer reading it as "we are 80 % compliant with ISO 27001" needs the distinction made before it reaches an auditor.
- A CSV upload that "did nothing" almost always failed row validation. Requirement
Upload Logs on the requirements screen records each run with what was rejected and
why; read that before re-uploading. The reference ID has the same character rule as the
framework's: letters, numbers and
. _ -. - The Validity period and Warning period on a framework drive expiry warnings on the framework, not on its assessments. A framework showing as expiring is a framework due for a review of its own version, not a failing audit.
AI evidence analysis: three states, one configuration screen¶
The AI Evidence Analysis Status on an assessment is one of:
| Shown | Means |
|---|---|
| pending | Queued, or waiting for the next scheduled run, or held back by the per-audit cost cap |
| a score out of 100 | Analysed; the score is the platform's confidence in the finding it suggests |
| failed | The evidence could not be read; the reason is on hover |
Everything that decides whether it runs at all is on System → AI Configuration: the provider and credential, the model, the schedule interval, the Per-Audit Cost Cap, and whether analysis is switched on for Compliance and TPRM. If that screen shows AI service not configured, nothing will ever leave pending, and the fix is the administrator's, not the auditor's.
AI Queue Details on the same screen lists every analysis queue with its status and a Re-analyse this queue action. A stuck pending that survives the next scheduled run is worth re-analysing once before escalating; a failed that repeats on the same evidence is usually the evidence — an image with no readable text, or a file the extractor cannot open.
The evaluation is advisory. It writes no answer, changes no status and is not counted in any report; the auditor's input remains the only input. A customer who wants the score to be the answer is asking for something the product deliberately does not do.
UCF mapping¶
Controls map to framework entries through the Unified Control Framework. One control can belong to several frameworks, which is the point: answering it once satisfies each of them.
A control appearing in several framework reports is not duplicated data.
Evidence lives in two places¶
- On the control, as the answer's supporting attachment.
- On the status history, as the justification recorded when someone changed the state.
They serve different audiences — the first is what the assessor asked for, the second is what an auditor asks for later.
What to collect before escalating¶
- The audit name and type — compliance or TPRM.
- The control's reference and its Pending On value.
- Whether the audit requires a reviewer.
- For "cannot submit": which of answer, comment and evidence the control requires.
- For counting disputes: which statuses the deployment marks as closed type, and which as exceptions.