Deviations: every screen, column and action

A deviation is a decision not to fix something, recorded with an approval chain and an expiry. The module is mostly about who agreed and until when.

The deviation list

Column	What it holds
Risk Acceptance ID	The request identifier
Risk Acceptance Details	Subject and reason
RA Type	Which vulnerability types the acceptance covers — AppSec, VA, PT, Posture or RLCM
Initiator	Who raised it
Approved By	Who has approved so far
Pending On	Whose approval it is waiting for
End Date	When the acceptance expires

Row actions

View History, Update Initiator, Delete Risk Acceptance.

Update Initiator exists because acceptances outlive people. When the person who raised one leaves, the request would otherwise be pending on an account nobody uses — this reassigns it without restarting the approval chain.

RA Type spans modules, which is why the module sits outside them

One acceptance can cover AppSec, VA, PT, Posture and RLCM findings together. That is deliberate: a decision to accept a risk is usually about a system, not about which scanner happened to find it.

It also means a finding can be under an acceptance raised from a module you are not looking at, which is the usual reason a finding shows as accepted with no visible acceptance in its own module.

Approval configuration

Screen	Columns
Approval levels	Approval Levels, Approval Type, User Type, Updated By, Updated On
Approver configuration	Approval Levels, User Type, Approver Name, Status, Updated On, Comments
Designations	Designation Type, Users, Created By, Created On

Approval is by level, and each level is satisfied by a user type or designation rather than by a named person. That is what lets the chain survive staff changes: a level requiring "Head of Infrastructure" is satisfied by whoever currently holds it.

Comments on the approver configuration record why a level was added or changed, which matters when an auditor asks who authorised the authorisation structure.

Deviation properties

Property Name, Property Type, Mandatory, Info Hint, Sequence, Created By.

Info Hint is the help text shown beside the field when someone raises a request. It is the cheapest place in the product to prevent bad requests — a mandatory "compensating control" field with a hint explaining what counts as one produces usable answers, and without the hint produces "N/A".

Raising a deviation

The request form lists the findings being accepted:

Column	What it holds
vulVid	The finding's identifier
Observation	What was found
Recommendation	What was advised
Vulnerability Name and Status	The finding and its status at the time the deviation was raised
Audit Name	Where it came from
Asset Name	What it affects

The status shown is historical, not current

The product states this on the screen itself: the status is the state of the vulnerability when the deviation was raised. A finding accepted while New still reads New on the acceptance months later, even if it has since moved.

Read the finding's own screen for its current state. Reading the acceptance instead is the most common misinterpretation in this module.

Generate PDF Report produces the acceptance as a document — the artefact an auditor asks for, showing what was accepted, by whom, on what grounds and until when.

Bulk upload

Accepts CSV or XLSX, and covers APPSEC / VA / PT / POSTURE or RLCM — the two groups are uploaded separately because their identifiers differ.

The queue reports Status, Initiated By, Uploaded At, Download and Log File Download. The log is the per-row outcome; a bulk upload that accepted fewer findings than expected explains itself there.

Validated and expired vulnerabilities

Both tables carry the full provenance of each finding:

Track ID, VID, Org, Business, Project, Application, App Code, Application Type, Audit, Audit Type, Audit Cycle, Audit Created On, Audit Completed On, Audit First Reported On, Vulnerability Name, Severity, Risk Acceptance Expiry Date, Expired On.

Risk Acceptance Expiry Date is the date the acceptance runs out — it was labelled Risk Acceptance Date in earlier releases, which read as the date it was granted. The value is unchanged; only the label is, and it now says what it always meant. Reports and the health-check rules that test it use the same wording.

Because an acceptance can cover findings from any module, the tables also carry the identifiers each module uses:

Column	Applies to
Tools	Which scanner reported the finding
QID / NEXPOSE ID / NESSUS ID	The scanner's own identifier — Qualys QID, Nexpose or Nessus id
Host, Port, Protocol	Network findings, where the acceptance is per service rather than per machine
Category	The finding's classification
Policy Name, Control Name	Policy Compliance findings, where the acceptance is against a control

The scanner identifier is what makes an acceptance verifiable. An auditor checking that an accepted finding is the one described will look it up by QID or plugin id in the scanner, not by the title — titles get rewritten, identifiers do not.

Audit First Reported On is the one that matters for an expiry dispute. It is when the finding was first raised, which may be several audits before the acceptance — so an acceptance expiring after six months can cover a finding that has been open for two years.

The expired list is the module's most actionable screen: those acceptances have lapsed, so the findings are open again and, unless someone is watching this list, nobody has been told.

Vulnerability status history

Audit ID, Audit Name, Severity, Vulnerability Status, Sub Status, Created On, Status Changed By.

Sub Status carries the qualifier beneath the main status — which kind of acceptance, or which stage of an approval. Two findings both reading Risk accepted can differ in sub status, and that is what distinguishes a permanent acceptance from a temporary one.

Vulnerability summary

Assets, Critical, High, Medium, Low, Info — what an acceptance covers, at a glance, before approving it. An approver looking at a request for forty findings across twelve assets is being asked a different question from one looking at a single Low.