Security Procedures

Change Management and the Change Control Board

Security procedures are the step-by-step instructions for how security-relevant activities must be performed. Where policy states what must be done and standards specify the technical requirements, procedures define the exact sequence of actions, decision points, and responsibilities. Procedures make policy enforceable in daily operations.

Change Management vs. Change Control

Change management is the broad process for managing all changes to IT systems. Change control is the formal approval mechanism within change management that ensures changes receive appropriate review before implementation.

• Change management: the overall discipline covering how changes are requested, categorized, reviewed, approved, implemented, and documented.
• Change control: the specific formal approval step. A change control process may require that proposed changes pass through the Change Control Board before implementation.

The Change Control Board (CCB)

The Change Control Board is the formal governance body responsible for reviewing and approving or rejecting proposed changes to IT systems. The CCB ensures that changes are evaluated for risk, have appropriate rollback plans, and are scheduled appropriately.

Change control workflow:

1. Scope definition: The change requestor documents exactly what is being changed, which systems are affected, and the reason for the change.
2. Risk analysis: The potential security and operational impact is assessed. High-risk changes (touching production firewalls, active directory, or core databases) require more rigorous analysis than routine patches.
3. Implementation plan: Step-by-step instructions for implementing the change, including timing, resource requirements, and dependencies.
4. End-user impact assessment: Determination of how the change affects users and whether they need advance notification.
5. CCB review and approval: The board reviews the change request and either approves, rejects, or requires modification before resubmission.
6. Backout plan: The documented procedure for reverting to the previous state if the change fails or causes unexpected issues. This must be defined before the change window, not improvised during a failure. Without a backout plan, a failed change may leave systems in an undefined state.
7. Documentation: After implementation, the change and its outcome are documented. Approved changes that produce unexpected results must be escalated.

Emergency Changes

Emergency changes (e.g., patching an actively exploited critical vulnerability) cannot wait for the next scheduled CCB meeting. Emergency change procedures allow expedited approval — typically from a designated authority (CISO, IT director on-call) — while still requiring post-hoc documentation, risk assessment completion, and CCB review at the next meeting. Emergency change procedures do not eliminate review; they expedite it.

Onboarding and Offboarding Procedures

Onboarding Procedures

Onboarding is the process of provisioning access, equipment, and training to a new employee or contractor. Security-focused onboarding ensures that new personnel enter the environment with appropriate access and awareness:

• AUP acknowledgment: Before accessing any organizational system, the new user must read and sign the Acceptable Use Policy. This is often the first required step. The signature creates documented notice that the user understands permitted and prohibited activities.
• Account creation with least privilege: User accounts are created with the minimum permissions required for the person's job role. Access is granted based on job function, not seniority or assumed future needs. Additional access requires a formal access request with business justification and approval.
• Role-based group assignment: The new account is added to the appropriate security groups based on job function, inheriting the permissions defined for that role (RBAC).
• Hardware provisioning: Workstations, laptops, and mobile devices should be provided as pre-configured images with security tools installed (EDR, encryption, MDM enrollment). Pre-configured hardware ensures consistent security baseline; users should not receive blank hardware to self-configure.
• Security awareness training: New employees must complete security awareness training before being given unescorted access to facilities or systems. Training covers phishing recognition, data handling, incident reporting, and policy compliance.

Offboarding Procedures

Offboarding is the process of revoking access and recovering assets when an employee or contractor departs. Offboarding failures are a significant security risk; many insider incidents occur because former employees retained active access after separation.

• Account disabled, not deleted: The departing employee's accounts must be disabled immediately on the last day of employment. Accounts must NOT be deleted immediately. Reason: the account may be associated with encrypted data, digital signatures, or other records that require the account to remain for decryption or verification. Deleting the account may destroy the ability to decrypt files encrypted by that user. Accounts are typically disabled for a retention period (30–90 days) and then deleted after all dependencies are resolved.
• Hardware recovery: All organizational hardware (laptop, mobile phone, access badges, security tokens, keyfobs) must be recovered before or on the last day. Receipts should be documented.
• Data management: Ensure any data owned by the departing employee that is needed for business continuity is transferred to an appropriate successor or preserved. Personal data on organizational devices must be handled per policy.
• Pre-planned process: Offboarding should not be improvised. The process must be pre-planned, documented, and assigned to specific roles (HR, IT, security, facilities) with clear responsibilities and a checklist to ensure nothing is missed.
• Access removal scope: Logical access (all accounts, VPN, cloud services, third-party SaaS tools), physical access (badge deactivation, key recovery), and remote access must all be addressed simultaneously.

Playbooks, SOAR, and Governance Structures

Security Playbooks

A security playbook is a documented, step-by-step procedure for responding to a specific type of security event or performing a specific security operation. Playbooks operationalize incident response plans into actionable instructions.

• Step-by-step format: Each step in a playbook is a specific, actionable instruction: "Isolate the affected system from the network by disabling the switch port listed in the asset database" rather than "contain the system."
• Conditional logic: Playbooks include decision points: "If the system is a critical server (listed in Tier 1 assets), escalate to the IR lead before isolation. If the system is a standard workstation, proceed with isolation."
• Manual vs. automated execution: Playbooks can be executed manually by human analysts following the steps, or automatically by security orchestration platforms that execute the steps as code.
• Common playbook types: Phishing response, ransomware containment, account compromise investigation, DDoS mitigation, malware infection response, and data breach notification.
• Monitoring and revision: Playbooks must be updated as threats evolve, technology changes, and post-incident reviews identify procedural gaps. A playbook that was accurate last year may be incorrect if the environment has changed.

SOAR: Security Orchestration, Automation, and Response

SOAR (Security Orchestration, Automation, and Response) platforms enable playbooks to be executed automatically, integrating with the organization's security tools to take response actions without human intervention for high-confidence scenarios.

• Orchestration: Connects disparate security tools (SIEM, EDR, firewall, ticketing system, threat intelligence) and coordinates actions across them based on playbook logic.
• Automation: Executes playbook steps automatically when trigger conditions are met. Example: when an EDR alert fires for known malware, SOAR automatically isolates the host, creates a ticket, notifies the on-call analyst, and queries threat intelligence for the malware hash — in seconds, without human intervention.
• Response: Takes active response actions: blocking IPs in firewalls, disabling accounts in Active Directory, quarantining email messages, isolating endpoints — actions that would take a human analyst minutes or hours are completed in seconds.
• Value: Reduces mean time to respond (MTTR), eliminates analyst fatigue for repetitive low-level decisions, and ensures consistent execution of playbook steps that might be missed under pressure.

Governance Structures

Security governance defines who has authority over security decisions, how that authority is exercised, and how security programs are structured and overseen.

Centralized vs. Decentralized Governance

Organizations must choose how security governance authority is distributed:

• Centralized governance: A single security team (CISO and security department) makes all security decisions and sets standards enforced across all business units. Advantages: consistent standards, unified visibility, efficient resource use. Disadvantages: may be slow to adapt to business unit-specific needs; single point of failure if the central team is understaffed.
• Decentralized governance: Each business unit has its own security team with independent decision-making authority. Advantages: faster response to business unit needs; more context-appropriate decisions. Disadvantages: inconsistent standards across the organization; gaps between business units; harder to maintain enterprise-wide visibility.
• Federated governance (hybrid): Central security team sets enterprise-wide standards and policy; business unit security teams handle implementation and local decisions within those standards. Most common approach in large organizations.