Prioritising with business context

Why this matters

No organisation remediates everything. Capacity is finite, the backlog grows faster than it shrinks, and the real question is never "how do we fix it all" but "what do we fix first, and what do we consciously leave".

The previous lesson narrowed the field with severity and exploitability. This one adds the part only you can supply: what the asset is worth, who can reach it, and what already protects it. The exam tests whether you can combine those rather than sorting by score — and in practice it is the difference between a programme that reduces risk and one that produces reports.

The lesson

Asset criticality and data sensitivity

A vulnerability's importance depends heavily on what it is a vulnerability in.

Criticality is usually assessed on a few axes:

• Business process dependency. What stops if this asset stops? A payment system, a clinical system or a production line has consequences a wiki does not.
• Data sensitivity. Personal data, health records, card data, credentials, intellectual property, or nothing much. This drives both impact and regulatory consequence.
• User population. A system used by every employee is a better foothold than one used by three.
• Connectivity. An asset that can reach many other systems — a jump host, a management server, a CI/CD pipeline — is worth more to an attacker than its own data suggests. CI/CD in particular is frequently under-rated and holds credentials to everything it deploys.
• Recovery difficulty. Something rebuildable in an hour from code is a different proposition from a bespoke system nobody understands.

The practical problem is that criticality has to come from the business, and asking three hundred system owners to rate their own systems reliably produces three hundred "critical" answers. What works better:

• Derive it where possible: from data classification already assigned, from disaster recovery tiers already agreed, from whether the asset is in scope for a regulatory audit.
• Force a distribution. If everything is tier one, nothing is.
• Attach it to the asset record, per lesson 18, so it flows automatically into every finding rather than being rediscovered each time.

Internet exposure as a multiplier

Of all the context available, exposure is the one that changes urgency most sharply, and it is the easiest to determine objectively.

The reasoning is simple. Mass exploitation is opportunistic: attackers scan the entire internet for a newly disclosed vulnerability and exploit whatever answers. An exposed system is found within hours of a scan sweep. An internal system with the same flaw requires the attacker to already be inside, which is a much higher bar and usually means you have a different problem too.

So exposure should be a first-class field, and it needs to be verified rather than assumed. The asset record's claim that something is internal is regularly wrong, because of:

• a firewall rule added for a project and never removed,
• a cloud security group opened to 0.0.0.0/0,
• a load balancer or reverse proxy publishing something unintentionally,
• a misconfigured DNS record pointing outside,
• an asset moved between segments without the record updating.

The reliable check is an external scan from the internet, per lesson 17, and comparing its results against what the inventory claims is exposed. The difference is a finding in itself, and often a more urgent one than the vulnerabilities it contains.

Related and worth the same treatment: reachability from a compromised workstation. The lateral-movement question from lesson 3. A vulnerability reachable from every desktop is far more urgent than one reachable only from a locked-down admin segment.

Compensating controls that genuinely compensate

A compensating control reduces risk without removing the vulnerability, and it legitimately lowers priority — when it is real.

Controls that genuinely compensate:

• Network isolation that actually prevents reachability from where an attacker would be. Verified, not assumed.
• A WAF rule that blocks the specific exploit, tested against the actual payload rather than switched to "high security" and hoped over.
• Multi-factor authentication in front of a service whose vulnerability requires authentication.
• Disabling the vulnerable feature, which is close to remediation.
• Detection with a tested, rapid response, which does not prevent but bounds the damage — and only counts if someone actually responds at the hour it would fire.

Controls that are frequently claimed and usually do not compensate:

• "It's behind the firewall." Almost everything is behind a firewall. This says nothing about who can reach it.
• "The EDR will catch it." Possibly. Lesson 11 covered the evasion and coverage gaps, and an untested claim is a hope.
• "It requires authentication." True until the credential-stuffing lesson says otherwise, and irrelevant against an insider or a compromised account.
• "It's a legacy system nobody uses." If nobody uses it, decommission it. A system too unimportant to patch and too important to switch off is usually neither.
• "We haven't seen any attacks against it." Absence of detection, as this course keeps saying, is not evidence of absence.

The test to apply, and a good exam answer: does the control break the specific attack path this vulnerability creates, and has anyone verified that it does? An unverified compensating control is a deferral with better vocabulary.

Service-level objectives for remediation

SLAs turn prioritisation into something measurable and enforceable.

A conventional structure ties the deadline to severity and exposure:

What makes them work rather than decorate a policy document:

• Agreement from the teams who must meet them, not imposition by security. An SLA nobody agreed to is a stick, and it gets ignored or gamed.
• Achievability. An SLA routinely missed by everyone teaches the organisation that SLAs are aspirational, which then applies to the one that mattered.
• A defined clock start — discovery date, not ticket date, or the measure can be improved by being slower to raise tickets.
• An exception process that is real, documented and time-bounded, because without one the pressure goes into not recording findings.
• Reporting against them by owner, which is where Domain 4 picks this up.

Emergency handling belongs here too: a critical, actively exploited, internet- facing vulnerability is not an SLA matter but an incident, and should use the incident process from Domain 3 — including its authority to bypass normal change control.

Explaining a deferral so it survives an audit

Most findings will not be fixed in their SLA window, and the difference between a mature programme and a negligent one is entirely in how the exceptions are handled.

A deferral that stands up to scrutiny records:

1. The finding, specifically — which vulnerability, which assets.
2. Why remediation is not being performed now: vendor has no patch, fix breaks a dependency, system is in a change freeze, patch requires downtime the business will not approve.
3. What compensating controls are in place, and the evidence they were verified.
4. The residual risk, stated in business terms rather than as a CVSS score.
5. Who accepted it — a named individual with the authority to do so. Not the security team, per lesson 1.
6. An expiry date, after which it returns for review. Permanent exceptions are how organisations accumulate undocumented risk.
7. The date and the review history.

Why this matters beyond bureaucracy: after an incident, the question is never "did you know about this vulnerability?" — the logs will show you did. It is "what did you do about it?" A documented, reviewed, owned acceptance with compensating controls is a defensible answer. A finding sitting open for eighteen months with no record is not, and the absence of a decision reads as negligence even where the decision would have been reasonable.

Which is the through-line of this entire domain, and the reason the reporting lessons exist: the work only counts if the reasoning behind it survives in a form somebody else can read.

Topics this lesson owns

• [x] Asset criticality and data sensitivity
• [x] Internet exposure as a multiplier
• [x] Compensating controls that genuinely compensate
• [x] Service-level objectives for remediation
• [x] Explaining a deferral so it survives an audit