Information Security Analyst (Staff Level) Interview Preparation Guide - FAANG-Standard Cybersecurity Edition

1) IOC / Reputation Enrichment (IPs, URLs, hashes)

• Integration: During ingestion, lookup indicators against a local cache of TI feeds (zeek/suricata tags -> enrichment fields) and attach reputation fields (feed name, confidence, last_seen). Use async fetch with caching and bulk updates to SIEM.
• Operational challenges: Latency if live lookups; mitigate with TTL-based caching and periodic bulk pulls. False positives from stale or noisy feeds; require feed hygiene and allowlist. Licensing: commercial feeds may limit queries; prefer local mirror or IDS integration.
• Scoring/trust: Assign weighted scores by feed reliability, recency, and indicator type (hash > IP). Compute composite score = sum(weight_i * freshness_factor).

2) TTP / ATT&CK Mapping Enrichment

• Integration: Map observed behaviors (processes, command lines, sequences) to MITRE ATT&CK techniques via enrichment engine in pipeline; tag events with likely technique IDs and confidence.
• Operational challenges: Behavioral mapping produces probabilistic matches → higher false positives; requires tuning and contextual correlation to reduce noise. Minimal latency but needs curated mapping rules.
• Scoring/trust: Use rule confidence + corroborating signals (multiple techniques, cross-asset occurrence) to raise trust. Treat single weak matches as low priority.

3) Threat Context & Adversary Attribution (who/why)

• Integration: Enrich with actor profiles from TI platforms (known campaigns, IOCs relationships) and past incident history; surface links in caseviews and hunting dashboards.
• Operational challenges: Attribution is often uncertain; introduces bias and overfitting. Licensing and API rate limits for commercial platforms.
• Scoring/trust: Use provenance scoring (source reputation, corroboration count, analyst validation). Expose trust level (high/medium/low) and allow analysts to override.

Situation: While monitoring our SIEM one evening I triaged a high-priority alert: multiple hosts generating large outbound connections to unknown IPs flagged by the IDS as data-exfiltration. This triggered escalation to the SOC.

Task: I needed to quickly determine if this was a real breach, contain any threat, and if it was false positive, identify root cause and prevent recurrence while keeping stakeholders informed.

Action: I collected host logs, firewall flows, endpoint telemetry and cross-referenced asset inventory. Endpoints showed a scheduled vulnerability scan that authenticated with a service account and opened many outbound sessions to our scanning appliance — the IDS signature matched that pattern. I ran packet captures to confirm traffic was scanner-to-appliance, checked process lists to confirm the scanner process, and reviewed scan schedules. Root cause: overly broad IDS rule and lack of scanner tagging in SIEM. I updated the IDS/SIEM rule to exclude authenticated scanner IPs and specific ports, created an allowlist for scheduled internal scans, documented the scan in our asset registry, and added a checklist to the SOC runbook to verify scheduled maintenance before escalating. I also adjusted alert thresholds to reduce noise.

Result: The incident was closed as a false positive within 90 minutes with no containment required. After tuning, similar alerts dropped by 85% over the next month. I communicated findings and remediation to SOC leads, IT ops, and the CISO via a concise incident report and a 15-minute walkthrough, and delivered the runbook updates so future triage is faster and clearer.

Direct answer

Fix the public bucket first: it requires no attacker skill and data is exposed the moment it exists. The over-broad Lambda IAM (Identity and Access Management) policy is second, because it is the finding with the largest blast radius once any foothold exists. The permissive Cross-Origin Resource Sharing (CORS) policy on the API gateway is third: on its own it needs a victim's browser to be useful to an attacker, and its real danger is usually in combination with the other two, not in isolation.

Structured elaboration

Worked example

A realistic 5-day remediation sequence for this exact report:

• Day 0, first hour: confirm via S3 server access logs (or CloudTrail data events) that no legitimate service depends on the bucket's public read, then flip Block Public Access. This is non-disruptive because it is reversible in seconds if something breaks, and the finding's exploitability was the highest of the three.
• Day 0, same day: capture the current CORS configuration, replace the wildcard origin with the known production and staging frontend origins, and deploy behind a feature flag so it can be reverted without a full redeploy if a missed origin surfaces.
• Day 1: run IAM Access Analyzer's policy generation against 90 days of the Lambda function's CloudTrail activity to produce a scoped candidate policy; diff it against the current wildcard policy and flag every action the function legitimately used.
• Day 2 to 4: deploy the scoped policy to a canary alias or a staging copy of the function, replay representative traffic (including any known rare code paths, such as a monthly batch job) against it, and watch for AccessDenied errors.
• Day 5: cut the production alias over to the scoped policy once the canary period shows no denied calls, and archive the wildcard policy version rather than deleting it, so a fast rollback exists if something in production diverges from the sampled traffic.

Trade-offs and pitfalls

• Speed versus production impact is not a straight line. The public bucket fix is both the highest priority and the lowest risk to flip immediately; the IAM fix is the opposite (real but lower immediate exploitability, real risk of breaking a legitimate rare call path if scoped from an incomplete activity sample). Sequencing by exploitability first and reversibility second, rather than by "IAM is scary so do it last," is what keeps the team from either leaving the bucket open too long or breaking production by rushing the IAM change.
• Wide IAM policies exist because scoping is tedious, not because anyone chose them deliberately. Preventing recurrence means making the scoped path the path of least resistance: a CI (continuous integration) gate that runs policy-as-code checks (Open Policy Agent/Conftest, or a managed rule set) against every Terraform or CloudFormation change, blocking wildcard actions or resources before merge.
• CORS misconfiguration is easy to fix wrong. Allow-listing origins from memory instead of from an inventory of every legitimate caller (including a partner integration or an internal tool) causes the second incident: a real caller breaks silently, and the fastest fix under pressure is often to widen the origin back to a wildcard, undoing the remediation.
• Validate fixes the same way across every environment, not just production. A Config rule or CSPM (Cloud Security Posture Management) check that only runs against the production account will let the same misconfiguration ship again from a developer copying dev or staging Terraform into a new module; the detection gate belongs in the pipeline that produces the IaC (Infrastructure as Code), applied identically to every environment's plan.
• Preventing recurrence needs an organization-level guardrail, not just a per-account fix. A Service Control Policy (SCP) denying changes to S3 Block Public Access settings, paired with a scheduled drift-detection rule, catches the case where a well-meaning engineer reverses today's fix six months from now through the console.

Approach
Brief sliding-window dedupe using a deque for timestamps and a dict mapping key -> last-seen timestamp. Evict entries older than window_seconds to keep memory bounded; process stream in one pass (O(n)).

Code

from collections import deque

def dedupe_alerts(alerts, window_seconds):
    """
    alerts: iterator of dicts with keys: timestamp (int), signature, src_ip, dst_ip
    yields deduplicated alerts (suppress same signature+src+dst within window)
    """
    window = deque()  # stores (timestamp, key)
    last_seen = {}    # key -> last timestamp within window

    for alert in alerts:
        ts = int(alert['timestamp'])
        key = (alert['signature'], alert['src_ip'], alert['dst_ip'])

        # Evict old entries
        cutoff = ts - window_seconds
        while window and window[0][0] <= cutoff:
            old_ts, old_key = window.popleft()
            # only remove if mapping still points to that timestamp
            if last_seen.get(old_key) == old_ts:
                del last_seen[old_key]

        # If not seen in window, yield and record
        if last_seen.get(key) is None:
            yield alert
            last_seen[key] = ts
            window.append((ts, key))

Key concepts & complexity

• O(n) time, memory proportional to active-window unique keys.
• Suitable for SIEM streaming ingest; works with out-of-order slight drift if timestamps are monotonic chronological.

Edge cases

• Non-monotonic timestamps: require buffering or sort.
• Very high cardinality within window: memory grows accordingly.

Direct answer

Likelihood is the probability that a given threat is actually realized in a given time window. Impact is the magnitude of harm if it is realized, spanning financial, operational, regulatory, and reputational dimensions. Risk velocity is a third, independent axis: how fast the window between "this threat becomes exploitable" and "this threat is likely exploited" actually is. Static likelihood times impact scoring answers "how bad is this risk," while risk velocity answers "how much time do I have to act on it," and a remediation queue that ignores the second question will routinely work on the wrong item first.

Structured elaboration

Likelihood and impact are usually scored on a small ordinal scale (for example 1 to 5) and multiplied to produce a single risk score, a widely used shorthand:

$\text{Risk} = \text{Likelihood} \times \text{Impact}$

This score is a snapshot: it says nothing about time. Risk velocity captures the missing dimension by asking how quickly the likelihood of exploitation is changing, in practice driven by signals like whether a working exploit has been published, whether it has been added to a common exploitation framework, and whether the vulnerable asset is internet-facing. A vulnerability can have modest static likelihood today and extremely high risk velocity the moment a proof-of-concept goes public, because the population of people capable of exploiting it just expanded from a handful of specialists to anyone who can run a script.

The practical effect on prioritization is that a lower-scored, high-velocity item can legitimately need to be worked before a higher-scored, low-velocity item, because the organization's actual window to act on the high-velocity item is closing fast while the low-velocity item's window is not.

Worked example

Consider two findings in the same remediation backlog, scored on a 1 to 3 scale for likelihood and impact:

• Vulnerability A: likelihood 2 (medium, no known exploit, requires an unusual configuration to reach), impact 3 (high, full database read access). Static score: $2 \times 3 = 6$. No public exploit exists yet and the vendor patch is complex to test, so the realistic window before exploitation is roughly 180 days.
• Vulnerability B: likelihood 1 (low, was assessed as a minor issue when first triaged), impact 2 (medium, limited to one internal admin function). Static score: $1 \times 2 = 2$. But a working exploit was published today and added to a popular exploitation framework used by opportunistic attackers scanning the internet, compressing the realistic window before exploitation to roughly 2 days.

Under static likelihood times impact scoring, A (6) outranks B (2), and a queue sorted purely by that score works A first. Introducing risk velocity as a divisor against the exploitation window in days reorders the queue:

$\text{Priority} = \text{Likelihood} \times \text{Impact} \times \frac{1}{\text{Risk Velocity (days)}}$

$\text{Priority}_A = \frac{6}{180} \approx 0.033 \qquad \text{Priority}_B = \frac{2}{2} = 1.0$

B's priority score is roughly 30 times higher than A's, despite scoring three times lower on the static risk score, because the organization has two days rather than six months to act on it before exploitation is likely.

Trade-offs and pitfalls

The scale (1 to 3, days as the velocity unit) used above is illustrative, chosen to keep the arithmetic traceable, not a claim about an industry-standard scoring convention; a real program calibrates its own scales against its own historical incident data. The main pitfall is treating risk velocity as replacing likelihood and impact rather than multiplying against them: a low-impact finding with extremely high velocity (say, a typo in a public marketing page that gets embarrassing fast) still should not outrank a catastrophic-impact finding with only moderately high velocity, so velocity should compress a queue's ordering within a similar impact tier more than it should override impact entirely. A second pitfall is stale velocity: unlike likelihood and impact, which change slowly, velocity can shift from low to critical within hours of a public disclosure, so a velocity-aware queue needs to be re-scored on a cadence that matches how fast the underlying signals actually move, not on the same quarterly cycle as the rest of the risk register.

Direct answer
A stretch assignment only works as a growth tool if it's picked deliberately (real stakes, but survivable if it goes wrong), supported actively rather than handed off and hoped for, and evaluated by whether the person can now do something they genuinely couldn't before, not just whether the project shipped.

Picking the assignment

• Look for the specific gap between where someone is and where they want to go, and pick something that exercises exactly that gap: not a bigger version of what they already do well, but the thing they haven't had to do yet (leading ambiguity, owning a stakeholder relationship, making a judgment call without a clear right answer).
• Sanity-check the blast radius: a good stretch assignment has real consequences if it goes wrong, but not consequences the team or the person can't absorb. If failure would be catastrophic, it's not a stretch assignment, it's a bet you shouldn't be making on someone's first attempt.

Supporting through it

• Set explicit checkpoints rather than open-ended availability; someone stretching is often reluctant to ask for help exactly when they need it most, because asking feels like it undercuts the point of the assignment.
• Watch actively for the failure mode where the person becomes overwhelmed or delivery risk climbs mid-assignment. The fix isn't to quietly take it back (that undoes the growth and teaches them stretch assignments are a trap), it's to scope down the ask while keeping ownership intact: shrink the surface area, extend the timeline, or bring in narrow support on the hardest sub-piece, while the person still owns the outcome.

Knowing it worked

• The real signal isn't whether the deliverable shipped; plenty of stretch assignments succeed despite the person, propped up by others. The signal is whether they can now do a similar thing again with meaningfully less support than before.
• Ask them directly what they'd do differently next time; someone who's actually grown from it usually has a specific, concrete answer, not a vague "it was good experience."

Variants worth having ready

• Succession-driven: when someone owning a critical piece of the system is leaving, a stretch assignment can double as a deliberate handoff, usually spread across two or three people rather than one, so the knowledge doesn't just move from one single point of failure to another.
• Developing a mentor, not just a mentee: a technically strong senior who's never mentored can be given a stretch assignment that's explicitly about teaching, not delivery, such as owning a junior's ramp-up plan with the growth of the junior, not the speed of the project, as the success measure.

Worked example
A strong individual contributor wanted to grow into leading larger, more ambiguous work but had only ever executed against fully-scoped tasks. Rather than a bigger version of the same kind of work, the assignment was to own a smaller, genuinely under-scoped project end to end: figure out the actual requirements from a vague ask, make the technical calls, and report progress upward directly instead of through a lead. Support looked like a standing short weekly check-in (not daily oversight) and an explicit agreement that they'd flag it early if they felt stuck, rather than waiting until a deadline made the risk visible.

Partway through, the scope turned out to be bigger than either of us expected, and the person started showing the classic overwhelmed signs: shrinking updates, slipping the weekly check-in. Rather than pulling the project back, the assignment was rescoped down to the highest-value piece, with the harder edge case handed to someone else, while they kept ownership of the core decision and the delivery. They finished a smaller version of the original ask, and more importantly, on the next ambiguous piece of work a few months later, they scoped it themselves without needing the same weekly check-in structure. That second instance, done with much less support, was the actual evidence the stretch assignment had worked, not the fact that the first project shipped.

Trade-offs and pitfalls

• Picking a stretch assignment that's really just "more of the same, but bigger" doesn't build a new skill; it just tests stamina.
• Quietly rescuing someone the moment they look overwhelmed (taking the assignment back rather than rescoping it) protects the deliverable but teaches the person that stretching is unsafe, which discourages them from taking the next one.
• Measuring success by whether the deliverable shipped, rather than by what the person can now do independently, rewards you propping the project up rather than the person actually growing.

Approach (brief)
As an Information Security Analyst I integrate OSINT and commercial TI into the vuln management pipeline by enriching vuln records, applying reprioritization rules, and automating an incident playbook when active exploits are observed.

Enrichment fields to add

• TI source (open/commercial) and confidence score
• Exploit observed (boolean) + first-seen timestamp
• Exploit type (PoC / weaponized / RCE / LPE / info-steal)
• Active campaigns / malware family (if known)
• IOCs (C2 IPs, URLs, hashes) and TTPs (ATT&CK IDs)
• Targeting context (industry, geolocation, product)
• CVSS + temporal/factors (exploitability, age)
• Business asset owner, business impact, compensating controls

Reprioritization conditions

• Observed exploit in the wild for the CVE (immediate bump to high/critical)
• Public PoC release with weaponized payload (raise)
• Active campaign targeting our sector or assets (raise)
• IOC matches internal telemetry (raise to incident)
• Low confidence TI or irrelevant targeting (no change or lower)

Automated playbook (fires on 'active exploit' for high-severity CVE)

1. Ingest TI → mark vuln as “Active Exploit” and notify SOC + vuln owner.
2. Query EDR/SIEM for IOCs and asset matches; isolate impacted hosts if detected.
3. Apply compensating controls: block IOCs at perimeter, add WAF/IDS signatures, restrict access.
4. Schedule emergency patch/remediation workflow and maintain mitigation tickets.
5. Run threat hunt for lateral activity; escalate to IR if confirmed compromise.
6. Log actions, update ticket with TI artifacts, and feed back enriched data to TI platform.

This design balances speed (automated containment) with analyst validation to avoid false positives.

Direct answer

Evaluating a threat intelligence (TI) feed for ingestion means judging it on the same dimensions any data source should be judged on before it is trusted to drive detections, does it actually catch things (coverage), is it timely enough to matter, is it accurate enough not to become a new source of false positives, and is the operational cost proportionate, and the only way to know any of that is to pilot the feed against real telemetry before fully trusting it, not to take a vendor's own marketing claims at face value.

Structured elaboration

Quality metrics to evaluate:

• Coverage: what fraction of the organization's actual threat landscape (relevant attacker infrastructure, malware families, techniques) does this feed plausibly address, versus a generic feed covering threat categories irrelevant to this specific organization's risk profile.
• Timeliness: how quickly does the feed publish an indicator relative to when that indicator becomes actively used in the wild; a feed that is accurate but consistently late provides much less real defensive value than its raw indicator count suggests.
• Accuracy: what fraction of the feed's indicators, when checked against ground truth or historical incident data, are genuinely malicious versus stale, mislabeled, or overly broad (a feed listing an entire large cloud provider's IP range as "malicious" because ONE tenant on that range was compromised is technically not wrong but is operationally almost useless).
• Telemetry hit-rate: how often this feed's indicators actually MATCH something in the organization's own telemetry at all; a feed with excellent indicators for threats the organization simply does not encounter contributes little practical value regardless of its abstract quality.
• Overlap with existing feeds: how much of this feed's content is redundant with feeds already ingested, since paying for and processing heavily overlapping feeds is a real, avoidable cost with little marginal detection benefit.
• Operational costs: ingestion volume, licensing cost, and the engineering time needed to normalize and integrate the feed's format into the existing pipeline.
• Licensing restrictions: some threat intelligence has usage or redistribution restrictions (particularly some commercial and government-sourced feeds) that constrain how it can be used, for example whether matched indicators can be shared with a managed security service provider or included in an external incident report.

Worked example

A concrete, low-risk piloting approach: ingest a candidate feed into a SHADOW or scoring-only mode first, where its indicators are matched against a rolling window of the organization's own historical telemetry (for example the trailing 30 days) WITHOUT generating live analyst-facing alerts, and the match results are logged for offline review. This measures the feed's real telemetry hit-rate and, by manually reviewing a sample of the matches, an approximate accuracy rate, using the organization's OWN data rather than the vendor's aggregate claims, before any live alerting is turned on. Only once this pilot shows an acceptable hit-rate and accuracy, and a manageable overlap with existing feeds, does the feed graduate to live, analyst-facing enrichment or alerting.

Trade-offs and pitfalls

• Tactical, operational, and strategic threat intelligence serve different purposes and should be evaluated differently: tactical intelligence (specific indicators like IPs, domains, file hashes) is what directly feeds detection rules and is the primary subject of the coverage/accuracy/hit-rate evaluation above; operational intelligence (adversary tactics, techniques, and procedures, campaign-level detail) informs detection ENGINEERING priorities (which techniques to build coverage for) rather than being ingested as literal indicators; strategic intelligence (broader threat-landscape trends, targeting patterns) informs leadership-level risk decisions and budget, not day-to-day detection rules at all. Evaluating a strategic-intelligence source on "telemetry hit-rate" is a category error, since it was never meant to produce matchable indicators in the first place.
• Common mistake: judging a feed purely by raw indicator VOLUME; a feed with millions of low-quality, stale, or irrelevant indicators is a worse addition to a detection pipeline than a smaller, high-precision, well-curated feed, since every ingested indicator carries some ongoing cost (storage, matching compute, and the risk of contributing a false positive).
• Common mistake: never re-evaluating a feed after initial onboarding; a feed's quality can degrade over time (a vendor's data sourcing changes, a previously well-curated feed becomes automated and noisier), so the same piloting-style evaluation discipline should be applied periodically, not just once at intake.
• Poisoning risk: a feed sourced from an insufficiently vetted or adversarial-accessible collection mechanism (for example, crowd-sourced or honeypot-derived feeds with weak curation) can be deliberately poisoned by an adversary who learns the collection method, submitting false indicators designed to either waste defender attention or, more dangerously, get a legitimate resource blocklisted; provenance and curation rigor are themselves a quality dimension worth evaluating, not just the resulting indicator content.

Direct answer
Signs pointing toward a security incident rather than a purely operational one include unexplained privilege or permission changes, authentication failures or account lockouts clustering in an unusual pattern, traffic or data-access patterns that look like exfiltration rather than normal load, and any sign of unauthorized file or configuration changes that nobody on the team made. Once you suspect any of these, the biggest change is that you stop trying to 'just fix it': you preserve evidence instead of immediately remediating, and you loop in a security responder rather than continuing to triage it as a routine outage.

Structured elaboration

• Signals that lean operational: the timing correlates with a known deploy or infrastructure change, the failure pattern matches a resource exhaustion or a known dependency issue, and the behavior is explainable by something the team did on purpose.
• Signals that lean security: access or configuration changes nobody recognizes, authentication anomalies (a spike in failed logins, logins from unusual locations, tokens being used in ways that don't match normal patterns), data being read or moved in volumes or patterns that don't match normal usage, or any indicator resembling a known attack pattern (credential stuffing, privilege escalation, lateral movement).
• What changes once you suspect it. You stop applying your normal 'fix it fast' instincts on the affected system, because touching it (restarting a process, wiping a disk, rotating credentials without first documenting state) can destroy evidence a security investigation needs. You loop in whoever owns security response, and from that point the deep investigation, containment technique, and evidence-handling discipline live with that team rather than being improvised by whoever happened to be on call.
• Who to involve: the security on-call or incident response function, as early as suspicion arises, not after you've already tried to resolve it yourself.

Worked example
A service starts throwing errors and the on-call engineer initially assumes it's a bad deploy, since that's the most common cause. But checking recent deploys shows nothing changed, and instead they notice a spike in failed authentication attempts against an admin endpoint in the minutes before the errors started, followed by a permissions change on a service account that nobody on the team made. That combination (no correlated deploy, authentication anomaly, unexplained permission change) is the tell that this isn't a routine outage; the engineer stops attempting further remediation, preserves the current state (avoids restarting the affected service, which could wipe useful logs), and escalates to the security team rather than continuing to debug it as an availability problem.

Trade-offs and pitfalls
The main risk under pressure is dismissing security signals too quickly because restoring service feels more urgent, which can mean actively destroying evidence (restarting a compromised host, deleting suspicious files 'to clean up') before anyone with security expertise has looked at it. The opposite risk is over-escalating every anomaly as a security incident, which burns the security team's time and can create alert fatigue that makes real security incidents harder to distinguish from noise; the right calibration is a small, well-understood set of signals (like the ones above) rather than a vague sense that 'something feels off.'

Direct answer

Combine business impact, personal-data exposure, and technical severity into a single Sev1-to-Sev4 scale with concrete thresholds for common ML failure modes, and treat a confirmed Sev1 (for example, PII leakage or regulator-impacting errors at scale) with the same first-hours coordination discipline as any other major security incident: engineering, legal, and executives in the room immediately.

Structured elaboration

A practical scheme, roughly:

• Sev1: confirmed personal-data exposure at scale, or model errors directly causing regulator-impacting harm (for example, systematically incorrect loan denials affecting a protected class), or full model/service unavailability for a business-critical use case.
• Sev2: significant accuracy collapse on a meaningful user segment without confirmed PII exposure, or a smaller-scale, contained data exposure affecting a limited number of users.
• Sev3: localized or edge-case model degradation with limited business impact, no confirmed data exposure, affecting a small population or a non-critical feature.
• Sev4: cosmetic or negligible-impact anomalies requiring tracking but not urgent response.

Give each threshold concrete, measurable criteria rather than leaving it to judgment call each time: for example, define "accuracy collapse" as a specific percentage-point drop against a rolling baseline, define "PII exposure" thresholds by estimated affected-user count, and define "regulator-impacting" by whether the affected decision category (lending, employment, healthcare) is one your legal team has already flagged as high-risk.

Coordinating the first hours of a Sev1. Convene engineering, legal, and executive leadership together, not sequentially, since a confirmed PII leak or regulator-impacting error needs all three perspectives simultaneously: engineering to contain and assess technical scope, legal to assess notification obligations and regulatory exposure, and executives to make resourcing and external-communication calls quickly. Assign a single incident commander to own the coordination rather than letting three parallel, uncoordinated workstreams emerge.

Worked example

An automated loan-approval model is found to be systematically denying applications from a specific demographic at a disproportionate rate due to a data-pipeline bug introducing a biased feature. Given the regulator-impacting nature of lending decisions, this is classified Sev1 even though there's no direct PII leakage and the model itself hasn't crashed. Within the first hour, engineering, legal, and an executive sponsor are convened together: engineering begins tracing the specific feature causing the bias and prepares an immediate mitigation (reverting to the prior model version), legal assesses fair-lending regulatory exposure and notification obligations, and the executive sponsor authorizes the immediate rollback despite the operational cost of reverting a recently-improved model, given the regulatory severity classification.

Trade-offs and pitfalls

Defining severity thresholds vaguely ("high impact" without a measurable definition) leads to inconsistent classification between incidents and slows down the decision of how urgently to respond; concrete, pre-agreed thresholds remove that ambiguity exactly when speed matters. A second common mistake is classifying by technical severity alone (did the model crash) without weighing business and regulatory impact, which can under-classify an incident like the lending-bias example above, where the model technically "worked" but caused serious harm.