SOC Analyst Portfolio: An Alert-Triage Case-Study Worksheet

What should a SOC analyst portfolio case study show?

Show how you investigated one alert: the permitted environment, the initial signal, the evidence you checked, your decision and what you could not establish. A useful case study makes the reasoning inspectable. A screenshot of a dashboard or a list of security tools does not explain why an alert deserved escalation or closure.

The strongest material may come from an authorized lab rather than a real customer incident. Label that context clearly. A simulated account and a synthetic event sequence can demonstrate a method without pretending to represent production incident-response experience.

This guide supplies a defensive alert-triage writing model. The existing cybersecurity portfolio overview owns the broader sections and portfolio patterns. No hiring outcome is promised, and none of the fictional events below should be treated as a decision rule for a real incident.

Separate the alert from the conclusion

Start with a narrow question. “Does the available evidence justify further investigation of this sign-in sequence?” is a bounded task. “Detect every attack” is not a plausible claim for one portfolio exercise.

Step 1: define the environment and permission

State whether the exercise uses your own lab, an authorized training environment or an approved sanitized account of work. Identify what you personally did. Do not imply that collecting a supplied dataset is equivalent to running a production SOC.

Record the data sources, time window and important omissions. Explain whether clocks use the same time zone and whether a record is an event, an alert or an analyst note. Those distinctions stop a reader from mistaking several representations of the same activity for independent evidence.

Official event-logging and threat-detection guidance explains why useful logs and consistent context matter to investigations. For the portfolio, show the small set of permitted observations that supports your actual decision rather than reproducing a large operational log dump.

Step 2: write an evidence ledger

Keep observed facts and interpretations in separate fields. An unfamiliar address, a failed login or an automated severity label can be a reason to investigate; it should not silently become proof of an attacker. Describe how the available context changed your judgment.

Sanitize material before it becomes a public screenshot. Remove private identities, credentials, tokens and unnecessary customer details. Replacing those with explicit synthetic values is preferable to suggesting that fictional identifiers came from a real employer. A case study can remain useful while acknowledging that some evidence cannot be shown publicly.

Step 3: explain the decision path

Write the question you asked at each stage and the observation that answered it. If a check could not be completed, say so. A reviewer should understand why your conclusion follows from the evidence and what additional information might change it.

Use ordinary language for the main narrative. Put tool-specific details beside the relevant step rather than letting screenshots carry the entire explanation. If a dashboard counts events, specify whether that count represents distinct events or repeated alerts about the same sequence.

Include a short decision summary near the end: the available explanation, the action you would recommend under the exercise’s rules and the unresolved limits. For a real workplace, escalation and handling belong to the organization’s authorized procedures; a public portfolio example is not a substitute for them.

Worked example: a synthetic authentication alert

This is a fictional writing model, not a real incident. The supplied sample shows failed sign-ins followed by a successful one. The learner initially labels it “compromised account” without checking any other context.

The revised case study starts with the alert condition and an evidence ledger. It explains the time window, identifies which device/account context the exercise supplies and notes that endpoint records are absent. The learner checks the available context and documents why the remaining uncertainty warrants further review under the exercise instructions.

The conclusion does not invent malware, a stolen password or a contained incident. It distinguishes a suspicious sequence from a confirmed explanation. The useful result is the documented investigation and its limits, not a fabricated number of threats stopped.

Step 4: make the report readable as a portfolio page

Use a short summary, scope, evidence sequence, decision and limitations. A screenshot should have a caption explaining which observation matters. Provide a text explanation so the reader does not need to decipher tiny dashboard labels on a phone.

For a project whose private evidence cannot be shown, the portfolio evidence guide explains honest alternatives. Keep this alert-triage article focused on the reasoning model rather than another generic portfolio layout guide.

Match the portfolio format to the report

Write one complete, permitted case study before shopping for its presentation. Test long headings, evidence captions and mobile reading in the preview, and confirm the exact delivered page structure.

Compare Csume v3 Framer for a visual editing workflow with Csume v2 Next.js for a code-managed workflow. The original free Csume is a separate HTML/Bootstrap option; it is not a free Next.js edition.

Choose around the person who will update the report, the setup work and continuing hosting costs. Confirm support scope before buying. The cybersecurity portfolio overview helps plan the wider site. DesignToCodes sells these templates; a template presents your evidence and does not establish security competence or hiring results.

Frequently asked questions

Can a lab exercise belong in a SOC analyst portfolio?

Yes, when the lab status, supplied data and your contribution are clear. Do not describe it as production incident-response work.

Is a dashboard screenshot enough?

Explain the question, evidence and decision in readable text. The screenshot should support a specific observation, not replace the reasoning.

Should I call a suspicious sign-in a confirmed compromise?

Use a conclusion supported by the available evidence. State missing context and alternative explanations rather than upgrading uncertainty into certainty.

Can I publish workplace logs?

Use only material approved for public use through the relevant owner’s process. A sanitized or synthetic exercise can demonstrate the method without exposing private records.

Does a portfolio case study need a success metric?

It needs inspectable work and an honest result. Do not invent prevented losses, detection percentages or hiring outcomes to make the example sound stronger.

Review Csume v3 Framer for your case-study presentation.

Related reading

• Cybersecurity portfolio overview
• Evidence without a live demo

Sources and platform references

• Official event-logging guidance