Lab 14 SOC Investigation Reporting & Case Documentation

Mission Overview

Welcome to Lab 14 — SOC Investigation Reporting & Case Documentation.

You have investigated alerts, authentication activity, Windows and Linux systems, phishing, endpoint events, network traffic, DNS/web activity, SIEM telemetry, threat intelligence, incident timelines, scope, containment, and escalation.

Now you must turn all of that technical work into a professional SOC case record.

A technically correct investigation can still fail operationally if the documentation is incomplete, unclear, unsupported, or impossible for another analyst to reproduce.

Your case should answer:

What triggered the investigation?
What happened?
When did it happen?
Which systems and identities were involved?
What evidence was reviewed?
What did the evidence establish?
What remains uncertain?
How severe was the incident?
How confident are we?
What containment actions occurred?
Was the case escalated?
What remediation is recommended?
What should happen next?

Mission Goal: Convert a completed SOC investigation into a concise, evidence-backed, reproducible case record suitable for analyst handoff, incident response, management review, audit support, and case closure.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	SOC Investigation Reporting
Secondary Skill	Security Case Documentation
Environment	GoHackersCloud SOC Analyst Lab
Input	Completed investigation evidence and artifacts
Primary Outcome	Professional SOC Case Report
Secondary Outcome	Complete Case Documentation Package
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

create consistent SOC case metadata
write a concise executive summary
document the original alert accurately
define investigation scope
document affected assets and identities
maintain evidence provenance
build evidence and IOC registers
include a defensible incident timeline
distinguish evidence from analyst interpretation
write professional findings
document severity and confidence separately
distinguish confirmed from potential impact
document containment and response actions
document escalation decisions
record investigation limitations
track outstanding questions
write remediation recommendations
establish closure criteria
prepare analyst handoff notes
produce an auditable SOC case package

Core Methodology

Use:

Evidence → Findings → Timeline → Scope → Impact → Actions → Conclusion → Case Record

Expanded:

Alert
  │
  ▼
Investigation Evidence
  │
  ▼
Validated Findings
  │
  ▼
Master Timeline
  │
  ▼
Incident Scope
  │
  ▼
Impact Assessment
  │
  ▼
Containment / Escalation
  │
  ▼
Analyst Conclusion
  │
  ▼
Recommendations
  │
  ▼
Case Documentation
  │
  ▼
Review / Handoff / Closure

The core principle is:

A case should tell another analyst exactly what happened, what was checked, what the evidence supports, what remains unknown, and what should happen next.

Part 1 — Understand the Purpose of SOC Documentation

SOC documentation is not simply administrative paperwork.

It provides:

Investigation Continuity

Another analyst can continue the case without restarting the investigation.

Evidence Traceability

Every important conclusion can be traced to supporting evidence.

Incident Response Support

Responders understand what has already been investigated.

Management Visibility

Security leadership can understand risk and impact.

Auditability

The organization can demonstrate how an alert was investigated and resolved.

Lessons Learned

Previous incidents become useful operational knowledge.

Part 2 — Understand the Difference Between Notes and a Case Record

Analyst notes might contain:

Checked EDR.

Looks suspicious.

Domain seems bad.

User probably clicked it.

Escalated.

That is not sufficient case documentation.

A professional record should explain:

WHAT WAS OBSERVED

WHAT WAS INVESTIGATED

WHAT EVIDENCE WAS REVIEWED

WHAT WAS CONFIRMED

WHAT WAS NOT CONFIRMED

WHAT ACTION WAS TAKEN

WHY THE ACTION WAS TAKEN

WHAT REMAINS OUTSTANDING

Part 3 — Create the Lab Workspace

Create:

SOC-Labs/
└── Lab-14/
    ├── 01-Case-Metadata/
    ├── 02-Alert/
    ├── 03-Scope/
    ├── 04-Assets/
    ├── 05-Identities/
    ├── 06-Evidence/
    │   ├── Original/
    │   ├── Working/
    │   └── Redacted/
    ├── 07-IOCs/
    ├── 08-Timeline/
    ├── 09-Findings/
    ├── 10-Impact/
    ├── 11-Containment/
    ├── 12-Escalation/
    ├── 13-Remediation/
    ├── 14-Limitations/
    ├── 15-Handoff/
    ├── 16-Closure/
    └── 17-Final-Report/

Create:

Lab-14-SOC-Investigation-Reporting.md

Part 4 — Open the Case Record

Use a consistent case identifier.

Example:

CASE ID:
GHC-SOC-2026-014

CASE TITLE:
Suspicious Email and Endpoint Security Incident

CASE TYPE:
Security Incident Investigation

STATUS:
Investigating

PRIORITY:
P2

SEVERITY:
High

CONFIDENCE:
High

ANALYST:

DATE OPENED:

DATE UPDATED:

DATE CLOSED:

Part 5 — Create the Case Metadata Register

Field	Value
Case ID	GHC-SOC-2026-014
Title	Suspicious Email and Endpoint Incident
Analyst
Created
Updated
Priority	P2
Severity	High
Confidence	High
Status	Investigating
Escalation	Incident Response

Consistent metadata makes cases searchable and manageable.

Part 6 — Use Consistent Case Status

Recommended statuses:

New

Triage

Investigating

Pending Information

Escalated

Containment in Progress

Monitoring

Resolved

Closed

Avoid vague states such as:

Maybe Done

Looks Fine

Waiting

Part 7 — Record the Original Alert

Preserve what initiated the investigation.

Example:

ALERT ID:
ALT-EDR-001

ALERT TITLE:
Suspicious Executable Detected

SOURCE:
Endpoint Security

HOST:
WIN-FIN-02

USER:
finance-user

INITIAL SEVERITY:
High

ALERT TIME:
15:24:01 UTC

INITIAL ACTION:
Quarantine initiated

Do not rewrite the original alert to match your final conclusion.

Part 8 — Distinguish Initial Alert from Final Assessment

Example:

INITIAL ALERT:
Suspicious Executable Detected

Final investigation:

FINAL ASSESSMENT:
Confirmed Security Incident — Partially Contained

These are different fields.

Initial Alert ≠ Final Incident Classification

Part 9 — Write the Executive Summary

The executive summary should answer:

What happened?
What was affected?
What was the impact?
What was done?
What is the current status?

Keep it concise.

Part 10 — Example Executive Summary

A SOC investigation identified a simulated phishing-related security incident affecting one finance workstation and one user identity. Email, DNS, proxy, endpoint, and network telemetry established delivery of the suspicious message, interaction with the associated domain, file download, file execution, and subsequent outbound communication. Endpoint security detected the activity, terminated the suspicious process, and quarantined the associated file. No evidence established persistence or data exfiltration within the available telemetry. Potential identity exposure remained under investigation, and the case was escalated for endpoint and identity containment.

Notice what this summary does not do.

It does not claim:

The attacker stole all finance data.

because the evidence did not establish that.

Part 11 — Avoid Technical Overload in the Executive Summary

Do not start with:

Event ID 4688 generated PID 4428 and destination
203.0.113.50:443...

Those details belong later in the report.

The executive summary communicates security meaning, not every log field.

Part 12 — Define Investigation Scope

Record:

INVESTIGATION SCOPE

Primary Alert:

Primary Host:

Primary User:

Initial Time Window:

Expanded Time Window:

Telemetry Sources:

Related IOCs:

Related Cases:

Primary Investigation Questions:

Part 13 — Document Investigation Questions

Examples:

Did the suspicious file execute?

Did it communicate externally?

Were additional endpoints affected?

Was the user's identity compromised?

Was persistence established?

Was sensitive information accessed?

Was data transferred externally?

These questions explain what the analyst attempted to determine.

Part 14 — Document Data Sources Reviewed

Create:

Source	Reviewed	Purpose
Email Gateway	Yes	Initial delivery
Identity Logs	Yes	Authentication
Windows Logs	Yes	Host activity
EDR	Yes	File/process behavior
DNS	Yes	Domain interaction
Proxy	Yes	Web/download activity
Firewall	Yes	Network communication
SIEM	Yes	Correlation

Part 15 — Record Data Source Health

A missing event means little if the source was not functioning.

Create:

Source	Healthy	Coverage	Limitation
EDR	Yes	Full window	None
Proxy	Yes	Full window	None
Windows	Partial	Process command line unavailable	Reduced context

Part 16 — Create the Asset Register

Asset	IP	Role	Criticality	Status
WIN-FIN-02	10.10.20.55	Finance workstation	Medium	Confirmed affected
WIN-HR-04	10.10.20.60	HR workstation	Medium	Exposed

Part 17 — Create the Identity Register

Identity	Role	Privilege	Status	Evidence
finance-user	Finance	Standard	Affected	Email/web/endpoint
admin-user	Administrator	High	No impact established	Review

Part 18 — Use Precise Scope Vocabulary

Use:

Confirmed Affected

Potentially Affected

Exposed

Related

Cleared

Unknown

Avoid using compromised for every entity associated with the investigation.

Part 19 — Create the Evidence Register

Every significant artifact should have an evidence identifier.

Example:

Evidence ID	Type	Source	Description
EV-001	Email	Gateway	Original suspicious email
EV-002	DNS	DNS Logs	Domain query
EV-003	Proxy	Proxy	URL access
EV-004	Endpoint	EDR	File creation
EV-005	Endpoint	EDR	Process execution
EV-006	Network	Firewall	Outbound connection

Part 20 — Preserve Evidence Provenance

For each evidence item record:

EVIDENCE ID:

SOURCE:

ORIGINAL LOCATION:

COLLECTED:

COLLECTED BY:

ORIGINAL TIMESTAMP:

HASH:
If applicable

CASE ID:

NOTES:

Part 21 — Separate Original Evidence from Working Copies

Maintain:

06-Evidence/
├── Original/
├── Working/
└── Redacted/

Original

Preserved evidence.

Working

Analyst copies used during investigation.

Redacted

Copies prepared for sharing where sensitive information must be removed.

Part 22 — Document Evidence Integrity

Where appropriate, record cryptographic hashes for exported evidence.

Conceptually:

Evidence File
      ↓
Cryptographic Hash
      ↓
Evidence Register

This helps establish whether an artifact changed after collection.

Part 23 — Create the IOC Register

Example:

IOC ID	Type	Value	Assessment	Confidence
IOC-001	Domain	account-update.example.test	Malicious	High
IOC-002	IP	203.0.113.50	Suspicious	Medium
IOC-003	Hash	training SHA-256	Malicious	High

Part 24 — Document IOC Context

Do not simply write:

203.0.113.50 — Malicious

Record:

IOC:
203.0.113.50

TYPE:
IP

EXTERNAL ASSESSMENT:
Suspicious

LOCAL CORRELATION:
Observed from affected endpoint after process execution

SPECIFICITY:
Medium

CONFIDENCE:
Medium

LIMITATION:
Shared infrastructure

Part 25 — Include the Master Incident Timeline

The report should contain the most important events.

Example:

UTC Time	Source	Event	Evidence
15:18:10	Email	Suspicious message delivered	EV-001
15:21:02	DNS	Domain queried	EV-002
15:21:05	Proxy	HTTPS interaction	EV-003
15:22:11	Proxy	File download	EV-004
15:23:17	Endpoint	File executed	EV-005
15:24:01	EDR	Alert generated	EV-006
15:25:08	Firewall	Outbound communication	EV-007
15:26:10	EDR	Process terminated	EV-008
15:27:02	EDR	File quarantined	EV-009

Part 26 — Reference Evidence from the Timeline

Every significant timeline event should be traceable.

Bad:

15:23 Malware ran.

Better:

15:23:17 UTC — Endpoint telemetry recorded process creation for
InvoiceViewer.exe. [EV-005]

Part 27 — Distinguish Observation from Interpretation

Example:

Observation

Proxy telemetry recorded an HTTPS request to
account-update.example.test.

Interpretation

The activity is consistent with interaction with the URL
contained in the suspicious email.

Do not merge these into unsupported certainty.

Part 28 — Create the Findings Register

Use:

FINDING ID:

TITLE:

STATUS:

SEVERITY:

CONFIDENCE:

AFFECTED ASSET:

OBSERVATION:

EVIDENCE:

SECURITY IMPACT:

LIMITATIONS:

RECOMMENDATION:

Part 29 — Example Finding 01

FINDING ID:
F-001

TITLE:
Suspicious File Execution Confirmed

SEVERITY:
High

CONFIDENCE:
High

ASSET:
WIN-FIN-02

OBSERVATION:
Endpoint telemetry recorded execution of InvoiceViewer.exe.

EVIDENCE:
EV-005

IMPACT:
Execution of the suspicious file was confirmed.

LIMITATION:
Available evidence does not independently establish all
post-execution functionality.

RECOMMENDATION:
Preserve endpoint evidence, maintain containment, and complete
endpoint investigation.

Part 30 — Example Finding 02

FINDING ID:
F-002

TITLE:
Outbound Communication Following Execution

SEVERITY:
High

CONFIDENCE:
High

OBSERVATION:
Network telemetry recorded outbound communication from
WIN-FIN-02 after execution of the suspicious process.

EVIDENCE:
EV-007

IMPACT:
Post-execution external communication was observed.

LIMITATION:
Available telemetry does not establish data exfiltration.

RECOMMENDATION:
Maintain network containment and review related communications.

Part 31 — Example Finding 03

FINDING ID:
F-003

TITLE:
Potential Identity Exposure

SEVERITY:
High

CONFIDENCE:
Medium

OBSERVATION:
Unexpected authentication activity involving the affected user
was observed after the endpoint activity.

IMPACT:
Potential misuse of the user's identity cannot be excluded.

LIMITATION:
Available evidence does not confirm credential compromise.

RECOMMENDATION:
Review active sessions and authentication telemetry and apply
authorized identity containment where appropriate.

Part 32 — Use Evidence-Based Finding Titles

Prefer:

Suspicious File Execution Confirmed

over:

Hacker Took Over Computer

Prefer:

Unexpected Authentication Requires Investigation

over:

Credentials Stolen

unless evidence supports the stronger statement.

Part 33 — Document Confirmed Impact

Create:

Impact	Status	Evidence
Phishing delivery	Confirmed	EV-001
Domain interaction	Confirmed	EV-002/003
File download	Confirmed	EV-004
File execution	Confirmed	EV-005
External communication	Confirmed	EV-007

Part 34 — Document Potential Impact Separately

Impact	Status	Reason
Credential exposure	Potential	Authentication anomaly
Persistence	Not established	No supporting evidence
Data exfiltration	Not established	No supporting evidence
Additional endpoint compromise	Under investigation	IOC matches require validation

Part 35 — Never Turn Unknown into Confirmed

Avoid:

No evidence of exfiltration, therefore no data was stolen.

Prefer:

No data exfiltration was established within the available telemetry and investigation window.

Part 36 — Document Severity

Record:

FINAL SEVERITY:
High

RATIONALE:
Confirmed suspicious file execution and subsequent outbound
network activity occurred on a finance workstation, requiring
coordinated endpoint and identity response.

Part 37 — Document Confidence Separately

Example:

ANALYST CONFIDENCE:
High

RATIONALE:
Multiple independent telemetry sources corroborate email
delivery, domain interaction, file execution, endpoint
detection, and network activity.

Remember:

Severity ≠ Confidence

Part 38 — Document Case Disposition

Use consistent vocabulary:

Benign

Expected Activity

False Positive

Duplicate

Suspicious

Potential Security Incident

Confirmed Security Incident

Inconclusive

Escalated

For the scenario:

DISPOSITION:
Confirmed Security Incident — Escalated

Part 39 — Document Containment Actions

Create:

Time	Action	Target	Status	Owner
15:26	Process terminated	WIN-FIN-02	Complete	EDR
15:27	File quarantined	WIN-FIN-02	Complete	EDR
15:43	Endpoint isolated	WIN-FIN-02	Complete	IR
15:45	Sessions revoked	finance-user	Complete	IAM

Part 40 — Separate Automated and Analyst Actions

Example:

Automated

EDR terminated process.

Analyst Recommended

SOC recommended endpoint isolation.

Response Team Performed

IR isolated endpoint.

These should not be recorded as the same action.

Part 41 — Create the Response Action Register

ACTION ID:

TIME:

ACTION:

TARGET:

REQUESTED BY:

PERFORMED BY:

APPROVAL:

RESULT:

BUSINESS IMPACT:

EVIDENCE IMPACT:

STATUS:

Part 42 — Document Escalation

Record:

ESCALATION

Escalated:
Yes

Time:

Escalated By:

Destination:
Incident Response

Secondary Teams:
IAM
Email Security

Reason:
Confirmed execution, external communication, and potential
identity exposure.

Severity:
High

Confidence:
High

Part 43 — Document What Was Sent During Escalation

The package should include:

case summary
alert
affected assets
affected identities
timeline
evidence references
IOCs
findings
confirmed impact
potential impact
containment status
outstanding questions

Part 44 — Document Remediation Recommendations

Separate immediate response from longer-term remediation.

Immediate

Maintain endpoint containment.

Protect affected identity.

Block high-confidence malicious indicators.

Remove remaining phishing messages.

Continue scope validation.

Short Term

Review authentication activity.

Verify endpoint remediation.

Validate other exposed endpoints.

Review relevant security-control telemetry.

Longer Term

Improve phishing controls.

Improve endpoint telemetry coverage.

Improve identity monitoring.

Improve IOC correlation.

Review incident detection logic.

Part 45 — Prioritize Recommendations

Use:

P1 — Immediate

P2 — High

P3 — Medium

P4 — Low

Example:

Recommendation	Priority	Owner
Protect affected identity	P1	IAM
Validate other endpoints	P2	SOC/IR
Improve telemetry	P3	Security Engineering

Part 46 — Make Recommendations Actionable

Weak:

Improve security.

Better:

Review endpoint telemetry coverage on systems that currently
lack process and network visibility.

Weak:

Train users.

Better:

Review phishing awareness content using the observed social
engineering pattern as a sanitized training example.

Part 47 — Document Positive Security Controls

Professional reporting should record what worked.

Examples:

EDR detected suspicious execution.

EDR terminated the process.

EDR quarantined the file.

DNS telemetry supported domain correlation.

Proxy telemetry established web interaction.

Firewall telemetry established outbound communication.

SIEM enabled multi-source correlation.

Part 48 — Create the Positive Controls Register

Control	Result	Investigation Value
EDR	Detected/contained	High
DNS Logging	Recorded query	High
Proxy	Recorded interaction	High
SIEM	Correlated events	High

Part 49 — Document Control Gaps

Examples:

No process command-line telemetry.

Incomplete proxy coverage.

No EDR on one exposed endpoint.

Authentication retention insufficient.

Email click telemetry unavailable.

Part 50 — Create the Control Gap Register

Gap	Impact	Recommendation
Missing process command line	Reduced execution context	Improve endpoint logging
Endpoint without EDR	Scope uncertainty	Expand coverage

Part 51 — Document Investigation Limitations

Every professional investigation should state important limitations.

Example:

INVESTIGATION LIMITATIONS

1. Process command-line telemetry was unavailable for part of
   the investigation window.

2. One exposed endpoint did not have complete EDR coverage.

3. Available network telemetry established communication but
   did not establish data exfiltration.

4. The investigation was limited to the defined telemetry
   retention period.

Part 52 — Understand Why Limitations Matter

Limitations prevent statements such as:

We proved nothing else happened.

when what you actually know is:

No additional activity was identified within the available
telemetry.

Part 53 — Create the Outstanding Questions Register

Question	Owner	Priority	Status
Was identity misuse confirmed?	IAM	High	Open
Were other endpoints affected?	SOC/IR	High	Open
Was persistence established?	DFIR	Medium	Open

Part 54 — Distinguish Open Question from Finding

An unanswered question is not a finding.

Example:

QUESTION:
Did credentials get exposed?

does not become:

FINDING:
Credentials were stolen.

Part 55 — Document Analyst Decisions

Record significant decisions.

Example:

DECISION:
Escalate to Incident Response.

RATIONALE:
Confirmed execution and post-execution communication exceeded
SOC monitoring-only threshold.

TIME:

ANALYST:

Part 56 — Create the Decision Register

Decision	Rationale	Analyst	Time
Escalate	Execution confirmed
Expand scope	IOC on second host
Recommend isolation	Active risk

Part 57 — Document False Positives Properly

If the final disposition is false positive, still document:

why the alert fired
what evidence was checked
why the activity is benign
what baseline or authorization supports it
whether tuning is recommended

Do not write only:

False positive.

Part 58 — Example False-Positive Closure

DISPOSITION:
False Positive

ASSESSMENT:
The alert accurately identified administrative PowerShell
execution. Endpoint, identity, and change-management evidence
established that the activity was generated by approved
automation from the expected management account.

SECURITY IMPACT:
None identified.

CONFIDENCE:
High

RECOMMENDATION:
Review alert tuning to reduce repeated notifications for the
approved automation while preserving detection for deviations.

Part 59 — Document Inconclusive Cases Properly

Sometimes:

Available evidence does not support either confirmation or
dismissal.

That is acceptable.

Use:

DISPOSITION:
Inconclusive

CONFIDENCE:
Low

REASON:
Required telemetry unavailable.

Do not force every case into benign or malicious.

Part 60 — Build the Case Conclusion

A conclusion should include:

Classification

Severity

Confidence

Confirmed Scope

Confirmed Impact

Potential Impact

Containment Status

Escalation Status

Remaining Risk

Part 61 — Example Case Conclusion

The investigation confirms a security incident involving one finance workstation and one user. Available email, DNS, proxy, endpoint, and network evidence establishes delivery of the suspicious message, interaction with the related domain, file download, file execution, and subsequent outbound communication. Endpoint controls terminated the process and quarantined the file. No evidence established persistence or data exfiltration within the available telemetry. Potential identity exposure remained under investigation. The incident was rated High severity with High analyst confidence and escalated to Incident Response and IAM for continued containment and validation.

Part 62 — Establish Closure Criteria

A case should not be closed simply because:

The alert stopped.

Possible closure criteria:

investigation completed
scope established
evidence preserved
findings documented
containment completed or transferred
required escalation completed
recommendations assigned
outstanding questions transferred
final disposition assigned
case reviewed

Part 63 — Create the Closure Checklist

alert reviewed
scope established
assets documented
identities documented
evidence registered
IOCs documented
timeline completed
findings completed
impact documented
severity assigned
confidence assigned
containment documented
escalation documented
recommendations assigned
limitations documented
outstanding questions transferred
final disposition assigned
final report reviewed

Part 64 — Distinguish Resolution from Closure

Resolved

The immediate investigation or response requirement has been addressed.

Closed

Documentation, ownership, evidence, and required follow-up are complete according to organizational procedure.

Resolved ≠ Closed Automatically

Part 65 — Prepare Analyst Handoff Notes

Sometimes a shift ends before the case does.

Create:

ANALYST HANDOFF

Case ID:

Current Status:

Current Severity:

Current Confidence:

Last Investigation Action:

Confirmed Findings:

Current Scope:

Containment Status:

Evidence Location:

Queries Used:

Outstanding Questions:

Pending Actions:

Next Recommended Step:

Handoff From:

Handoff To:

Time:

Part 66 — Make Handoff Notes Actionable

Weak:

Still investigating.

Better:

Endpoint execution is confirmed on WIN-FIN-02. EDR has
quarantined the file, but identity exposure remains unresolved.
Next analyst should correlate the 15:32 UTC authentication event
against VPN/MFA and active-session telemetry.

Part 67 — Record Saved Queries

Create:

Query ID	Purpose	Data Source
Q-001	Search affected user	SIEM
Q-002	Search domain	DNS
Q-003	Search hash	EDR
Q-004	Search destination IP	Firewall

This improves reproducibility.

Part 68 — Record Investigation Pivots

Example:

Alert
  ↓
Host
  ↓
User
  ↓
Domain
  ↓
Hash
  ↓
Additional Hosts

Create:

Pivot	From	To	Result
P-001	Alert	Host	WIN-FIN-02
P-002	Host	User	finance-user
P-003	User	Domain	Related IOC

Part 69 — Create the Case Audit Trail

Record major actions chronologically:

15:24 — Alert received

15:28 — Analyst opened case

15:31 — Endpoint execution confirmed

15:35 — Network activity correlated

15:40 — Scope expanded

15:42 — IR escalation initiated

15:43 — Endpoint isolation approved

15:45 — IAM containment requested

16:05 — Report updated

Part 70 — Avoid Modifying Historical Case Entries Silently

If an assessment changes:

Initial Severity:
Medium

to:

Current Severity:
High

record the change and reason.

Do not erase the history.

Part 71 — Create the Severity Change Register

Time	Previous	New	Reason
15:24	Medium	High	File execution confirmed

Part 72 — Create the Confidence Change Register

Time	Previous	New	Reason
15:24	Low	Medium	Endpoint evidence
15:35	Medium	High	Network correlation

Part 73 — Apply Consistent Writing Standards

SOC reporting should be:

Factual

Use evidence.

Concise

Remove unnecessary narrative.

Specific

Name the relevant system, user, time, and evidence.

Neutral

Avoid emotional or speculative language.

Reproducible

Another analyst should understand how you reached the conclusion.

Part 74 — Avoid Unsupported Attribution

Do not write:

Russian attackers compromised the system.

because an IP or tool has previously been associated with a particular actor.

Attribution requires a much stronger evidentiary basis.

Prefer:

Available evidence does not support threat-actor attribution.

when appropriate.

Part 75 — Avoid Absolute Statements

Avoid:

No data was stolen.

when telemetry only shows no detected transfer.

Prefer:

No evidence of data exfiltration was identified within the available telemetry and investigation period.

Part 76 — Use Confidence Language

Useful phrases include:

Evidence confirms...

Evidence supports...

Activity is consistent with...

Evidence suggests...

Available telemetry does not establish...

No additional evidence was identified...

Unable to determine from available telemetry...

These phrases improve precision.

Part 77 — Protect Sensitive Information

Case reports may contain:

usernames
email addresses
IP addresses
hostnames
business systems
security architecture
customer information
authentication information
internal URLs

Follow organizational handling requirements.

Use redacted copies where appropriate.

Part 78 — Create the Report Distribution Register

Recipient	Version	Reason
SOC	Full	Investigation
IR	Full	Response
Management	Summary	Decision support
External audience	Redacted	Approved purpose

Part 79 — Perform Analyst Self-Review

Before submitting, ask:

Does every major conclusion have evidence?

Are confirmed and potential impact separated?

Are severity and confidence separated?

Are timestamps consistent?

Are assets and identities clearly identified?

Are IOCs contextualized?

Are containment actions accurate?

Are limitations documented?

Are outstanding questions visible?

Could another analyst reproduce the investigation?

Part 80 — Perform Peer Review

Where your SOC process supports it, have another analyst verify:

case classification
timeline
findings
severity
confidence
evidence references
containment status
closure readiness

Create:

PEER REVIEW

Reviewer:

Date:

Case Classification Reviewed:
Yes / No

Timeline Reviewed:
Yes / No

Evidence References Reviewed:
Yes / No

Severity Reviewed:
Yes / No

Confidence Reviewed:
Yes / No

Closure Approved:
Yes / No

Comments:

Part 81 — Build the Final Case Package

Your final package should contain:

SOC Case
│
├── Case Metadata
├── Original Alert
├── Executive Summary
├── Investigation Scope
├── Asset Register
├── Identity Register
├── Evidence Register
├── IOC Register
├── Master Incident Timeline
├── Findings
├── Impact Assessment
├── Severity Assessment
├── Confidence Assessment
├── Containment Actions
├── Escalation Record
├── Recommendations
├── Positive Security Controls
├── Control Gaps
├── Investigation Limitations
├── Outstanding Questions
├── Analyst Decisions
├── Handoff Notes
├── Audit Trail
└── Closure Record

Part 82 — Mission Challenge

Complete the following case:

LAB INFORMATION

Lab:
SOC Investigation Reporting & Case Documentation

Case ID:

Analyst:

Date:


CASE METADATA

Case Title:

Case Type:

Status:

Priority:

Severity:

Confidence:

Opened:

Updated:

Closed:


ORIGINAL ALERT

Alert ID:

Alert Title:

Alert Source:

Alert Time:

Host:

User:

Initial Severity:

Initial Action:


EXECUTIVE SUMMARY

What Happened:

Affected Assets:

Affected Identities:

Confirmed Impact:

Potential Impact:

Containment:

Escalation:

Current Status:


INVESTIGATION SCOPE

Primary Host:

Primary User:

Initial Window:

Expanded Window:

Investigation Questions:

Data Sources:


ASSETS

Confirmed Affected:

Potentially Affected:

Exposed:

Cleared:

Unknown:


IDENTITIES

Confirmed Affected:

Potentially Affected:

Privileged:

Service Accounts:

Cleared:


EVIDENCE

Evidence Count:

Original Evidence Location:

Working Evidence Location:

Evidence Integrity Verified:
Yes / No


IOCS

Domains:

URLs:

IPs:

Hashes:

Email Indicators:


TIMELINE

First Seen:

Last Seen:

Observed Duration:

Major Event 01:

Major Event 02:

Major Event 03:

Major Event 04:

Major Event 05:


FINDINGS

Finding 01:

Severity:

Confidence:

Evidence:


Finding 02:

Severity:

Confidence:

Evidence:


Finding 03:

Severity:

Confidence:

Evidence:


CONFIRMED IMPACT

Email Delivery:

Web Interaction:

File Download:

Execution:

Network Communication:

Persistence:

Credential Misuse:

Additional Hosts:

Data Exfiltration:


POTENTIAL IMPACT

Identity Exposure:

Persistence:

Additional Hosts:

Sensitive Data:


CONTAINMENT

Endpoint:

Identity:

Network:

Email:

Overall Status:


ESCALATION

Required:
Yes / No

Destination:

Reason:

Time:

Status:


REMEDIATION

Immediate:

Short Term:

Long Term:

Owners:


POSITIVE CONTROLS

Control 01:

Outcome:

Control 02:

Outcome:


CONTROL GAPS

Gap 01:

Impact:

Recommendation:


LIMITATIONS

Limitation 01:

Limitation 02:

Limitation 03:


OUTSTANDING QUESTIONS

Question 01:

Owner:

Question 02:

Owner:


FINAL ASSESSMENT

Disposition:

Severity:

Confidence:

Confirmed Scope:

Confirmed Impact:

Potential Impact:

Containment Status:

Remaining Risk:


HANDOFF

Required:
Yes / No

Handoff To:

Next Action:


CLOSURE

Investigation Complete:
Yes / No

Evidence Complete:
Yes / No

Containment Complete / Transferred:
Yes / No

Escalation Complete:
Yes / No

Recommendations Assigned:
Yes / No

Outstanding Questions Transferred:
Yes / No

Peer Review:
Yes / No

Ready for Closure:
Yes / No

Part 83 — What Not to Do

Do not:

Write conclusions without evidence

Rewrite the original alert to match the conclusion

Mix observations and assumptions

Treat suspicious activity as confirmed compromise

Treat IOC matches as proof

Treat missing evidence as proof nothing happened

Mix confirmed and potential impact

Call every related system compromised

Claim data exfiltration from outbound traffic alone

Claim credential theft from suspicious authentication alone

Hide contradictory evidence

Hide telemetry gaps

Hide investigation limitations

Delete historical severity changes

Use vague phrases such as "looks bad"

Write unsupported threat-actor attribution

Use emotional language

Include unnecessary sensitive information

Close cases with unresolved ownership

Close cases simply because alerts stopped

Create recommendations without owners

Create vague recommendations

Hand off a case without explaining the next action

The professional rule is:

If another analyst cannot understand and reproduce your investigation from the case record, the documentation is not complete.

Evidence Requirements

Capture:

Evidence 01

Case Metadata Register.

Evidence 02

Original Alert.

Evidence 03

Executive Summary.

Evidence 04

Investigation Scope.

Evidence 05

Investigation Questions.

Evidence 06

Data Source Inventory.

Evidence 07

Data Source Health Register.

Evidence 08

Asset Register.

Evidence 09

Identity Register.

Evidence 10

Evidence Register.

Evidence 11

Evidence Provenance.

Evidence 12

Evidence Integrity Record.

Evidence 13

IOC Register.

Evidence 14

IOC Context.

Evidence 15

Master Incident Timeline.

Evidence 16

Timeline Evidence References.

Evidence 17

Finding 01.

Evidence 18

Finding 02.

Evidence 19

Finding 03.

Evidence 20

Confirmed Impact Register.

Evidence 21

Potential Impact Register.

Evidence 22

Severity Assessment.

Evidence 23

Confidence Assessment.

Evidence 24

Case Disposition.

Evidence 25

Containment Action Register.

Evidence 26

Response Action Register.

Evidence 27

Escalation Record.

Evidence 28

Escalation Package.

Evidence 29

Remediation Recommendations.

Evidence 30

Recommendation Priority Register.

Evidence 31

Positive Security Controls Register.

Evidence 32

Control Gap Register.

Evidence 33

Investigation Limitations.

Evidence 34

Outstanding Questions Register.

Evidence 35

Decision Register.

Evidence 36

Case Conclusion.

Evidence 37

Closure Checklist.

Evidence 38

Analyst Handoff.

Evidence 39

Saved Query Register.

Evidence 40

Investigation Pivot Register.

Evidence 41

Case Audit Trail.

Evidence 42

Severity Change Register.

Evidence 43

Confidence Change Register.

Evidence 44

Peer Review.

Evidence 45

Final Case Package.

Evidence 46

Mission Challenge worksheet.

Mission Deliverables

Complete:

case metadata completed
original alert preserved
initial alert separated from final assessment
executive summary written
investigation scope documented
investigation questions documented
data sources documented
data-source health documented
affected assets documented
affected identities documented
scope terminology applied consistently
evidence registered
evidence provenance preserved
original and working evidence separated
evidence integrity documented where appropriate
IOC Register completed
IOC context documented
Master Incident Timeline included
timeline entries referenced to evidence
observations separated from interpretations
findings documented
findings linked to evidence
confirmed impact documented
potential impact documented separately
severity assigned with rationale
confidence assigned with rationale
final disposition assigned
containment actions documented
automated and analyst actions distinguished
escalation documented
escalation package completed
immediate remediation documented
short-term remediation documented
longer-term improvements documented
recommendation priorities assigned
recommendation owners identified
positive security controls documented
security-control gaps documented
investigation limitations documented
outstanding questions documented
analyst decisions documented
case conclusion completed
closure criteria evaluated
analyst handoff prepared
saved queries documented
investigation pivots documented
audit trail completed
severity changes preserved
confidence changes preserved
final report reviewed
case package completed

Final SOC Case Report Template

# SOC Investigation Report

## 1. Executive Summary

## 2. Case Information

## 3. Original Alert

## 4. Investigation Objective

## 5. Investigation Scope

## 6. Investigation Questions

## 7. Data Sources Reviewed

## 8. Data Source Health

## 9. Affected Assets

## 10. Affected Identities

## 11. Evidence Register

## 12. IOC Register

## 13. Master Incident Timeline

## 14. Investigation Findings

### Finding 01

### Finding 02

### Finding 03

## 15. Confirmed Impact

## 16. Potential Impact

## 17. Incident Scope

## 18. Severity Assessment

## 19. Confidence Assessment

## 20. Containment Actions

## 21. Escalation

## 22. Remediation Recommendations

### Immediate

### Short Term

### Long Term

## 23. Positive Security Controls

## 24. Security Control Gaps

## 25. Investigation Limitations

## 26. Outstanding Questions

## 27. Analyst Decisions

## 28. Current Incident Status

## 29. Final Disposition

## 30. Handoff / Ownership

## 31. Evidence References

## 32. Closure Criteria

## 33. Conclusion

Knowledge Check

Question 1 — Why is SOC case documentation important?

Because it preserves investigation context, evidence, decisions, ownership, and conclusions so another analyst or response team can understand and continue the case.

Question 2 — Should the original alert be rewritten after the investigation?

No.

Preserve the original alert and record the final assessment separately.

Question 3 — Why maintain an Evidence Register?

It makes findings and conclusions traceable to their supporting evidence.

Question 4 — Should confirmed and potential impact appear together?

They may appear in the same report, but they should be clearly separated.

Question 5 — Is severity the same as analyst confidence?

No.

Severity represents potential or confirmed security impact. Confidence represents certainty in the assessment.

Question 6 — Why document investigation limitations?

Because missing or incomplete telemetry affects what conclusions can legitimately be made.

Question 7 — Should a false-positive case still contain investigation documentation?

Yes.

The analyst should explain what was investigated and why the activity was determined to be benign or expected.

Question 8 — Does “no evidence of exfiltration” mean exfiltration definitely did not occur?

No.

It means the available investigation evidence did not establish exfiltration.

Question 9 — What makes a good analyst handoff?

Clear current status, confirmed findings, scope, containment status, evidence location, outstanding questions, and the next recommended action.

Question 10 — What is the central question?

“Can another analyst understand exactly what happened, what you investigated, what evidence supports your conclusion, what remains unknown, and what the organization should do next?”

Skills Achieved

After completing this lab, you should understand:

SOC case management
security investigation reporting
case metadata
executive-summary writing
investigation-scope documentation
asset and identity documentation
evidence management
evidence provenance
IOC documentation
timeline reporting
evidence-backed findings
impact documentation
severity assessment
confidence assessment
containment documentation
escalation documentation
remediation planning
positive-control documentation
control-gap documentation
investigation limitations
case handoff
closure criteria
audit-trail maintenance
professional security writing

Professional Takeaway

A weak SOC case looks like:

Alert:
Malware

Investigation:
Looked suspicious.

Result:
Compromised.

Action:
Blocked it.

Status:
Closed.

A professional SOC case looks like:

Original Alert
      ↓
Investigation Scope
      ↓
Evidence Collection
      ↓
Asset / Identity Context
      ↓
IOC Correlation
      ↓
Master Timeline
      ↓
Evidence-Backed Findings
      ↓
Confirmed vs Potential Impact
      ↓
Severity + Confidence
      ↓
Containment Actions
      ↓
Escalation Decision
      ↓
Recommendations
      ↓
Limitations
      ↓
Outstanding Questions
      ↓
Ownership / Handoff
      ↓
Closure Criteria

Always distinguish:

Alert
   ≠
Incident

Observation
   ≠
Interpretation

IOC Match
   ≠
Compromise

Suspicious Activity
   ≠
Confirmed Malicious Activity

Outbound Traffic
   ≠
Data Exfiltration

Potential Impact
   ≠
Confirmed Impact

High Severity
   ≠
High Confidence

No Additional Evidence
   ≠
Activity Never Happened

Containment
   ≠
Case Closure

Resolved
   ≠
Closed Automatically

The strongest SOC report does not try to sound dramatic.

It makes the investigation clear, defensible, reproducible, and actionable.

What’s Next?

➡️ Lab 15 — Enterprise SOC Analyst Capstone

This is the final SOC lab.

You will receive a simulated enterprise security incident involving multiple telemetry sources and will investigate it from the initial alert through final reporting.

You will bring together everything from Labs 01–14:

SOC Environment
      ↓
Alert Triage
      ↓
Authentication Investigation
      ↓
Windows / Linux Analysis
      ↓
Phishing Investigation
      ↓
Endpoint Investigation
      ↓
Network Investigation
      ↓
DNS / Web Analysis
      ↓
SIEM Correlation
      ↓
Threat Intelligence
      ↓
Timeline Reconstruction
      ↓
Incident Scoping
      ↓
Containment
      ↓
Escalation
      ↓
Final SOC Reporting

The complete capstone methodology will be:

Alert → Validate → Investigate → Correlate → Scope → Contain → Escalate → Report

The final challenge will answer one question:

“Can you take an enterprise security alert from first detection to final incident report and produce an investigation another SOC analyst, incident responder, and security leader can trust?”