What Are Reports in Splunk? A Beginner-to-SOC L3 Guide to Creating Professional Security Reports

ratikraj01 -
April 1, 2026
Top view of a cosmetics sales volume report with charts on a wooden desk.
Uncategorized

INTRODUCTION

In a real Security Operations Center (SOC), detecting threats is only part of the job.
The real value comes from how well you communicate those findings.

This is where reports come in.

Reports help transform raw log data into structured, readable insights that can be shared with analysts, managers, and executives.

In this guide, I will explain what reports are, why they matter, and how to create them step-by-step — from beginner level to SOC L3 advanced reporting.

WHAT IS A REPORT IN SPLUNK

A report in Splunk is a saved search that presents data in a structured and reusable format.

Instead of running the same query again and again, you save it as a report and reuse it anytime.

A report can include:

  • A query (SPL)
  • A table or visualization
  • A time range
  • Filters and logic

In simple terms:

👉 A report = saved detection + structured output

WHY REPORTS ARE IMPORTANT

Reports are critical in SOC operations because they:

  • Provide consistent visibility into security events
  • Help track trends over time
  • Support incident investigations
  • Enable communication with non-technical stakeholders
  • Create audit and compliance records

Dashboards show live data.
Reports provide structured snapshots of analysis.

BEGINNER LEVEL — CREATING YOUR FIRST REPORT

Step 1 — Run a basic query

Example:

index=botsv3 EventCode=4688
| table _time New_Process_Name Command_Line

This shows process execution logs.

Step 2 — Save as report

Click:

👉 Save As → Report

Step 3 — Give a name

Example:

Process Activity Report

Step 4 — Choose time range

  • Last 24 hours
  • Last 7 days
  • All time

Step 5 — Save

Now your report is reusable anytime.

INTERMEDIATE LEVEL — ADDING STRUCTURE

Now we improve the report.

1. Add filtering

Example:

| search powershell

This focuses on specific activity.

2. Add logic

Example:

| eval suspicious=if(like(Command_Line,”%enc%”),”YES”,”NO”)

This introduces detection logic.

3. Add aggregation

Example:

| stats count by ComputerName Account_Name

This summarizes data instead of raw logs.

4. Clean output

Example:

| table ComputerName Account_Name count

This makes it readable.

ADVANCED LEVEL — SOC L3 REPORTING

This is where you become professional.

1. Detection-based reports

Instead of generic logs, build reports like:

  • PowerShell Abuse Report
  • Lateral Movement Report
  • Credential Dumping Report

Each report is tied to a MITRE technique.

2. Add MITRE mapping

Example:

| eval MITRE=”T1059.001 – PowerShell Execution”

This aligns your report with industry standards.

3. Use meaningful titles

Example:

“12. SOC L3 – Windows Attack Technique Detections — MITRE T1562.001”

This looks professional and structured.

4. Add descriptions

Every report should explain:

  • What it detects
  • Why it matters
  • What to investigate

5. Use aggregation for executives

Executives don’t want raw logs.

Use:

| stats count by MITRE

This shows trends and impact.

HOW REPORTS DIFFER FROM DASHBOARDS

  • Reports = saved queries (static or scheduled)
  • Dashboards = visual panels (real-time view)

Reports are used for:

✔ Documentation
✔ Sharing
✔ Auditing

Dashboards are used for:

✔ Monitoring
✔ Investigation

SCHEDULING REPORTS (VERY IMPORTANT)

Reports can be automated.

Example use cases

  • Daily SOC report
  • Weekly threat summary
  • Monthly compliance report

How to schedule

While saving report:

  • Enable scheduling
  • Set frequency (daily/weekly)
  • Set time
  • Choose time range

Add alerts (optional)

Trigger alerts when:

  • Count > threshold
  • Suspicious activity detected

EXPORTING REPORTS

Reports can be exported as:

  • PDF
  • CSV
  • Email

This allows sharing with teams and management.

SOC L3 MINDSET FOR REPORTING

At SOC L3 level, reports should answer:

  • What happened?
  • How many times?
  • Which systems are affected?
  • Which users are involved?
  • What is the risk?

Not just logs — but insights.

COMMON MISTAKES TO AVOID

❌ Too much raw data
❌ No structure
❌ No MITRE mapping
❌ No explanation
❌ Cluttered output

FINAL THOUGHT

Reports are not just technical outputs.

They are communication tools that show your ability to:

  • Analyze
  • Structure
  • Explain
  • Present

This is what separates SOC L1 from SOC L3.

#No Tag

Comments are closed