DoorDash Staff Security Architect Interview Preparation Guide

Summary approach
Identify and prioritize business-critical assets, map likely threat actors to each, list common attack vectors, and explain why each risk undermines safety, revenue, or trust.

Top 5 assets (priority order)

1. User PII & payment data — financial loss, regulatory fines, reputational damage
2. Courier identities & background-check data — safety, liability, fraud prevention
3. Order fulfillment & transaction system (matching/payments) — revenue integrity and service availability
4. Delivery tracking & location telemetry — user safety, stalking risks, fraud disputes
5. Internal admin systems / credentials — ability to escalate impact and persist

Threat actors & mappings

• External attackers: data exfiltration (PII, payments), DDoS on ordering systems
• Fraud rings: fake accounts, chargebacks, GPS spoofing to steal orders
• Malicious couriers: location spoofing, order diversion, privacy violations
• Insiders: misuse of admin access to view PII, manipulate orders/payments

Common attack vectors

• Phishing / credential stuffing → stolen accounts/admin access
• API abuse & insufficient auth → order/payment manipulation
• Payment fraud / synthetic identities → chargebacks, revenue loss
• GPS spoofing / app tampering → misdeliveries and safety incidents
• SQLi/Exfiltration and misconfigured S3 → PII leaks

Why critical
Each risk directly impacts user/courier safety, regulatory exposure, revenue, and marketplace trust. Prioritize protecting PII/payments and hardening auth, then telemetry integrity, fraud-detection, and least-privilege for internal systems.

Approach (one-sentence):
Design an event-driven SBOM ingestion + enrichment pipeline that normalizes components, matches against multi-source vuln feeds, scores/prioritizes per-service impact, and invokes owner-specific remediation workflows at scale.

High-level flow

• CI/CD & prod images emit SBOMs (CycloneDX/ SPDX) → ingest API → normalization service → component-index store → enrichment/matching engine (stream + batch) → risk aggregator → alert/orchestration.

Data models

• SBOM { id, source, artifact_id, purl[], hash, created_at, owner_service_id }
• Component { purl, name, version, hashes[], meta }
• Vulnerability { vuln_id, source, cve, affected_purl_patterns, severity, fix_info, published_at }
• Finding { finding_id, component_purl, vuln_id, artifact_id, impact_score, owner_service_id, status, created_at }

APIs (REST/GraphQL)

• POST /ingest/sbom — accepts SBOM, returns sbom_id
• GET /sbom/{id}
• GET /service/{id}/findings?state=
• POST /remediation/{finding_id}/action — trigger ticket/PR/automation
• GET /vuln/{id}/meta

Matching & enrichment

• Normalize to purl + semver ranges; use package-url and SPDX parsers
• Real-time matching via stream processor (Kafka + ksql) against in-memory indices; fallback batch jobs for complex fuzzy matches
• Use bloom filters and sharded hash indexes for fast existence checks; maintain canonical vulnerability canonicalization layer per feed

Prioritization & owner impact

• Compute impact_score = weighted(sum(service_criticality, exploitability, exposure_score, transitive_dependency_depth))
• Service criticality from CMDB (SLA, revenue, external facing)
• Aggregate per-service dashboards and SLA-based SLIs; auto-assign owner_service_id and owner_user via service registry

Remediation orchestration

• Orchestrator invokes playbooks: create ticket (Jira), open PR (CI), apply runtime mitigation (WAF, network ACL), or schedule patch window
• Support manual gating: notify owners with runbook and auto-retry

Ownership boundaries

• Ingestion + normalization: Platform team
• Matching & vuln feed integration: Security Threat Intel team
• Prioritization/risk model + SLAs: Security Architecture/Risk
• Orchestration/integration with CI/CD and ticketing: DevOps teams
• Final remediation responsibility: Service owners

Scale & reliability

• Stream-first (Kafka), microservices autoscaled (K8s), stateful stores: Cassandra/Dynamo for components, Redis for hot indices, Elasticsearch for search
• Partition by purl namespace/service to support millions of artifacts
• Use incremental diffs: only re-evaluate components when SBOM deltas or new vuln feed updates
• Rate-limit feed ingestion; maintain provenance and TTLs; support eventual consistency
• Observability: metrics (Prometheus), traces, alerting for backpressure and matching latency SLAs

Trade-offs

• Real-time matching vs accuracy: use hybrid (fast in-memory for exact matches + periodic deep analysis)
• Storage cost vs query speed: tier hot indices for recent/high-risk artifacts, archive old SBOMs

This design provides scalable, auditable orchestration tying vulnerability intelligence to owner-driven remediation with clear team boundaries and measurable SLAs.

Direct answer

Pull a small set of metrics that each answer a different question: how many people or transactions does this touch (scale), how well does it perform (latency), how well is it understood (monitoring coverage), and how often does it break (incident frequency), because together they tell you whether the team's current work is really about growth, stability, or catching up on debt.

Structured elaboration

• Active-user or transaction counts: tells you scale and growth trajectory. A team serving a fast-growing base has different priorities than one serving a flat or shrinking one.
• Service latency, often reported as p95 or p99 (the 95th or 99th percentile response time, meaning 95 or 99 percent of requests are faster than that number): tells you whether performance is a live, active concern or an already-solved problem. A team quoting specific latency targets in postings is usually still fighting that battle.
• Monitoring or observability coverage (how much of the system has alerting and dashboards): low coverage usually means near-term work is "instrument this" rather than "optimize this."
• Incident frequency, from a public status page if one exists: a high-frequency team is likely in stabilization mode, a low-frequency one may be free to invest in new features instead.

Worked example

Comparing two candidate teams from public data alone. Team A's status page shows one incident in the last six months and its job posting emphasizes "build new capabilities." Team B's status page shows five incidents in the same window, several repeating in the same subsystem, and its posting emphasizes "improve reliability." A LinkedIn scan also shows Team B has no dedicated site reliability engineer (SRE, a role focused on keeping production systems reliable and observable) while Team A does. Combined, it's reasonable to infer Team B's near-term work is firefighting and foundational reliability investment, while Team A's is closer to steady-state feature growth.

Trade-offs and pitfalls

Public metrics are lagging and incomplete, a quiet status page might mean genuine stability or just under-reporting of minor incidents, so treat these as directional signals worth asking about, not settled conclusions. Also avoid over-indexing on any one metric in isolation, high incident count alongside high user growth could actually describe a healthy team straining under real success, not a poorly run one.

Direct answer

Persuading a skeptical stakeholder starts with diagnosing what kind of resistance you're actually facing, since the same "here's more data" response only works on an evidence-based objection. A political objection or a loss-of-control objection needs a different tactic entirely.

Structured elaboration

Objection taxonomy. Naming the type of resistance before choosing a tactic is what separates a senior answer from "I showed them more data":

Worked example

Situation. At a product org, a UX team relied on manual review of every design change against brand guidelines. A design systems lead proposed an automated linting check for a subset of mechanical rules. One senior designer resisted far more strongly than the proposal's scope seemed to warrant.

Stakes. The designer's review was a required approval gate; without their buy-in, adoption could be blocked or slow-walked indefinitely, regardless of how good the tool was.

The influence moves.

• Noticed the resistance didn't track with the evidence: false-positive-rate numbers didn't move the reaction at all, which was the signal something else was going on.
• Asked directly what was underneath the resistance, and learned it wasn't about accuracy: automating the check felt like it removed the designer's voice and shrank their judgment role.
• Reframed the proposal to preserve their say explicitly: the linter would catch only mechanical rule violations (spacing, contrast ratios), routing anything subjective to the designer's review, unchanged.
• Gave the designer a visible role in defining which rules counted as mechanical versus subjective, turning them from a blocker into the rule-owner.

Resolution. The designer became the tool's internal champion once their judgment role was made explicit rather than replaced.

What a senior candidate does differently. Doesn't try to win a trust objection with more data. A mid-level answer keeps citing the false-positive rate; a senior candidate diagnoses the objection type first and matches the tactic to it.

Trade-offs and pitfalls

• Misdiagnosis wastes your strongest tool. Aiming data at a political or trust objection wastes the one resource that can't solve that problem, and can read as tone-deaf to the stakeholder.
• Political objections sometimes can't be fully resolved through the stated concern, because the real driver is unstated. A senior candidate says plainly when they suspect this is happening rather than pretending the objection was purely rational.
• Preserving a role is not the same as granting a veto. The trade is scoping what the stakeholder keeps control over, not surrendering the decision.

Direct answer

For a large enterprise retaining 3 years of security logs, a four-tier design, hot, warm, cold, and archival, each with its own storage technology and an explicit query service-level agreement (SLA), is what lets the organization satisfy the full 3-year window without paying the same per-byte cost across all of it; the core discipline is matching each tier's query-speed guarantee to how the data at that age actually gets used, since almost all real investigative and correlation activity happens against recent data, and the further back in time a query reaches, the more latency an organization can reasonably accept in exchange for cost.

Structured elaboration

Cost vs. retrieval-time trade-off, stated directly: each tier transition trades an order of magnitude or more in query latency for a substantial reduction in per-byte storage cost; the organization's real design decision is choosing where each tier boundary sits, informed by how often data of that age actually gets queried in practice (which should itself be measured and revisited periodically, not fixed once and assumed correct for the life of the program).

Worked example

Assume this enterprise ingests 50,000 events per second, at the same 500-byte average event size assumption used elsewhere: $50{,}000 \times 500 \times 86{,}400 = 2.16 \times 10^{12}$ bytes/day, 2.16 TB/day raw.

• Hot (30 days): $2.16 \times 30 = 64.8$ TB raw; with 1.3x index overhead and 2x replication, $64.8 \times 1.3 \times 2 = 168.5$ TB indexed.
• Warm (150 days, months 2-6): $2.16 \times 150 = 324$ TB raw; with 1.3x overhead and 1x replication (single copy on cheaper storage), $324 \times 1.3 = 421.2$ TB indexed.
• Cold (185 days, months 7-12): $2.16 \times 185 = 399.6$ TB raw; compressed at 6:1 (a lighter compression ratio than the archival tier, since cold still needs some structure for minutes-scale retrieval), $399.6 / 6 = 66.6$ TB.
• Archival (2 more years, 730 days): $2.16 \times 730 = 1{,}576.8$ TB raw; compressed at 10:1 (heavier compression is viable since this tier trades away fast retrieval entirely), $1{,}576.8 / 10 = 157.7$ TB.

Total tiered 3-year footprint: $168.5 + 421.2 + 66.6 + 157.7 = 814.0$ TB. Against the counterfactual of keeping all 3 years at hot-tier density and replication, $2.16 \times 365 \times 3 \times 1.3 \times 2 = 6{,}149.5$ TB, the tiered design uses about $6{,}149.5 / 814.0 \approx 7.6$ times less storage for the identical 3-year retention obligation, the concrete justification for the four-tier structure over a flat design.

Trade-offs and pitfalls

• GDPR right-to-be-forgotten, and why it usually does NOT force per-record deletion from a security-log archive: the General Data Protection Regulation's erasure right (Article 17) carries explicit exemptions, most relevantly compliance with a legal obligation (Article 17(3)(b)) and the establishment, exercise, or defense of legal claims (Article 17(3)(e)), both of which routinely justify continuing to retain security audit logs despite an individual erasure request, PROVIDED the retention is proportionate, time-bound, and documented as such. The practical engineering implication is usually not "build per-user surgical deletion into a compressed archival tier" (a genuinely difficult capability to build correctly at this scale) but rather documenting the lawful basis for retaining security logs specifically, minimizing which personal fields are captured in the first place (data minimization), and applying pseudonymization to fields not strictly necessary for the security purpose, so what IS retained is defensible on its own terms rather than needing to be deleted on request.
• PCI DSS-specific prohibition for a fintech/payment-processing organization: regardless of retention tier, payment-related log entries must never capture full Primary Account Number (PAN) in a reversible form outside PCI's own permitted storage controls, and must never capture prohibited sensitive authentication data at all (the card's CVV2/CVC2 value, PIN blocks, or full magnetic-stripe track data) post-authorization, even for security-monitoring purposes; this is a data-minimization requirement enforced at the LOGGING SOURCE (redact or tokenize before the event is ever emitted), not something a retention-tiering policy downstream can retroactively fix.
• Common mistake: sizing compression ratios uniformly across tiers rather than letting each tier's own retrieval-speed requirement drive how aggressively it can be compressed; the cold tier's lighter 6:1 ratio versus the archival tier's heavier 10:1 in the worked example above is not an arbitrary choice, it reflects that cold still needs viable minutes-scale retrieval while archival has fully traded that away.
• Common mistake: treating tier boundaries as permanent once set; actual query patterns against each age range should be measured periodically (which age of data investigators and correlation rules ACTUALLY reach for) and the boundaries adjusted, since a boundary set once at program launch can drift out of alignment with real usage as the organization's detection content and investigative needs evolve.

Direct answer

Give the startup a small set of measurable triggers, not a vibe: sustained traffic growth that vertical scaling can no longer absorb, a build or deploy pipeline slow enough to block multiple teams, incidents where one team's unrelated change repeatedly takes down another team's feature, and enough independent teams that they're routinely waiting on each other to ship. If none of those are true yet, stay on a well-structured monolith and invest in automation instead; splitting before any trigger fires adds real operational cost for a benefit the team can't cash in yet.

Structured elaboration

Triggers, with what each one actually signals

Default for an MVP-stage team
For a brand-new MVP with one or two engineers and no confirmed product-market fit yet, none of these triggers are even reachable: default to a single, well-organized modular monolith (one deployable codebase with clear internal module boundaries), because splitting now means guessing at service boundaries before there's usage data to draw them correctly, and redrawing a wrong boundary between two live services is far more expensive than redrawing it between two modules in one codebase.

When triggers do fire
Extract incrementally using the strangler pattern (pulling one bounded, high-value piece out from behind the existing interface at a time), named here without re-deriving its mechanics, and check that team structure already matches the boundary being proposed (Conway's Law, named only): if a small team doesn't already own the candidate service end to end, extracting it just relocates the coordination problem onto the network.

Worked example

A 25-person engineering org split into four product teams sees average deploy lead time climb past 45 minutes as all four teams queue behind one release train, and in the last quarter, three of nine production incidents were an unrelated team's change breaking a different team's feature through shared code. That's two of the four triggers above (deploy lead time, blast radius) firing at once, on an org that already has team boundaries to extract along (the third trigger). This combination, not any single signal alone, is what justifies picking one bounded, high-value capability, say the search or recommendations code, since it is already the most independently used and owned piece, as the first strangler-pattern extraction, rather than a big-bang rewrite of the whole system into services.

Trade-offs & pitfalls

• Extracting the first service based on which code is oldest or ugliest rather than which extraction actually relieves a measured trigger.
• Splitting without the operational maturity (CI/CD automation, monitoring, on-call ownership) to run more than one deployable thing, which adds cost with no offsetting benefit.
• Treating "we might need to scale eventually" as a trigger on its own; without a load number or a deploy-lead-time number attached, it's speculation, not evidence.
• What separates a senior answer: naming the first service to extract and why, based on a specific measured pain point, rather than describing microservices in the abstract.

Direct answer
The conversation matters less than the sequence: separate stabilizing the consequence from the coaching conversation, then run the retrospective as blameless (focused on the system and process, not the individual) so the mentee stays engaged rather than defensive, and turn what's learned into a durable safeguard, not just a one-time talk.

Sequence: stabilize, then convene

• First, contain the actual consequence, ideally with the mentee involved rather than sidelined; solving it together protects both the outcome and their sense of ownership.
• Only after that, run the retrospective. Doing it while still firefighting mixes urgency with reflection and makes the mentee defensive.

The blameless postmortem as the concrete framework

• Ground rules stated up front: the goal is understanding the system and sequence of events, not assigning blame to the individual who happened to be the one who made the change.
• A neutral facilitator, or a rotating one across the team so it isn't always the same person in that role, helps keep the conversation from drifting toward blame, especially when the mentor is also the mentee's manager.
• Reconstruct a factual timeline first, before any discussion of what should have happened differently; jumping to "here's what you should have done" before the facts are laid out reads as judgment, not diagnosis.
• Sensitive details (who wrote the specific line, private context) get anonymized in the written artifact where possible, since the point is the process, not the person.
• The output is a written root-cause artifact with concrete action items, not just a conversation that ends when the meeting does.

Coaching the mentee specifically

• Ask them to walk through their own reasoning at each decision point, rather than you narrating what went wrong; this builds their own diagnostic skill for next time instead of just transmitting your conclusion.
• Separate the mistake from their competence explicitly, out loud; the message is "the system let this happen too easily," not "you're bad at this."

When the mistake isn't just one person's

• Sometimes the visible consequence comes from multiple people's individually reasonable changes interacting badly (a cross-team or cascading failure), not one person's error. The blameless frame matters even more here: the postmortem needs to surface the interaction, not scapegoat whichever team's change happened to be the trigger. The coaching conversation with your mentee shifts from "what would you do differently" to "how do you think about the blast radius of a change you don't fully control," since the lesson is about system boundaries, not individual judgment.

Worked example
A mentee I was supporting shipped a change that caused a visible, customer-facing issue. The first move was working alongside them to stabilize it, not taking over and pushing them out of the loop. Once it was stable, I ran a blameless postmortem with the mentee, a couple of the affected team members, and a neutral facilitator: we built a timeline from logs and commits before discussing anything about what should have happened, and the mentee walked through their own reasoning at each step rather than me presenting conclusions.

The root cause turned out to be a gap in the pre-merge checks, not a lapse in the mentee's judgment; the change was reasonable given what the tooling surfaced at the time. The written follow-up had concrete items (a new check added to the pipeline, an update to the review checklist) rather than just "be more careful." A few weeks later, in a separate incident, another engineer's change was caught by that new check before it shipped, which is the kind of signal that the fix generalized rather than just patching one person's blind spot.

Trade-offs and pitfalls

• The common junior mistake is either being too harsh in the moment (public correction, visible frustration), which teaches the mentee to hide mistakes next time, or being too soft and skipping the structured retrospective entirely, which loses the systemic fix.
• Blameless doesn't mean consequence-free; if the pattern repeats after a genuine fix and support, that's a different, harder conversation about capability or fit, not a postmortem.
• Anonymizing sensitive details in the artifact protects psychological safety (people's sense that they can admit a mistake without fear of punishment), but overdoing it (scrubbing so much nobody can learn the specific mechanism) makes the postmortem useless as a teaching tool. The balance is protecting the person while keeping the mechanism specific.

Direct answer. I would assess first, contain second, and decide integrate versus isolate on evidence. Until baseline controls are in place I would keep the acquired environment separated from the parent network. The business sponsor is accountable for the decision, the CISO recommends, and legal and compliance are involved before the deal closes and again at day 0. This is a governance design, not legal advice.

Terms. Diligence is the investigation of the target company before the deal closes. Day 0 is the day ownership transfers. Network segmentation splits a network into zones with firewall rules between them. A jump host is a hardened intermediate server that administrators must pass through, giving one monitored entry point. A privileged-access tool vaults and records administrator credentials. Immutable backups cannot be altered or deleted for a set period, so ransomware cannot wipe them.

What to assess first.

• Data map: what regulated data exists, in which systems, how many records, which jurisdictions and contractual obligations.
• Exposure: internet-facing systems, remote access, privileged accounts, backups.
• Legacy risk: unsupported systems, patch status, ability to add multi-factor authentication or logging.
• Third parties, past incidents, and gap analysis against the central controls.

Who decides. An integration steering group makes the integrate-or-isolate call: sponsor accountable, CISO and privacy lead recommend, legal, compliance and IT consulted, executive sign-off for anything that changes the parent's risk. Criteria: current exposure, regulatory duties, cost, time to business value, and whether the parent needs the data.

Legal and compliance involvement. During diligence (breach history, regulatory obligations, data-transfer terms; for example, finding that the target had a ransomware incident with backups stored on the same network would push the call toward isolation and a price or indemnity discussion), at close (notification duties, contracts, data processing terms), and at each design decision touching regulated data.

Sequencing against risk.

Interim risk mitigation. Network segmentation, administrator access through a jump host or privileged-access tool (legacy systems often cannot do MFA natively), logging to the central monitoring platform, immutable backups, and a freeze on new data flows.

Pitfall. Connecting the networks on day 1 for convenience imports the acquired company's risk.

Use Open Policy Agent (OPA), a general-purpose policy engine, with its policy language Rego to compute a single allow decision as the AND of three independent checks against the incoming request: the caller's JSON Web Token (JWT, a compact, signed way of encoding claims about who someone is), an access-control list, and a device posture score. Each clause enforces a distinct part of the zero trust story: who is calling, what they're allowed to do, and whether the thing presenting that identity is healthy enough to be trusted with it.

Approach

Model the request as input (the caller's JWT claims, the target service name, and the device posture) and keep the access lists and posture thresholds in a separate data document, so a security team can update who's allowed without touching the policy logic itself.

Code (Rego v1)

package service.authz

import rego.v1

default allow := false

allow if {
	input.jwt.aud == input.target_service
	input.jwt.role in data.access_lists[input.target_service]
	input.device.posture_score >= data.posture_thresholds[input.target_service]
}

Control data (data.json):

{
  "access_lists": {
    "billing-service": ["payments-writer", "payments-admin"]
  },
  "posture_thresholds": {
    "billing-service": 70
  }
}

A request that should be allowed (input.json):

{
  "jwt": {"aud": "billing-service", "role": "payments-writer"},
  "target_service": "billing-service",
  "device": {"posture_score": 82}
}

Run it:

opa eval -d policy.rego -d data.json -i input.json "data.service.authz.allow" --format pretty

Output: true

Change only posture_score to 55 in the input (below the 70 threshold) and re-run the same command: the output flips to false, and the same happens if jwt.aud is set to a different service than target_service.

Key points: what each clause protects against

• input.jwt.aud == input.target_service: protects against a token issued for one service being replayed against a different one. Without an audience check, a token that's valid but meant for the inventory service could be presented to the billing service and pass identity verification even though it was never intended for that call.
• input.jwt.role in data.access_lists[...]: protects against a caller who is correctly authenticated but not authorized for this specific service. Identity (who you are) is kept separate from entitlement (what you're allowed to do), which is the least-privilege half of the model.
• the posture check: protects against a compromised or non-compliant device or workload using otherwise-valid credentials. Even a correctly-scoped, correctly-authenticated caller shouldn't get access if the thing presenting that identity fails a health check. This is the "continuous verification" piece of zero trust: trust is re-evaluated against the current state of the caller, not granted once and assumed to hold.

Complexity and edge cases

Evaluation is a constant number of map lookups per request against the loaded data document, so the cost that actually scales is the size of data and how often it's refreshed, not the policy logic itself. Edge cases worth testing: a missing key anywhere in the lookup chain should resolve to undefined and therefore deny, matching the default allow := false; a request with posture_score entirely absent should fail closed rather than being treated as passing; and a role that exists on some OTHER service's access list but not this one's should still deny, since the lookup is keyed strictly by target_service.

Trade-offs and pitfalls

Hardcoded, hand-maintained access lists don't scale as the number of services grows; production setups usually generate data from a service catalog or a CI pipeline rather than editing it by hand. If this policy runs behind a centralized Policy Decision Point (PDP, the component that computes authorization decisions) rather than as a local OPA sidecar, add a timeout and an explicit fail-closed or short-TTL-cached behavior for when the PDP is unreachable, since otherwise an identity or posture system outage silently becomes an outage of all service traffic.

Overview / Goal
Provide a concise, executive-ready KPI set that proves controls are effective, demonstrates improving security posture, and supports audit evidence.

Core KPIs & Definitions

• Control Coverage: % of in-scope assets/processes with required control implemented
  • Calculation:

Control Coverage = (Number of assets with control implemented / Total in-scope assets) * 100%

• Mean Time to Detect (MTTD): average time from incident start or control failure to detection

MTTD = Sum(detection time - start time) / Number of incidents

• Mean Time to Remediate (MTTR): average time from detection to remediation/closure

MTTR = Sum(remediation time - detection time) / Number of incidents

• Remediation Velocity: % of findings closed within SLA window (e.g., 30/60/90 days)
• Evidence Freshness: median age of supporting evidence per control (days)
• Control Exception Trend: rolling 90-day count and severity-weighted rate of exceptions

Supporting Metrics

• False-positive rate (detection quality)
• Repeat-finding rate (recurrence)
• Audit pass-rate by control family

Dashboard Layout (Executive / Audit Tabs)

• Top row (Executive summary): Overall Risk Score, Control Coverage, MTTD, MTTR, Remediation Velocity (gauges)
• Middle row: Trend charts (30/90/365 days) for MTTD, MTTR, Exceptions by severity
• Lower row: Heatmap of coverage by business unit, evidence freshness table, top 10 open findings with age and owner
• Audit view: Per-control evidence links, timestamped evidence history, exception approvals

Thresholds / Targets

• Set targets by risk tier:
  • Critical controls: Coverage >= 99%, MTTD < 1 hour, MTTR < 24 hours, Remediation Velocity 95% within SLA
  • High: Coverage >= 95%, MTTD < 4 hours, MTTR < 72 hours, Remediation Velocity 90%
  • Medium/Low: progressive relaxed targets
• Evidence Freshness target: < 30 days (or per control-specific cadence)
• Exception trend: target zero increasing trend; define alert when 3-month trend slope > +10%

Implementation & Governance

• Map KPIs to control owners, automate data collection from SIEM, GRC, ticketing, CMDB
• Quarterly review with execs + monthly operational review
• Use targets as control SLAs; escalate deviations via RACI and runbooks

Why this works: combines coverage, speed, quality, and evidence to show both technical effectiveness and auditability, with thresholds tied to business risk.