Severity is an argument, not a label
Two deficiencies land on the same audit report with the same rating. The first: an access review that missed one contractor account for eleven days before the control owner caught it internally. The second: an encryption control that had never been tested, affecting a data store holding regulated records, with no compensating control in place and no one certain when the gap began. Both rated "moderate." Neither rating holds under scrutiny, and that is the problem this piece addresses.
Severity is a conclusion you have to earn. Without a documented rubric, the rating becomes a negotiation — shaped by whoever in the room is most confident, most senior, or most motivated to minimize findings. That is not risk management. It is politics with GRC branding.
The absence of a scoring matrix is not a technical failure. It is a judgment deficit. The correction is not to adopt a universal scoring scheme — that trades one kind of arbitrariness for another — but to build a defensible argument from inputs that are each individually evidenced. A severity rating that cannot be reconstructed from its inputs cannot be defended to an auditor, a regulator, or a board.
What the failure period actually exposed
The duration of a control failure is one of the most consequential severity inputs, and it is frequently treated as a formality. A control that failed for two weeks and a control that failed for two years are not the same finding, even if the control description is identical.
Duration determines exposure window. The longer a control was absent or ineffective, the larger the population of transactions, records, or users that may have been unprotected. That is a factual expansion of scope, not an interpretation. Whether the expanded scope produced an adverse outcome is a separate question — but scope itself is a severity input that belongs in the argument.
The practical question is whether you can bound the failure period at all. Evidence collection infrastructure (covered in GRC-AUDIT-002) may give you log timestamps, change records, or prior test results that anchor a start date. If that infrastructure was in place and functioning, the failure period is bounded. If it was not, or if prior tests were not run on a defined cadence, the start date is unknowable from internal records — and that matters for how you rate the finding.
Likelihood and magnitude without a scoring scheme
In the absence of a numeric rubric, two questions carry the argument: how likely was it that the failure produced an adverse outcome, and how large would that outcome have been?
Likelihood is not a guess. It is an assessment grounded in: whether the control was a preventive or detective control; whether there were other controls operating over the same risk; what threat activity was present or plausible in the environment during the failure period; and whether the asset protected by the control was actively targeted. A preventive control that failed in an environment with active threat activity and no detective backup presents a higher likelihood than the same failure in an environment with layered controls and no known threat exposure.
Magnitude is the population and consequence of the protected asset. Regulated records, financial data subject to PCAOB AS 2201 material-weakness thresholds (Source: PCAOB AS 2201, https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201), and high-privilege identity stores each carry different consequence weights. COSO's integrated framework treats the effectiveness of any component as contingent on all five components operating together (Source: COSO Internal Control—Integrated Framework, https://www.coso.org/guidance-on-ic) — which means a single control failure in a thin control environment carries more weight than the same failure in a dense one.
Neither of these assessments requires a scoring matrix. They require documented inputs and a written rationale that connects the inputs to the conclusion.
When the failure period cannot be bounded
This is the honest section. An unbounded failure period is not an administrative inconvenience. It is a severity input — and depending on the control and asset, it may be the most material one.
When you cannot establish a start date for a control failure, you cannot claim a bounded exposure window. That means you cannot argue limited scope. The correct framing is: the failure period is unknown, the evidence available does not allow it to be bounded, and the rating reflects that condition.
In many environments, an unbounded failure period — particularly on a preventive control over a sensitive asset — supports a higher severity rating than the same failure with a known two-week window, even if no adverse outcome is confirmed. The absence of evidence of harm is not evidence of absence of harm.
Document the unbounded condition explicitly. Note what evidence was examined, why it did not establish a start date, and what that uncertainty means for the rating. That documentation is itself an audit artifact. An auditor reviewing the finding can then assess whether your rating appropriately reflected the uncertainty — or whether you rated it lower because bounding the failure period was inconvenient.
NIST SP 800-53A Rev. 5 defines depth and coverage as attributes applied across examination, interview, and test methods (Source: NIST SP 800-53A Rev. 5, https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final). An assessment that cannot establish coverage of the failure period — because evidence was unavailable or collection was not in place — is an assessment with a known coverage limitation. Coverage is the breadth across which a method was applied; depth is its rigour. That limitation belongs in the severity argument, not in a footnote.
Compensating controls and what they do to severity
A compensating control reduces severity when it was operating, was tested, and demonstrably covers the risk exposed by the primary control failure. It does not reduce severity by existing on paper.
The relevant questions are: Was the compensating control active during the failure period? Was it tested during the failure period, or is the assertion of its effectiveness based on a prior test cycle? Does it address the same risk vector, or does it address an adjacent risk that happens to share a control description?
Note that compensating-control testing methodology in an assurance context — determining whether a compensating control actually performed its function — is held for a forthcoming asset and is not covered here. For vulnerability exposure paths specifically, VEM-VERIFY-002 Component 4 owns compensating-control validation, but that scope is limited to exploitation attempts and exploitability assessment. Do not extend it to control assurance contexts.
Where a compensating control is claimed as a severity-reducing factor, the documentation should state the control, the test basis, the test date, and the specific risk element it covers. A claim that a compensating control "was in place" without a tested basis during the failure period does not meet that bar and should not reduce the severity rating. It may still be worth recording as a mitigating circumstance for the remediation discussion, but an untested control is an assumption about coverage rather than evidence of it.
Comparability across controls
A severity rating has to mean the same thing across different control types. That is harder than it sounds when ratings are assigned in separate conversations by different people with no shared rubric.
A "high" finding on an access control and a "high" finding on an encryption control should reflect comparable underlying conditions: similar failure duration, similar population exposure, similar likelihood of adverse outcome, and similar absence of effective compensating controls. If the conditions differ substantially, the ratings should differ — or the rating scale needs a documented explanation of why it treats them equivalently.
Comparability matters for prioritization. Remediation capacity is finite. If severity ratings are not comparable across controls, the remediation queue is not prioritized on risk — it is prioritized on whoever assigned the highest rating most recently.
GRC-FOUND-002 covers the control inventory and ownership model that underpins consistent assignment. The comparability problem is not solved by ownership — but without clear ownership and a shared set of severity inputs, comparability is close to impossible.
What a severity rating does not decide
Severity is not the same as remediation priority. It is an input to priority, not the output.
Remediation priority also incorporates: current threat environment, remediation cost and complexity, regulatory deadline pressure, and the presence of interim controls that reduce live exposure. A high-severity historical finding with a bounded failure period and a confirmed absence of recurrence may rank below a moderate-severity finding that is actively recurring and undetected by the control system.
Severity also does not decide whether a finding is reported externally. Reporting thresholds are set by regulatory frameworks, contractual obligations, and organizational policy — not by internal severity ratings alone. Under PCAOB AS 2201, the material-weakness and significant-deficiency designations carry specific reporting consequences for issuers subject to integrated audit requirements (Source: PCAOB AS 2201, https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201). Internal severity labels that do not align with those framework definitions create audit-trail conflicts when external reviewers compare internal documentation to reported findings.
GRC-COMPLY-002 owns crosswalk design between internal severity frameworks and external reporting obligations. If your internal rating system does not have an explicit crosswalk to the frameworks under which you report, that gap is itself a governance finding.
Severity argument table
| Input | What it establishes | How it is evidenced | What weakens it | Effect on the rating |
|---|---|---|---|---|
| Failure duration | How long the objective went unmet | Control execution records, system logs, change history bounding the start and end | An unbounded start date — "at least since the last review" is a floor, not a duration | Longer exposure raises severity; an unbounded period must be argued at its plausible worst, not its convenient best |
| Population affected | How much of what the control governs was exposed | Scope of the control against the records or systems in the failure window | A population the tester cannot enumerate, so the affected share is unknown | Wider share raises severity; an unenumerable population is itself a severity input |
| Detection source | Whether the control environment noticed, or something outside it did | Ticket, alert, or monitoring record showing who identified the failure and when | Discovery during the test itself, which tells you nothing about detection capability | Externally or accidentally discovered failures raise severity: the surrounding controls did not catch it |
| Adverse outcome | Whether the exposure was realised, not merely possible | Incident records, access logs, or downstream evidence covering the failure window | Absence of evidence is not evidence of absence where logging did not cover the period | A realised outcome raises severity sharply; no evidence of one does not lower it below the exposure argument |
| Tested compensating control | Whether another control demonstrably covered the risk during the failure window | A contemporaneous test result for the compensating control, covering the same period | A control that was "in place" but untested during the window — an assumption about coverage, not evidence of it | A tested and covering control lowers severity; an untested one does not |
| Recurrence | Whether this is an isolated lapse or a pattern | Prior findings against the same control, owner, or objective | A finding history that only goes back one cycle, so recurrence cannot be ruled out | Recurrence raises severity and shifts the question from operation to design |
The severity test
Before any severity rating is finalized, it should survive four questions without deflection:
Can you state the failure period, or explain in writing why it cannot be bounded? If the answer is neither, the rating is not ready.
Can you name the population affected and describe how you estimated it? A rating that does not account for population scope is a rating built on an incomplete argument.
Can you describe the likelihood of an adverse outcome using the conditions present during the failure period — not conditions in general? General likelihood assessments are not arguments. Specific ones are.
If a compensating control was claimed, can you cite a test of that control during the failure period? If not, document the gap and reflect it in the rating.
These questions are not a scoring rubric. They are the floor of a defensible argument. An engagement team that can answer all four in writing has produced a rating that can be reviewed, challenged, and updated as conditions change. A team that cannot answer them has produced a label — and a label does not hold when the finding is escalated, reported, or disputed.
The audit trail for severity decisions should include: the inputs considered, the evidence cited for each, the rationale for the weight given to each input, and the names of the people who made the judgment. That is not bureaucratic overhead. It is the difference between a rating that can be explained and one that has to be defended without evidence.
Sources
- PCAOB AS 2201: https://pcaobus.org/oversight/standards/auditing-standards/details/AS2201
- COSO Internal Control—Integrated Framework: https://www.coso.org/guidance-on-ic
- NIST SP 800-53A Rev. 5: https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final
