DoorDash Security Architect (Entry Level) Interview Preparation Guide

High-level approach (Board-facing)

• Present a concise Security Risk Appetite: what business outcomes we will not jeopardize (e.g., protect customer data confidentiality and platform availability), the categories of risk tolerated (residual third‑party risk, low-severity exceptions), and measurable boundaries.
• Use a one‑page statement + risk heatmap and 12‑month trend dashboard. Explain trade-offs in business terms (cost, time-to-market, customer trust) and request board approval for the stated appetite and exception process.

Translate to operational guardrails (Engineering/Product)

• Convert appetite into guardrails mapped to CI/CD, cloud config, incident response and vendor selection. Examples: mandatory SCA/SAST scans in pipelines, IaC compliance checks, runtime WAF for internet‑facing services, and mandatory threat models for new high‑impact features.

Measurable thresholds (examples)

• Externally‑exposed critical vulnerabilities: 0 critical externally‑reachable CVEs older than 7 days.
• Mean Time To Detect (MTTD): <= 24 hours for prod incidents affecting integrity/confidentiality.
• Patch/Remediation Time (MTTR for critical): <= 72 hours from detection to mitigation (or compensating control).

Enforcement mechanisms

• Preventative: CI/CD gates that block merges if SAST/SCA/IaC checks fail; automated cloud policy enforcement (OPA/Cloud Custodian).
• Detective: centralized telemetry + SIEM alerts with automated escalation; weekly security dashboard emailed to execs.
• Corrective/Accountability: SLOs for security thresholds included in team OKRs; exceptions require documented risk acceptance signed by CISO + business owner; regular audit and tabletop exercises; compensation/bonus alignment and monthly remediation scorecards reviewed by security leadership and reported to the board.

Why this works

• Board sees business impact and approved boundaries; engineering gets actionable, automatable controls and clear SLAs; product owners retain a formal exception path tied to measurable oversight.

Clarify requirements & constraints

• Only API-level access for a specific feature; read/write scopes defined in contract; SLA for revocation ≤ 1 minute; no downstream data export of PII; audit reports required.

High-level architecture

• Per-vendor tenant logically isolated behind an API Gateway/Proxy (e.g., Kong/Apigee/NGINX) → Vendor-specific micro-proxy fleet → Backend services.
• Identity provider + short-lived token broker (OAuth 2.0 client credentials + mTLS) issuing ephemeral JWTs per request.
• Data-proxy layer for filtering/transforming responses before leaving the boundary.

Core components & controls

• Per-vendor credentials: unique client_id/secret and mTLS certs stored in KMS/secret manager; secrets rotated weekly or on demand.
• Ephemeral tokens: token broker mints JWTs with fine-grained scopes and 1–5 minute TTL; refresh requires re-auth with mutual TLS + signed JWS proof.
• Least privilege: scope-based RBAC at gateway and service mesh enforcement (Envoy + RBAC filters).
• Per-vendor tenants: network segmentation (VNets), rate-limiting, quotas, and per-tenant API keys to prevent cross-tenant access.
• Data filtering/proxying: DLP rules at proxy to redact PII, block disallowed fields, and enforce schema validation.
• Fine-grained logging: structured, immutable logs (request/response hashes, token id, vendor id, redaction markers) shipped to tamper-evident SIEM (WORM storage).
• Alerting & detection: anomaly detection (rate, data volume, unusual endpoints) with pre-authorized playbooks and automated throttling + quarantine.
• Rapid revocation: central revocation service that blacklists tokens, revokes client secrets in KMS, and triggers gateway policy updates via config push (targeted within <60s).
• Contractual & compliance: signed API usage policy, allowed endpoints list, periodic attestation reports (access logs, rotations, alerts), and SOC/pen test clauses.

Data flow

• Vendor call → API Gateway (mTLS + JWT validation) → Rate limit + scope check → Data proxy (filter/redact) → Backend → Response filtered → Logged & monitored.

Trade-offs & rationale

• Short TTLs + mTLS balance usability and security; proxy filtering reduces backend complexity; per-vendor tenants increase ops cost but dramatically reduce blast radius.
• Prioritize detection and rapid revocation over long-lived credentials.

Metrics & success criteria

• Time-to-revoke ≤ 60s, no PII leaks in redaction tests, <0 false negatives in high-risk alerts, weekly credential rotation compliance > 99%.

Direct answer

Adaptive, risk-based multi-factor authentication (MFA) evaluates a transaction, not just a login, and asks for extra proof only in proportion to how unusual that specific action looks for that specific user: a routine transfer to a familiar payee stays frictionless, while a large transfer to a brand-new recipient from a new device triggers a stronger step-up challenge. The design has to answer two questions well: what combination of signals is worth checking on every transaction, and what happens to the user experience and to security when the risk engine itself cannot answer in time.

Structured elaboration

Risk signals. Combine signals that are each individually informative but not individually decisive: whether the device has been seen before for this user, whether the request's location and timing are consistent with the user's own travel and access patterns (an impossible-travel-style geo-velocity check), where the transaction amount falls in this user's own historical distribution (a request far above their typical amount is more worth scrutinizing than an average one), and whether the recipient or destination is one this user has paid before or is entirely new. Each of these has innocent explanations on its own (a new device from a phone upgrade, a large amount for a legitimate one-time purchase), which is exactly why the engine combines them rather than triggering step-up from any single signal.

How the risk engine integrates with the authentication flow. The risk evaluation sits inline in the transaction-authorization path itself, not only at login, because the risk profile of "log in and look around" is different from "authorize a large transfer," and a session that was low-risk at login can still authorize a high-risk action later in the same session. The engine is called synchronously at the moment the sensitive action is submitted, returns a risk tier, and the authentication flow branches on that tier before the transaction is allowed to proceed, rather than evaluating risk only once per session and reusing that verdict for every subsequent action.

Step-up authentication options. Map the tier to a proportionate challenge: a low tier requires no additional step; a medium tier requires a standard second factor (a time-based one-time password or a push approval); a high tier requires the strongest available method, a hardware-backed passkey (WebAuthn/FIDO2, a phishing-resistant standard that cryptographically binds the credential to the requesting site), precisely because the situations that reach the high tier are also the ones most likely to be an active social-engineering attempt, where phishing resistance matters most.

Latency and UX trade-offs. Every signal the engine evaluates (device history lookup, historical amount distribution, recipient novelty check) adds real latency to an action the user expects to complete quickly; a widely cited usability guideline treats roughly a tenth of a second as the threshold below which an action feels instantaneous, which is a useful design target even though the exact acceptable budget for a given product is a judgment call, not a universal constant. If the risk engine cannot respond within that budget, or is unavailable entirely, the flow needs an explicit fallback decision: failing open (allow the transaction with no step-up) protects availability but silently drops the fraud control exactly when it might matter most; failing to a fixed baseline step-up (always require the medium-tier challenge when the engine is unavailable) is the safer default, since it bounds the added friction to a known, tolerable level instead of either extreme.

Privacy and compliance considerations. Coarser signals (device identity, general location, transaction amount) are lower-sensitivity than fine-grained behavioral telemetry (keystroke rhythm, mouse movement, detailed on-device sensor data), and the fine-grained end of that spectrum draws materially more privacy and data-protection scrutiny in many jurisdictions. The design principle is data minimization: collect only the signals the risk score genuinely needs, disclose that behavioral risk signals are collected as part of fraud prevention, and set an explicit, bounded retention period for the raw signal data rather than keeping it indefinitely once the risk decision has been made.

Worked example

flowchart LR
    TX[Transaction request] --> SIG[Collect risk signals]
    SIG --> ENGINE[Risk engine: weighted score]
    ENGINE -->|below low threshold| ALLOW[Allow, no step-up]
    ENGINE -->|between thresholds| STEP[Step-up: TOTP or push]
    ENGINE -->|above high threshold| BLOCK[Hardware key step-up or manual review]

Take a simple, auditable weighted-sum risk score with weights that sum to 1 so the score stays in $[0,1]$: $w_{device}=0.3$ (new device), $w_{geo}=0.3$ (geo-velocity anomaly), $w_{amount}=0.25$ (amount percentile relative to this user's own history), $w_{recipient}=0.15$ (recipient novelty), each signal scored 0 (unremarkable) to 1 (maximally anomalous):

Transaction A: a routine transfer from a recognized device, no geo anomaly, a mid-range amount for this user (60th percentile of their own history, scored 0.4), to a payee they have paid before ($s_{recipient}=0$):

That is comfortably below a low threshold (say 0.3), so the transaction proceeds with no step-up. Transaction B: the same user, but from a device never seen before, with a geo-velocity result that fails the impossible-travel check, an amount at the 90th percentile of their history, to a recipient they have never paid:

That clears a high threshold (say 0.7), so the transaction is routed to the strongest step-up: a hardware-backed passkey challenge, or, if the user has not enrolled one, a manual review hold rather than falling back to a weaker method that would defeat the point of the high-risk classification. Note the gap between these two scores (0.10 versus 0.975) is exactly why a single flat MFA policy is the wrong design here: applying the same challenge to both transactions either annoys the user in case A for no security benefit, or under-protects the user in case B.

Trade-offs and pitfalls

The core trade-off is exactly the latency-versus-signal-richness tension named above: more signals generally make the risk score more accurate, but each one adds a lookup that has to complete before the transaction can proceed, and a slow, maximally-thorough risk engine that adds a full second of visible lag to every checkout will train users to distrust or avoid the product regardless of how accurate its fraud detection is.

A common pitfall is choosing threshold values once at launch and never revisiting them; fraud patterns and legitimate user behavior both drift over time, and thresholds tuned for last year's transaction-amount distribution will misclassify this year's normal activity as anomalous (or vice versa) unless they are periodically recalibrated against current data. A second pitfall is failing open silently when the risk engine times out: an outage in the fraud-detection path should not quietly become "no fraud detection today" with no record of it, both because that is a security gap and because it is exactly the condition an attacker who has learned to trigger engine timeouts would try to exploit. A third pitfall is collecting far more behavioral signal than the score actually uses, on the theory that more data might be useful someday; every signal collected is data that has to be secured, disclosed, and eventually deleted, and collecting it without a demonstrated use in the actual scoring function is pure downside from a privacy and compliance standpoint.

Direct answer

Start from the decision the ritual has to produce, not the calendar slot. Invite only the people who can actually make or unblock that decision, not everyone with an interest in the topic. Set the cadence to match how fast the underlying work changes, and instrument the ritual itself so you can tell whether it is producing decisions or just producing a meeting.

Structured elaboration

1. Name the single output first. Before picking attendees or a cadence, write down the one decision or artifact the ritual exists to produce (for example, "which cross-team dependencies get prioritized this cycle"). If you cannot name it, you are designing a status meeting, not a working ritual.
2. Minimum viable roster. Invite decision-owners, not stakeholders who only want visibility. A rule of thumb: if someone in the room has to say "let me check with my team" before committing to anything, they are a proxy, not an owner, and the room is one person too big.
3. Cadence tied to decision half-life. Match the frequency to how fast the thing being decided actually changes, not to habit. Too frequent and there is nothing new to decide between sessions; too infrequent and blockers age past the point where the ritual could have caught them early.
4. Session shape. Require light pre-work (so room time is spent deciding, not getting everyone up to speed), time-box the agenda to the decision at hand, and keep a running decision log so the group is not re-litigating the same question every time.
5. How you would know it is working (leading indicators, not attendance):

Worked example

Say the ritual is a recurring dependency review for a platform initiative touching four delivery teams. The roster is the four team leads plus the program owner as facilitator, five to six people, not the fifteen who are merely affected. The teams plan in two-week sprints, so a dependency raised today needs to be resolved before the next sprint's planning starts or it blocks that team. That reasoning sets the floor: the review has to run at least once per sprint, so biweekly, thirty minutes, is the minimum cadence that keeps blockers from aging past one planning cycle. A weekly cadence would mean showing up with nothing new most weeks; a monthly one would let a blocker sit for up to two sprints before anyone with authority to fix it even hears about it.

Trade-offs & pitfalls

• The most common wrong turn is defaulting the invite list to "everyone affected." The ritual becomes a broadcast, decision-owners tune out because nothing gets decided with fifteen people in the room, and the ritual quietly becomes theater.
• Choosing cadence by convention ("let's do it weekly like standup") instead of the decision's actual refresh rate produces either a hollow meeting or a slow one, and both erode trust in the ritual over time.
• Junior candidates describe running the meeting well. Senior candidates describe designing the meeting so it can be evaluated and retired: a built-in check for whether it is still adding value, and a plan for what replaces it if it is not.
• Skipping the decision log is a quiet failure mode: without a record of what was already decided and why, the group re-opens the same debate every session and the ritual's real cost shows up as fatigue, not as an obvious complaint.

Overview (role perspective)
As a Security Architect I design ZTA to shift trust from perimeter controls to identity, context, and continuous validation. Below are core tenets, a concrete design implication for each, and a short example.

Never trust, always verify

• Principle: Treat every actor and device as untrusted until authenticated and authorized.
• Design implication: Strong identity-centric controls (IAM + conditional access).
• Example: Require device posture check and conditional access policy before granting access to CRM.

Assume breach

• Principle: Design for compromise; limit blast radius and detect lateral movement.
• Design implication: Microsegmentation and east-west traffic monitoring.
• Example: Segment prod workloads; if an app is breached, it cannot access database subnet.

Least privilege

• Principle: Grant minimum rights required, time-bound and role-based.
• Design implication: Role-based access control (RBAC) + just-in-time (JIT) elevation.
• Example: Devs get time-limited sudo via PAM for deployments, not persistent admin.

Continuous authentication/authorization

• Principle: Re-evaluate trust based on session context and telemetry.
• Design implication: Continuous risk scoring (UEBA) feeding adaptive policies.
• Example: Re-authenticate or revoke session when anomalous geolocation detected.

Encryption in transit and at rest

• Principle: Protect confidentiality and integrity across flows and storage.
• Design implication: Enforce TLS everywhere, use KMS-backed encryption and HSMs for keys.
• Example: mTLS between services and KMS-managed DB encryption keys to prevent data exposure if a host is compromised.

Overview / Purpose
Describe scope, audience (compliance reviewers, auditors, ops), and regulatory target (e.g., PCI-DSS, HIPAA, SOC 2). State assumptions and system owner.

Required Sections & Artifacts

• System boundary & context: high-level architecture diagram showing trust zones, external parties, and business functions.
• Dataflow diagrams (DFDs): at least 3 levels (context, process, detailed) showing data classification, storage, and transformations.
• Network diagrams: L3/L2 segments, firewalls, load balancers, NAT, VPNs, WAFs, and connectivity to cloud services and external partners.
• Component inventory & deployment map: hosts, containers, services, third-party SaaS; versions and owners.
• Control mapping matrix: list technical, administrative, physical controls with implementation details.
• Risk & threat model: top threats, likelihood, mitigations.
• Operational runbooks: onboarding, patching, incident response, backup/recovery, access revocation procedures.
• Evidence pack: config snippets, policies, logs retention proof, encryption keys handling, pen test summary.

Mapping Controls to Regulatory Requirements

• Create a Traceability Matrix (rows = regulatory clause / audit criteria; columns = control ID, implementation location, owner, evidence links, test procedure).
• Example: PCI-DSS 3.4 (Protect PAN) → Control ID ENC-01: AES-256 at rest on DB cluster; Implementation: DB encryption-at-rest + KMS; Evidence: KMS policy, encryption config, key rotation logs; Test: verify key use via KMS audit.
• Use unique control IDs, map multiple controls to single requirement when needed, and show gap/risk status.

Practical Notes

• Prioritize reviewers’ workflows: include executive summary, quick-glance compliance status, and appendix with raw evidence.
• Keep diagrams source files (Visio/Draw.io) and export PDFs. Maintain versioning and change log for auditability.

Direct answer: For a web app using cookie-based session tokens, CSRF, session fixation, and XSS share the same underlying trust the browser places in cookies, but each needs its own layered defense; no single control covers all three. CSRF specifically works because the browser automatically attaches a user's session cookie to any request sent to a site, even one triggered by a different, attacker-controlled page - so a forged request looks legitimate to the server unless something explicitly checks for that.

Structured elaboration, attack surface and layered mitigations per attack:

Worked example connecting the three. Consider a session-fixation attack as the entry point: an attacker gets a victim to log in under a session ID the attacker planted (via a crafted link). Now the attacker's known session ID is authenticated. From there, even without stealing anything, the attacker could ride that session to perform CSRF-protected actions if the CSRF token itself was also generated at session-creation time and thus also known to the attacker (a common mistake: binding the CSRF token to the pre-fixation session rather than regenerating it alongside the session ID). This is why session regeneration on login has to reset BOTH the session identifier and any session-bound CSRF token together, not just one of them.

Trade-offs and pitfalls: SameSite=Strict is the strongest CSRF mitigation but breaks legitimate cross-site navigation into the app (a user clicking a link from an email lands unauthenticated, since the cookie isn't sent on that top-level navigation); Lax is the common practical default, which still sends the cookie on top-level GET navigations but not on cross-site POSTs or embedded requests, covering the actual CSRF attack shape while preserving normal linking. HttpOnly and CSP are complementary, not redundant: HttpOnly protects the cookie's confidentiality even under successful XSS, while CSP tries to prevent the XSS from executing at all; a defense-in-depth posture wants both, since either can fail independently (a CSP misconfiguration, or a cookie set without HttpOnly by an older piece of legacy code).

30/60/90-day Cloud Security Ramp Plan (Security Architect)

Days 0–30 — Discover & Baseline

• Activities: Stakeholder interviews, inventory of accounts/projects, map existing identity, networking, and logging.
• Deliverables: Current-state architecture diagram, asset inventory, high-level threat model, gap list vs. baseline controls (IAM, networking, logging).
• Verify competence: Walkthrough with infra and app owners; peer review of diagram and gap list; quiz/demo of access paths and basic console tasks.

Days 31–60 — Design Controls & Risk Assessment

• Activities: Prioritize risks, design guardrails (IAM roles, VPC segmentation, centralized logging), define compliance mapping.
• Deliverables: Target-state security architecture, prioritized risk assessment with mitigation plans, PoC for one control (e.g., org-wide IAM policy or centralized logging pipeline).
• Verify competence: Present architecture to security leadership; run tabletop on prioritized risk; demo PoC with test accounts and automated validation scripts.

Days 61–90 — Implement Roadmap & Operationalize

• Activities: Implement selected controls, automate compliance checks, create runbooks and monitoring dashboards, handoff/training.
• Deliverables: Implementation plan with milestones, automated policy-as-code (examples), runbooks, monitoring dashboards, metrics/KPIs.
• Verify competence: Successful pilot deployment, red-team/scan results showing reduced risk, knowledge transfer session with recorded demos and checklist sign-offs.

Overview / Approach
As Security Architect I run a combined technical, contractual and operational assessment, score risk, and produce a residual-risk brief for leadership and legal with recommended mitigations and acceptance statements.

Technical checks

• Data protection: encryption at rest and in transit; key management (customer-managed keys / HSM / KMS; key rotation, key separation).
• Access control: MFA, SSO/SAML, SCIM, least-privilege RBAC, privileged access reviews.
• Multi-tenancy & data segregation: tenant isolation model, row/column encryption, per-tenant keys, encryption context.
• Logging & monitoring: immutable audit logs, retention, alerting, integration with SIEM, integrity checks, admin activity logging.
• Availability & backup: RTO/RPO, encrypted backups, geo-resilience.
• Vulnerability & change management: patch cadence, pen tests, third-party/CI pipeline security.
• Network controls: VPC endpoints, private connectivity, egress controls.
• Secure development: SAST/DAST, dependency management, CVE remediation SLAs.
• Breach controls: detection time, forensics capabilities, notification APIs.

Contractual checks

• Signed BAA that covers PHI uses/scopes, subprocessor flow-down, termination & data return/destruction.
• SLAs for availability, security incident notification timelines (e.g., 72h), breach notification responsibilities and costs.
• Audit rights: SOC2/ISO/ISO27001 reports, penetration test results, right to perform audits or third-party assessments.
• Data residency and lawful processing clauses, liability & indemnification limits, cyber insurance proof.

Operational checks

• Vendor IR plan, playbooks, tabletop exercise cadence with our team.
• Employee screening, security training, least-privilege ops, separation of duties.
• Onboarding/offboarding processes, change-control transparency, maintenance windows.
• Escalation paths and single point-of-contact for compliance.

Documenting residual risk

• Create a vendor risk register entry with: risk statement, likelihood, impact, current controls, risk score, and proposed mitigations.
• For each residual risk include compensating controls, deadline/owner, and acceptance recommendation.
• Produce a 1–2 page executive brief for leadership: top 5 risks, legal concerns, recommended contractual language, go/no-go recommendation.
• Provide a legal annex listing required BAA clauses, audit artifacts, and required acceptance signature (CISO + Legal + BU owner).
• Schedule periodic review and remediation tracking in governance meetings.

This approach ensures HIPAA coverage across tech, contract, and ops, and gives leadership/legal a concise risk-and-acceptance package.

Direct answer

With scarce direct telemetry, the approach is to treat "this service is currently compromised" as a hypothesis with a weakly-informed prior probability, then update that prior with whatever weak indicators do exist, one at a time, using Bayes' rule. Priors come from whatever base rate is available, an industry benchmark, a small internal calibration sample, or a deliberately conservative guess when nothing else exists, kept wide (uncertain) rather than falsely precise. Likelihoods for each indicator come from however small a calibration sample can be assembled (red-team or purple-team exercises are a good source), and the update itself is exact arithmetic, not a judgment call, which is exactly what makes this method more defensible than an unstructured gut read even when the underlying data is thin.

Structured elaboration

Choosing priors

• Start from the best available base rate. An industry telemetry report, a security vendor's published statistics, or a comparable prior incident rate for similar assets are all reasonable starting points; where none of these exist, a conservative, deliberately wide prior (closer to uninformative) is safer than an invented precise one.
• Represent the prior as a distribution, not a point, when the stakes justify it. For a binary hypothesis (compromised or not), a Beta distribution is the natural conjugate choice: a Beta(a, b) prior can be read as "a positive pseudo-observations and b negative pseudo-observations of prior belief," so a wide, weak prior uses small a and b (worth few observations), and a confident prior uses larger values.
• For a genuinely novel threat with no comparable base rate at all, start close to an uninformative prior (roughly 50/50, or whatever reflects genuine ignorance) rather than anchoring on an unrelated number just to have something to write down.

Defining likelihoods from sparse indicators

Each indicator (an anomalous login, an unusual outbound connection, and so on) needs two numbers: how often it appears when the hypothesis is true, and how often it appears when the hypothesis is false. With scarce data, these come from whatever small calibration sample exists, most usefully a red-team or purple-team exercise where the ground truth (compromised or not) is actually known, so the indicator's true-positive and false-positive rates can be measured directly rather than guessed. A sample of even single-digit size is far better than an assumed number, because it is at least grounded in something real, and the resulting likelihoods should be treated as themselves uncertain if the sample is very small.

Bayes' update, one indicator at a time

For a single binary indicator $I$ and hypothesis $S$ (compromise), Bayes' rule gives the posterior:

When a second, independent indicator arrives, the previous posterior becomes the new prior and the same update runs again. This sequential process is mathematically identical to combining all the evidence at once, an equivalent and often more convenient form uses odds and likelihood ratios: posterior odds equal prior odds times the likelihood ratio of each new piece of evidence, multiplied together as evidence accumulates. Using conjugate priors (Beta-Bernoulli for a binary hypothesis) keeps every update in closed form, so no numerical approximation or sampling is needed for the binary case; Markov Chain Monte Carlo (MCMC, a family of sampling methods for approximating a distribution when no closed form exists) becomes useful once the model has enough interacting variables that the posterior can no longer be written down analytically.

Worked example

Scoring the hypothesis $S$: "this host is compromised," starting from a weak prior and updating with two indicators from a small purple-team calibration sample (every input is stated explicitly below, and the final posterior is re-derived a second way at the end, so the whole chain is checkable on paper without any tooling).

Prior: a Beta(2, 18) prior, giving a prior mean of $2/20 = 0.10$, reflecting a starting belief that about 10% of hosts showing some anomaly are actually compromised, held with the weight of only 20 pseudo-observations (a weak, easily-moved prior).

Indicator 1: "anomalous off-hours authentication." Calibration sample: of 9 known-compromised hosts from past exercises, 7 showed this indicator; of 11 known-clean hosts, 2 showed it. That gives $P(I_1 \mid S) = 7/9 \approx 0.778$ and $P(I_1 \mid \neg S) = 2/11 \approx 0.182$. Applying Bayes' rule:

One indicator moves belief from a 10% prior to about 32%, a real update, but nowhere near confirmation on its own.

Indicator 2: "outbound beaconing to a newly registered domain," from the same calibration sample: 5 of the 9 compromised hosts showed it, 1 of the 11 clean hosts did. That gives $P(I_2 \mid S) = 5/9 \approx 0.556$ and $P(I_2 \mid \neg S) = 1/11 \approx 0.091$. Treating the two indicators as conditionally independent given the hypothesis (a stated simplification, see Pitfalls) and updating again with the previous posterior as the new prior:

Two weak indicators together move belief from a 10% prior to about 74%, crossing into "worth an active response" territory even though neither indicator alone would have justified that. As a reproducibility cross-check, computing the same result via the odds-and-likelihood-ratio form (prior odds $0.111$, times a likelihood ratio of $4.28$ for indicator 1, times $6.11$ for indicator 2, giving posterior odds $2.90$, which converts back to a probability of $0.744$) matches the sequential update exactly, confirming the two equivalent derivations agree.

Trade-offs and pitfalls

• Conditional independence between indicators is an assumption, not a fact, and it is usually optimistic. Two indicators that both stem from the same underlying attacker behavior (a single command-and-control channel might produce both anomalous logins and beaconing traffic) are not truly independent, and treating them as independent overstates how much the second indicator actually adds; state the assumption explicitly and treat the resulting posterior as an upper bound on confidence, not a precise figure.
• Small calibration samples produce uncertain likelihoods, not just uncertain priors. A likelihood estimated from 9 or 11 examples carries real sampling error; a more rigorous treatment would propagate that uncertainty through (a hierarchical Bayesian model with its own priors on the likelihoods) rather than treating $7/9$ as if it were exact.
• A single well-chosen indicator can outweigh a weak prior fast, which is the whole point of the method, but it also means the method is sensitive to which indicators get included; cherry-picking indicators that happen to move the score in a preferred direction defeats the purpose of a supposedly objective update.
• Common wrong turn: presenting the final posterior as a confirmed fact rather than a probability that should inform, not replace, further investigation. A 74% posterior justifies escalation and active response, not a conclusion written up as certain compromise.