Security, Privacy and Compliance Risk Assessment Questions

Short answer. Before the control, expected annual loss is $3.65M; after it, $1.095M. The control saves $2.555M a year for $500k, so I would fund it, subject to checking the 70% claim and the $2M figure.

Terms. ALE (annualized loss expectancy) is the expected cost per year: the expected number of incidents per year (a rate, which can exceed 1, not the chance of at least one) times the cost per incident.

Computation

expected incidents per year (before) = 0.005 x 365 = 1.825
ALE before = 1.825 x $2,000,000 = $3,650,000

probability after = 0.005 x (1 - 0.70) = 0.0015 per day
expected incidents per year (after) = 0.0015 x 365 = 0.5475
ALE after  = 0.5475 x $2,000,000 = $1,095,000

risk reduction = $3,650,000 - $1,095,000 = $2,555,000
net benefit    = $2,555,000 - $500,000   = $2,055,000
benefit / cost = $2,555,000 / $500,000   = about 5.1

Net benefit is the loss the control removes minus what it costs; benefit / cost of 5.1 means each dollar spent removes about $5.10 of expected loss (anything above 1 pays for itself on paper).

Multiplying 0.5% by 365 gives the expected number of incidents, not the chance of at least one: the chance of at least one incident in a year is about 84% before and about 42% after.

Decision. Fund it. Residual loss is still $1.095M a year, so the control reduces risk, it does not remove it.

What would change my mind

• Break-even effectiveness: $500k / $3.65M is about 13.7%, so if the real cut is under roughly 14% the control does not pay for itself.
• Break-even incident cost: at 70% effectiveness, the incident cost would need to fall below about $391k before it stops paying.
• Whether 70% is evidence or a vendor claim: I would ask how it was measured and whether it covers the incident types that drive the $2M.
• Hidden costs: staffing, licences and integration beyond the $500k, and whether a cheaper control gets most of the cut.
• Risk appetite (how much loss the company is willing to carry): if the company cannot absorb a single $2M event, a lower expected value may still justify spending more.

Short answer. A pen test finding describes a technical flaw; business risk needs two more answers, how likely it is to be used against us and what it would cost. I rescore each finding on a fixed scale, show the arithmetic, and set remediation deadlines by the resulting band, agreed with leadership before the results are presented.

Why not rank by CVSS. CVSS (Common Vulnerability Scoring System, currently version 4.0) scores the severity of a flaw. It does not know the asset's value or whether the flaw is reachable. EPSS (Exploit Prediction Scoring System) estimates the probability a published vulnerability is exploited in the next 30 days. Use both as inputs, not as the answer.

Composite score (weights illustrative, agreed upfront):

likelihood = round(0.4 x exploit + 0.3 x exposure + 0.3 x control gap)   each 1-5
impact     = asset criticality 1-5 (data class, business function)
score      = likelihood x impact      Low 1-4, Medium 5-9, High 10-19, Critical 20-25

With both inputs on a 1 to 5 scale, the only possible products from 10 to 25 are 10, 12, 15, 16, 20 and 25, so "High 10-19" is the same set as the 10-16 band used on other 5x5 scales; no score of 17 to 19 exists.

• Exploit: how easily and reliably it is exploited (exploit maturity, a CVSS threat metric, means whether working attack code exists and how reliable it is; known exploitation in the wild, meaning attackers are already using it against real targets, scores 5).
• Exposure: internet-facing versus internal, authentication needed.
• Control gap: how little else stands in the way.

Dollar mapping. Likelihood levels 1 to 5 map to illustrative annual probabilities of 1%, 3%, 10%, 25%, 50%, and impact levels to loss of $50k, $250k, $1M, $5M, $20M. Expected loss is the product. Each band also carries a fix deadline (called an SLA, service level agreement, in the code): Critical 7 days, High 30, Medium 90, Low backlog.

# Likelihood = round(0.4*exploit + 0.3*exposure + 0.3*control_gap); Impact = asset criticality (1-5)
findings = [  # id, title, cvss_base, exploit(1-5), exposure(1-5), control_gap(1-5), impact(1-5)
 ("F1", "SQL injection on customer search API",         9.8, 5, 5, 4, 5),
 ("F2", "Default admin password on internal build server", 9.1, 4, 2, 4, 4),
 ("F3", "Outdated TLS config on marketing site",        5.3, 2, 5, 2, 1),
 ("F4", "Verbose errors leak stack traces (payments)",  5.3, 3, 5, 3, 3),
 ("F5", "Stored XSS in internal HR portal",             6.1, 3, 2, 3, 3),
]
P = {1: 0.01, 2: 0.03, 3: 0.10, 4: 0.25, 5: 0.50}          # illustrative annual probability per likelihood level
LOSS = {1: 50_000, 2: 250_000, 3: 1_000_000, 4: 5_000_000, 5: 20_000_000}  # illustrative loss per impact level
def band(s): return "Critical" if s >= 20 else "High" if s >= 10 else "Medium" if s >= 5 else "Low"
SLA = {"Critical": "7 days", "High": "30 days", "Medium": "90 days", "Low": "backlog"}

print("id  CVSS  L I score band      expected loss/yr  SLA")
def lik(f): return round(0.4 * f[3] + 0.3 * f[4] + 0.3 * f[5])
# order by score, then (tie-break) by expected loss
order = sorted(findings, key=lambda f: (-(lik(f) * f[6]), -(P[lik(f)] * LOSS[f[6]])))
for fid, t, cvss, ex, exp, gap, imp in order:
    L = round(0.4 * ex + 0.3 * exp + 0.3 * gap)
    s = L * imp
    print(f"{fid}  {cvss:4.1f}  {L} {imp} {s:4d} {band(s):9s} ${P[L]*LOSS[imp]:>12,.0f}  {SLA[band(s)]}")

Output:

id  CVSS  L I score band      expected loss/yr  SLA
F1   9.8  5 5   25 Critical  $  10,000,000  7 days
F2   9.1  3 4   12 High      $     500,000  30 days
F4   5.3  4 3   12 High      $     250,000  30 days
F5   6.1  3 3    9 Medium    $     100,000  90 days
F3   5.3  3 1    3 Low       $       5,000  backlog

Reading the table. F3 and F4 both have CVSS 5.3, yet F4 (payment errors, internet-facing) lands High and F3 (marketing site) Low. F2 has a CVSS of 9.1 but is internal, so High rather than Critical. F1 is Critical under either view. F2 and F4 tie at 12, so I break the tie by expected loss.

Making leadership accept it

• Agree the scale, weights and deadlines first, so the scores are not argued case by case.
• Present the top few findings in business terms (what an attacker could do, to which data).
• Group chained findings (separate flaws an attacker can use one after another): two Medium issues that combine into a path to the database are scored as the path.
• Give each finding an owner and a deadline, and route exceptions through risk acceptance.
• Retest to close.

Pitfall. Treating the weights as science: they are a shared convention, so keep them stable and show the inputs.

Short answer

Use a qualitative rating (a heat map: each risk gets a likelihood and an impact on an ordinal 1-5 scale (a ranking where 5 is worse than 4, with no promise that the gaps between steps are equal), and the product is coloured red/amber/green) to screen a long list quickly, when data is thin, and to decide what deserves a closer look. Insist on quantitative numbers (dollar ranges and an annualized loss, the expected dollars lost per year) when a spending, insurance or accept-or-transfer (keep the risk, or pass it to an insurer or supplier) decision depends on whether a risk is worth a given cost, or when several risks all land in the same red cell and you must order them.

Worked example: large data breach at a SaaS company

• Qualitative: likelihood 3 ("possible") x impact 5 ("severe") = 15, red. The scale behind that: likelihood 1 to 5 runs from "rare" to "almost certain", with 3 meaning roughly 5% to 20% a year; impact 5 means a loss of roughly $500k or more; red means a score of 15 or higher. Those anchors are illustrative.
• Quantitative: single loss expectancy (SLE, the cost of one event) of $500k to $4M, and annualized rate of occurrence (ARO, expected events per year) of 5% to 20%. Annualized loss expectancy (ALE) is SLE x ARO, so the range runs from 0.05 x $500k = $25,000 to 0.20 x $4M = $800,000. A single central figure, for example 0.10 x $1.5M = $150,000 (a rough central pick, not the arithmetic midpoint of the loss range, which would be $2.25M), is useful only if shown beside that range.

Where each approach misleads

How to use both

Score the whole register with defined qualitative scales (each level anchored to a probability band and a dollar band), then model only the top few risks in dollars, as ranges with stated assumptions and a confidence note. When the quantitative range straddles the cost of the control, say so: that is the honest answer, and it tells you which estimate to refine first.

Short answer. I would accept the risk formally, for a fixed period, only if compensating controls bring the security risk down to a level the data's business owner will sign for, and I would treat the regulatory gap as a distinct decision for counsel and the auditor. Acceptance does not make the requirement go away.

Two risks, not one.

• Security risk: an attacker or insider reaching unencrypted data at rest.
• Compliance risk: being out of line with a legal or contractual requirement. Compensating controls reduce the first; they only reduce the second if the regulator or auditor accepts them as equivalent. Counsel decides what exposure the company carries and whether an exception, extension or written guidance is available. If no exception route exists, the choices are to isolate or shrink the data, or to speed up the replacement.

Deciding whether to accept. Score before and after on a 5x5 scale (likelihood x impact, bands: Low 1 to 4, Medium 5 to 9, High 10 to 16, Critical 20 to 25; illustrative). Inherent (the risk before compensating controls): likelihood 4 x impact 4 = 16, High. Here likelihood 4 means "likely", for example a plausible chance of an incident reaching the stored data within a year given its exposure, and impact 4 means "major", for example exposure of customer records that triggers regulator and customer notification (illustrative definitions to agree with the business). After compensating controls: likelihood 2 ("unlikely") x impact 4 = 8, Medium (impact stays 4 because the data has not changed). I accept only if the residual lands in a band the owner may accept, the plan has a dated exit, and the compliance question is answered.

Compensating controls (each must meet the intent of the requirement with comparable strength. For encryption at rest the intent is that someone who obtains the stored data, such as a stolen disk, a copied backup or a snapshot, cannot read it. PCI DSS (Payment Card Industry Data Security Standard), for example, has a formal documented process for them):

1. Encrypt beneath the database: disk, volume and backup encryption with keys held in a key management service (a managed system that stores and rotates encryption keys). This stops stolen disks and snapshots but not a logged-in database user, so it is not equivalent on its own.
2. Field-level encryption in the application for the most sensitive columns where code can change.
3. Network isolation: a private segment allowing only the application servers.
4. Privileged access management (a tool that grants administrators temporary, approved access) with MFA (multi-factor authentication) and session recording.
5. Database activity monitoring (software that records queries and alerts on unusual ones).
6. Data reduction: purge or tokenize (swap sensitive values for meaningless stand-ins kept in a separate vault) what the business does not need.

Two rows of the compensating-controls matrix look like this (illustrative):

The signed acceptance names the residual risk (8, Medium), the owner, the date signed and the expiry.

Approvals. The business owner of the data signs the acceptance (they own the risk, not security). The security lead concurs. Compliance or counsel signs off on the regulatory position. The exception expires in 12 months, has quarterly reviews, and renewal needs a higher authority.

Migration milestones (illustrative): vendor chosen by month 2, build by month 6, cutover by month 11, leaving a month of buffer.

What I hand the auditors (six items)

1. The requirement text and gap analysis (a comparison of what the requirement demands with what the system does today).
2. The risk assessment and signed acceptance with names, dates and expiry.
3. A compensating-controls matrix with evidence (configuration exports, access reviews, alert samples).
4. Test results showing the controls work: design effectiveness (on paper, the control would meet the intent) and operating effectiveness (it actually ran as designed over the period, shown by samples and logs).
5. The migration plan with milestone status.
6. Counsel's or the regulator's position on the exception.

What would change my call: a regulator refusing any exception, or a residual that stays High.

Direct answer. With one week I would learn six things first: what the application does and who uses it, what data it handles, how it is exposed, how it authenticates and authorizes, what it depends on, and what controls and past findings already exist. Then I would spend most of the time where a failure would hurt most and where a quick test is most likely to find something, instead of trying to cover everything.

The minimum to learn (about a day)

1. Purpose and users: who uses it (employees, contractors, admins), and what business process depends on it.
2. Data: what it stores or touches, especially personal, financial or credentials. Sensitive data raises the stakes.
3. Exposure: internal only, behind VPN, or reachable from the internet? Which networks and which other systems connect.
4. Authentication and authorization: single sign-on or local accounts, roles, and whether users can reach each other's data.
5. Architecture and dependencies: components, hosting, third-party libraries and services, where secrets are kept.
6. Existing assurance: earlier reviews, scan results, logs and monitoring, owner, and when it must go live.

Deciding where to spend the time
Rank areas by impact (how bad if it fails) and exposure (how easy to reach). Illustrative 40-hour plan for an internal app holding employee data:

Access control gets the largest share because broken authorization is both common in internal apps and high impact. If the app turned out to be internet-facing or to hold payment data, I would move hours from the scan toward testing the exposed surface.

A small scoring rubric
Score each finding likelihood 1-3 x impact 1-3. A score of 6 or 9 blocks release until fixed or formally accepted; 3 or 4 is fixed within an agreed window; 1 or 2 is logged. Acceptance criteria for go-live: no blocking findings open, an owner named, logging in place and a re-test for every fixed blocker.

Report what you did not cover. State plainly what was out of scope so nobody reads "no findings" as "secure".

Pitfall. Running a scanner first and reporting its output unfiltered, without knowing which findings matter for this app.