Change Control Policy

1. Purpose

The purpose of the Change Control Policy is to ensure that all modifications to the SOC environment and Wazuh platform are properly reviewed, communicated, approved, tested, and documented. This prevents system failures, inconsistencies, and security vulnerabilities.

2. Scope

This policy applies to all SOC employees and includes changes made to:

• Wazuh Indexer (Pipelines, Log Retention)
• Wazuh Dashboard (Visualizations, Alerts)
• Wazuh Server (Rules, Decoders, Configuration Files)
• Wazuh Agents (Installation, Removal, Configuration Changes)
• Policies & Procedures (Documentation Updates)
• Any SOC-wide configuration or operational changes

3. Roles & Responsibilities

i) SOC Manager

• Oversees the overall SOC environment
• Manages the change control process
• Approves high-impact changes
• Resolves conflicts or escalations between teams
• Ensures all documentation is complete

ii) Team Leaders

(Indexer, Dashboard, Server, Agents, Policies)

• Lead their assigned area
• Review and approve team-specific changes
• Coordinate testing and validation
• Ensure proper procedures for changes within the team
• Communicate updates in the support channel

iii) SOC Analysts / Team Members

• Identify needed changes within their team
• Submit proposals following change request procedures
• Implement approved changes
• Conduct testing and validation
• Document results and updates in the support channel

iv) Change Control Coordinator

(May be the SOC Manager if no dedicated role exists)

• Maintain the change log
• Track pending, approved, and completed requests
• Facilitate communication across teams

4. Change Control Workflow

All change-related communication, meetings, requests, approvals, and updates must occur in the #support Discord channel.

Categories of Change

i) Standard Change

• Low risk
• Routine and well-documented
• Example: restarting agents, fixing dashboard panels

ii) Normal Change

• Medium risk
• Requires full review, testing, and approval
• Example: updating rules, server configuration

iii) Emergency Change

• High risk but time-sensitive
• May bypass some approvals due to urgency
• Must be fully documented afterward
• Example: disabling malicious rules, stopping a failing service

5. Change Control Steps

i) Step 1 – Submit Change Request

All requests must follow the template and be posted in #support.

CHANGE REQUEST TEMPLATE

Requested By:

• Team:
• Date:
• Type of Change: (Standard / Normal / Emergency)
• Description:
• Reason:
• Systems Affected:
• Risk Level:
• Rollback Plan:
• Testing Plan:
• Expected Change:
• Proposed Change
• Date/Time:

Each request must be reviewed by the Team Lead and SOC Manager.

ii) Step 2 – Review & Approval

Approval requirements:

• Standard: Team Lead
• Normal: Team Lead + SOC Manager
• Emergency: SOC Manager

Team Lead reviews:

• Risk
• Impact
• Dependencies
• Cross-team compatibility

SOC Manager updates the change log after review.

iii) Step 3 – Testing

All changes (except emergency) must be tested in:

• A local environment
• A test agent/server
• A cloned dashboard

Testing must confirm:

• No breakage
• Expected behavior
• No conflict with other teams
• Log ingestion and alerts remain functional

Results must be posted in Discord.

iv) Step 4 – Implementation

Once approved:

• Update progress in #support
• Follow rollback plan if issues occur
• Report any unexpected behavior immediately

v) Step 5 – Post-Change Validation

After implementation:

• Confirm system stability
• Validate logs, dashboards, and alerts
• Ensure no negative impact on other teams
• Document results in the change log

Team Lead will mark requests as:

• Completed
• Rolled Back
• Partially Completed

vi) Step 6 – Documentation

All approved changes must be recorded using:

CHANGE LOG ENTRY

Request Number:

• Title:
• Date Completed:
• Team:
• Implementer:
• Change Summary:
• Results:
• Rollback Triggered? Yes/No

6. Escalation or Exception Paths

i) Escalation Path

If conflicts arise, escalate in the following order:

1. Team Lead
2. SOC Manager
3. CISO (Instructor for the class)

ii) Emergency Path Exceptions

Emergency changes may bypass standard approvals if:

• The system is down
• Logging or dashboards fail
• An active security incident exists

Immediate SOC Manager notification and full documentation are required afterward.

7. Policy Review & Maintenance

• This policy must be reviewed quarterly or after major SOC updates.
• Any team member may propose improvements at any time.