Design a security incident response platform: system design interview question

How the interviewer opens it

“Design a platform that turns security alerts into investigation cases and automated response workflows. It must coordinate actions across external tools, support approval gates and retries, and preserve an execution history.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Scale
Alerts and case rules
Workflow behavior
Read and write traffic
Latency
External tools
Approvals and cancellation
Consistency and durability
Retention and audit
Security and boundaries

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Accept alerts and create or update investigation cases.
Run response workflows with conditions, parallel steps, and approval gates.
Execute external actions with retries and clear failure states.
Preserve case histories and an audit record for each action.

Usually out of scope

Detect threats from raw security data.
Analyze malware.
Implement the external security tools.
Provide multi-region failover.

What interviewers ask about

Alerts and cases: Sources repeat alerts and deliver them late. Concurrent consumers must create one case and one workflow without losing evidence.
External action outcomes: A tool can complete an action without returning a response. A retry can repeat a harmful action or hide an unresolved result.
Approval decisions: Human decisions arrive late while targets, policies, and run states can change. An approval must authorize one precise action.
Execution history and recovery: Security teams need evidence for every action. Worker failures and administrator access must not leave silent gaps or undetectable changes.

Common mistakes

Treat every duplicate alert as a new case or workflow.
Promise exactly-once external actions without support from the external tool.
Retry an uncertain destructive action without a safe recovery rule.
Store approval as a case flag without an action target or expiry.
Keep a worker active while a workflow waits for human approval.
Use ordinary application logs as the only audit record.

The bar by level

Senior (L5/E5): Defines crash recovery and unknown outcomes. Binds approvals to exact actions. Uses atomic state transitions, durable waits, tenant quotas, and a reliable audit path.
Staff (L6+/E6+): Defines enforceable safety boundaries across tools with different guarantees. Covers stale workers, credential compromise, audit integrity, tenant isolation, and recovery without duplicate destructive actions.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design a security incident response platform
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a platform that turns security alerts into investigation cases and automated response workflows. It must coordinate actions across external tools, support approval gates and retries, and preserve an execution history.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

Scope of a strong answer

Core requirements

Accept alerts and create or update investigation cases.
Run response workflows with conditions, parallel steps, and approval gates.
Execute external actions with retries and clear failure states.
Preserve case histories and an audit record for each action.

Usually out of scope

Detect threats from raw security data.
Analyze malware.
Implement the external security tools.
Provide multi-region failover.

What interviewers ask about

Alerts and cases

Sources repeat alerts and deliver them late. Concurrent consumers must create one case and one workflow without losing evidence.

External action outcomes

A tool can complete an action without returning a response. A retry can repeat a harmful action or hide an unresolved result.

Approval decisions

Human decisions arrive late while targets, policies, and run states can change. An approval must authorize one precise action.

Execution history and recovery

Security teams need evidence for every action. Worker failures and administrator access must not leave silent gaps or undetectable changes.

Common mistakes

Treat every duplicate alert as a new case or workflow.

Promise exactly-once external actions without support from the external tool.

Retry an uncertain destructive action without a safe recovery rule.

Store approval as a case flag without an action target or expiry.

Keep a worker active while a workflow waits for human approval.

Use ordinary application logs as the only audit record.

The bar by level

Senior (L5/E5)

Defines crash recovery and unknown outcomes. Binds approvals to exact actions. Uses atomic state transitions, durable waits, tenant quotas, and a reliable audit path.

Staff (L6+/E6+)

Defines enforceable safety boundaries across tools with different guarantees. Covers stale workers, credential compromise, audit integrity, tenant isolation, and recovery without duplicate destructive actions.