Compliance & Governance for SOC Analysts

Why SOC Analysts Need Compliance Knowledge

There is a common misconception among junior analysts: "Compliance is for auditors and managers, not for me." This is wrong, and here is why.

Compliance frameworks dictate the minimum security requirements your organization must meet. Those requirements directly translate into what your SIEM must log, how long you retain data, what you must detect, how fast you must respond, and what you must document during an incident. When a compliance audit fails, it is often because the SOC did not have the right logs, the right detections, or the right response documentation — all things that fall squarely on the security operations team.

Risk Management Basics

Before diving into specific frameworks, you need to understand the foundational concept they all share: risk management.

The Risk Equation

Risk = Likelihood × Impact

Likelihood: How probable is it that a threat will exploit a vulnerability? Ranges from rare (major infrastructure failure) to almost certain (daily internet scanning against public servers).

Impact: How severe are the consequences if the threat materializes? Ranges from negligible (single workstation temporarily offline) to catastrophic (full customer data breach with regulatory penalties).

Risk Response Strategies

When you identify a risk, there are four possible responses:

Risk Registers and the SOC

Organizations maintain a risk register — a living document that catalogs identified risks, their ratings, response strategies, and owners. SOC analysts interact with the risk register in several ways:

• When you discover a new vulnerability or attack vector, it may need to be added to the register
• When triaging alerts, knowing which assets are high-risk (from the register) helps you prioritize
• When writing detection rules, the risk register tells you which threats the organization considers most important
• During incidents, the risk register provides context about which systems carry the highest business impact

NIST Cybersecurity Framework (CSF)

The NIST Cybersecurity Framework is the most widely adopted cybersecurity framework in the United States and increasingly worldwide. Published by the National Institute of Standards and Technology, it provides a common language for managing cybersecurity risk.

Click to enlarge

The Five Core Functions

As a SOC analyst, you operate primarily in Detect and Respond, but understanding all five functions gives you context about why certain controls exist and what happens upstream (Identify, Protect) and downstream (Recover) from your work.

NIST CSF and Daily SOC Operations

Detect function in practice:

• DE.AE-2 (Anomalies and Events): "Detected events are analyzed to understand attack targets and methods." This is literally alert triage — your daily work.
• DE.CM-1 (Continuous Monitoring): "The network is monitored to detect potential cybersecurity events." This is your Suricata deployment and Wazuh network log collection.
• DE.CM-4 (Malicious Code Detection): "Malicious code is detected." Your YARA rules, Wazuh FIM, and endpoint detection capabilities.
• DE.DP-4 (Detection Process): "Event detection information is communicated." Shift handoffs, incident reports, escalation procedures — the soft skills from Lesson 1.5.

Respond function in practice:

• RS.AN-1 (Analysis): "Notifications from detection systems are investigated." Every alert you triage.
• RS.AN-3 (Forensics): "Forensics are performed." Velociraptor endpoint investigation, PCAP analysis.
• RS.CO-2 (Communication): "Incidents are reported consistent with established criteria." Escalation procedures, notification timelines.
• RS.MI-1 (Mitigation): "Incidents are contained." Blocking IPs, isolating hosts, disabling compromised accounts.

ISO 27001 — Information Security Management

ISO 27001 is the international standard for Information Security Management Systems (ISMS). While NIST CSF provides a framework for organizing security activities, ISO 27001 provides a certifiable management system with mandatory requirements and auditable controls.

ISMS Structure

An ISMS is a systematic approach to managing sensitive information. It includes:

• Policies: High-level statements of security intent (e.g., "All systems shall log authentication events")
• Procedures: Step-by-step instructions for implementing policies (e.g., "Configure Wazuh agents to collect Windows Security Event Log")
• Controls: Technical and administrative safeguards that reduce risk (e.g., "IDS deployment" is a control)
• Audits: Periodic assessments that verify controls are implemented and effective

ISO 27001 Annex A Controls Relevant to SOC

ISO 27001 Annex A contains 93 controls organized into 4 categories. SOC analysts interact most with:

Audit Readiness

ISO 27001 audits happen annually. Auditors will:

• Review your SIEM configuration to verify required logs are collected
• Examine incident response records to verify documented procedures were followed
• Check alert response times against SLAs defined in your policies
• Verify that security events are classified using a consistent methodology

PCI-DSS Essentials for SOC

The Payment Card Industry Data Security Standard (PCI-DSS) applies to any organization that stores, processes, or transmits credit card data. Even if your organization is not in retail or finance, understanding PCI-DSS is valuable because its requirements represent best practices that many frameworks share.

Requirement 10: Track and Monitor All Access

Requirement 10 is the most SOC-relevant section of PCI-DSS. It mandates:

Requirement 11: Regularly Test Security Systems

HIPAA and Data Protection

The Health Insurance Portability and Accountability Act (HIPAA) applies to healthcare organizations and their business associates. Its security requirements affect SOC operations in environments that handle Protected Health Information (PHI).

HIPAA Security Rule Highlights for SOC

• Access Controls (§164.312(a)): Technical policies to allow only authorized access to ePHI. SOC must detect and investigate unauthorized access attempts.
• Audit Controls (§164.312(b)): Hardware, software, and procedural mechanisms to record and examine access to information systems containing ePHI. This means SIEM logging is mandatory.
• Integrity Controls (§164.312(c)): Policies to protect ePHI from improper alteration or destruction. FIM on systems storing health data is a HIPAA control.
• Transmission Security (§164.312(e)): Technical measures to guard against unauthorized access to ePHI during electronic transmission. Network monitoring (Suricata) for unencrypted PHI transmission.
• Incident Response (§164.308(a)(6)): Policies to identify, respond to, and mitigate security incidents. Documented incident response procedures are mandatory, not optional.

Breach Notification Requirements

HIPAA requires notification within 60 days of discovering a breach affecting PHI:

• Notification to affected individuals
• Notification to the Department of Health and Human Services (HHS)
• For breaches affecting 500+ individuals, notification to media

The SOC's investigation timeline directly affects whether the organization can meet these notification deadlines. Delayed detection means delayed notification, which means regulatory penalties.

Security Policies and Procedures

Frameworks create requirements. Policies turn requirements into organizational commitments. Procedures turn policies into actionable steps. As a SOC analyst, you operate at the procedure level, but understanding the policy layer explains why your procedures exist.

Key Policies That Affect SOC Operations

Acceptable Use Policy (AUP): Defines what employees are permitted and prohibited from doing on company systems. SOC relevance: when you see an alert for a user visiting a prohibited website category or installing unauthorized software, the AUP is what determines whether this is a policy violation requiring action.

Incident Response Policy: Defines the organization's approach to security incidents — classification levels, escalation criteria, response timelines, communication protocols, and roles/responsibilities. This policy is the blueprint for everything you do during an incident.

Data Classification Policy: Defines categories of data sensitivity (Public, Internal, Confidential, Restricted) and handling requirements for each. SOC relevance: when triaging an alert involving data access, the classification of the accessed data determines the severity of the response. Unauthorized access to Public data is a low-priority policy violation. Unauthorized access to Restricted data is a critical incident.

Log Management Policy: Defines what must be logged, how long logs must be retained, who can access logs, and how log integrity is protected. This policy directly shapes your SIEM configuration and determines whether you have the data needed to investigate incidents.

DATA CLASSIFICATION AND SOC RESPONSE

┌────────────────────────────────────────────────────┐
│  RESTRICTED (PII, PHI, PCI, credentials)           │
│  → Unauthorized access = Critical incident         │
│  → Mandatory escalation to L2 + Legal              │
│  → Evidence preservation required                  │
├────────────────────────────────────────────────────┤
│  CONFIDENTIAL (financial reports, source code)     │
│  → Unauthorized access = High-severity incident    │
│  → Escalation to L2, notify data owner             │
├────────────────────────────────────────────────────┤
│  INTERNAL (employee directories, process docs)     │
│  → Unauthorized access = Medium-severity event     │
│  → L1 investigation, document and close            │
├────────────────────────────────────────────────────┤
│  PUBLIC (marketing material, published reports)    │
│  → Unauthorized access = Low-priority, log only    │
└────────────────────────────────────────────────────┘

Compliance-Driven Detection Requirements

The intersection of compliance and detection engineering produces mandatory detection rules — alerts that your SIEM must generate to satisfy regulatory requirements. These are not optional tuning decisions.

What You MUST Log (Across Major Frameworks)

How Compliance Affects SOC Operations Daily

Click to enlarge

Detection SLAs: Many frameworks require detection within a specific timeframe. If your SIEM has a 4-hour parsing delay, you may not meet the "detect within 24 hours" requirement.

Response timelines: PCI-DSS requires daily log review. HIPAA requires breach notification within 60 days. GDPR requires breach notification within 72 hours. Your triage SLAs and escalation procedures must account for these timelines.

Evidence preservation: During a compliance-relevant incident, you must preserve evidence in a forensically sound manner. This means read-only copies of logs, chain of custody documentation, and tamper-evident storage. Deleting logs to "clean up" after an incident is a compliance violation.

Documentation requirements: "We investigated and found nothing" is not sufficient documentation. Compliance requires evidence of what you checked, when you checked it, what you found, and what decision you made. The STAR format from Lesson 1.5 satisfies these requirements when applied consistently.

What's Next

Module 1 is now complete. You have built the foundation: SOC operations, the ATT&CK framework, alert classification, the CyberBlueSOC toolset, soft skills, career paths, and compliance frameworks. In Module 2: SIEM Mastery with Wazuh, you will move from theory to practice. You will learn to navigate the Wazuh dashboard like a veteran analyst, write KQL queries that pinpoint threats in millions of events, understand how Wazuh rules detect attacks in real time, and build custom dashboards that surface the signals you care about. Module 2 is where your SOC muscle memory starts forming. Get ready to triage alerts at speed.