Security, Privacy and Compliance Risk Assessment Questions

Direct answer. I would add a short intake that every change passes through, tier changes by risk using a handful of objective triggers, and send only the top tier to the central security and privacy team before release (the middle tier gets a lighter review by a security champion on the product team). Low-risk changes proceed with automated checks; high-risk ones get a time-boxed review. For urgent releases I would allow an expedited path: ship with a named executive accepting the specific risk, plus a follow-up review within a fixed window.

1. A one-page intake inside the tools teams already use
Put 6 to 8 yes/no questions into the ticket or pull-request template, for example: does the change collect or share new personal data; add or change authentication or permissions; expose a new internet-facing endpoint; send data to a new third party; handle payment or health data; or change encryption? Any yes moves the change up a tier: a new authentication or permissions model, a new third party, or payment or health data puts it straight into tier 3, while new personal data, a new internet-facing endpoint or a change to encryption counts as a tier 2 trigger. Example: a team adds a "share with a friend" button that sends the friend's email address to an email vendor already approved for this use. New personal data: yes (the friend's email). New third party: no. Authentication, permissions, payments or health data: no. One yes means tier 2, so the team's security champion reviews it against the checklist within 2 business days, and it ships without waiting for the central team.

2. Three tiers

3. Keep it light
Illustrative load: if a company ships 120 changes a month and 10% reach tier 3, that is 12 reviews. At 2 hours each, that is 24 hours of specialist time a month, a workload one or two people can carry. If the tier-3 share climbs well above that, tighten the triggers or add reviewers instead of dropping the gate.

4. Urgent release

• The product owner asks for an exception; I tier the change in minutes, not days.
• Do a 30-minute focused review of just the risky part, and add compensating controls (extra safeguards that reduce risk when the normal control cannot be met), such as a feature flag (a switch that turns the feature on for a few users and off instantly), limited rollout and extra monitoring.
• If risk remains, a named executive accepts it in writing with an expiry date. Security does not approve its own override.
• A full review follows within, say, 5 business days, and the exception count is reported monthly.

5. Measure whether it works
Track review turnaround, share of changes reviewed, and exceptions, plus findings caught before release against issues found afterward.

Trade-off. The gate trades coverage for speed on purpose. Being clear that tier 1 changes get no human review is better than promising review you cannot deliver.

Pitfalls. Triggers that are subjective ("is this risky?"), a gate owned only by security, and an exception path that quietly becomes the normal path.

Short answer. Risk appetite is the broad amount and type of risk the company is willing to pursue to meet its goals, set by the board. Risk tolerance is the measurable limit around a specific objective that engineers can check themselves against. Appetite says "we accept little risk with customer data"; tolerance says "no critical vulnerability stays open on an internet-facing system for more than 7 days".

In practice. Appetite is a few plain statements per risk area, owned by the board or executive team, reviewed yearly. Tolerance turns each statement into thresholds that are measured and have an owner. If a team cannot tell whether it is inside the tolerance, the tolerance is not operational.

Setting both for a global SaaS company (all numbers illustrative):

Making it usable by engineering

• Express tolerances as automated checks (build pipeline gates, which stop a release when a check fails, and dashboards) rather than documents.
• A risk acceptance authority matrix (who may sign off on how much risk) tied to a score, where the score is likelihood (1 to 5) times impact (1 to 5): Low (1 to 4) by the team lead, Medium (5 to 9) by the engineering director, High (10 to 16) by the executive sponsor with the security lead, Critical (20 to 25) not acceptable beyond a short period without the executive team.
• Pre-approved patterns so teams do not ask for permission each time: for example, a standard way to store customer data with encryption already configured, which any team may use without a risk review.
• Review thresholds when the business changes; tolerance that never fires is probably set too loose.

Machine learning systems. If the company trains machine learning models, they need their own tolerances: no personal data in training sets without a completed privacy assessment, a limit on measured performance gaps between user groups (for example, accuracy for one region or language far below the average), a required review when drift (the model's inputs or accuracy shifting away from what it was trained on) crosses a set threshold, and an escalation path to the privacy lead and executive sponsor for incidents such as a model leaking training data. Metrics: share of models with a completed assessment, count of open model-risk exceptions (approved departures from these tolerances), time from drift alert to review.

Pitfall. A single "low risk appetite" statement with no tolerances, so every team decides alone.

Direct answer. I would not promise the customer a number, because reputational damage cannot be measured directly. I would estimate it through proxies that tie to money (customer churn, contract concessions, slower sales, support cost), compute low, base and high scenarios, convert the result to the impact scale in my register, and validate the estimate against what actually happens in renewals.

Proxy measures

• Churn: extra customers who do not renew after the event. This is the largest and most measurable proxy for a business-to-business (B2B) company.
• Concessions: discounts or free months granted to keep customers.
• Sales friction: longer sales cycles, extra security questionnaires, deals lost where the incident is cited.
• Behavioural signals: drop in product usage, spike in support tickets, requests for audits, negative mentions.
• Contract triggers: customers with termination or audit clauses tied to breaches.

Worked example (illustrative figures)
Assume 200 customers, average annual contract value (ACV) of $50,000, so annual recurring revenue (ARR) is 200 x $50,000 = $10 million. Suppose extra churn after a breach is 2, 5 or 10 percentage points in the low, base and high cases:

Add concessions and sales friction separately and state them as ranges. Better inputs come from your own history (churn after past outages or incidents), peer incidents you can learn from, and the vulnerability's exposure: a flaw that exposed customer data to the internet implies higher churn than one that exposed internal data.

Feeding the ranking
Define impact bands on the same dollar basis as other impacts. Illustrative: 1 is under $50,000; 2 is $50,000 to under $250,000; 3 is $250,000 to under $1 million; 4 is $1 million to under $5 million; 5 is $5 million or more. The base case of $500,000 scores impact 3, and the high case of exactly $1 million scores 4. I rank on the base case but flag the high case as the tail, and I raise the score one band if a few customers account for a large share of ARR.

Validate
After an incident, compare predicted churn with actual renewals and update the percentages. Before one, calibrate with retention data from previous events. Treat all of these as estimates with a range, never a precise figure.

What to tell the customer. Not a damage estimate: tell them what happened, what you did, and what protects them next.

Pitfall. Quoting a single precise reputational number, or borrowing an industry average without knowing its basis.

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.

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.