Key Terms: Technical Change Management

An application control policy that permits ONLY explicitly approved applications to execute. Everything not on the list is blocked. Highly restrictive but very effective at preventing unauthorized software execution. Also called a whitelist.

An application control policy that blocks specifically named applications while allowing everything else to run. More flexible than an allow list but potentially less secure — new or unknown threats may not yet be listed. Antivirus is effectively a large deny list.

The specific, approved boundaries of a change. Technical staff must stay within the defined scope. Expanding scope during a maintenance window without approval is called scope creep and can turn minor changes into major outages.

The unauthorized expansion of a change beyond its approved boundaries during implementation. A significant risk in technical change management. Any additional changes discovered during implementation should be submitted as separate change requests.

A period during which a system or service is unavailable. Technical change management must plan for downtime — when it will occur, how long it will last, who is affected, and how to minimize it (e.g., using primary/secondary failover systems).

A downtime minimization strategy where users are switched to a secondary system, the primary is upgraded, then users are switched back. Allows changes to be applied to critical systems without a complete outage. Often automated.

Stopping and restarting an individual system service (daemon) without rebooting the entire operating system. Faster than a full reboot. Used when a change only requires a specific service to reload its configuration.

A full restart of the operating system. Required when changes affect system-level components that cannot be updated while running (e.g., kernel patches, system DLLs). More disruptive than a service restart but sometimes unavoidable.

An older system that has been in production for many years, often no longer supported by its original developer. Legacy applications frequently have undocumented behavior and dependencies. They require careful study and documentation before any changes are made to systems they run on.

A relationship where one service or application requires another to function correctly. Changing component A may require updating component B first. Dependencies can span multiple systems. Failing to identify dependencies is a common cause of change failures.

A system for tracking changes to configuration files, scripts, and system settings over time. Allows administrators to see exactly what changed between point A and point B and to revert to a previous version if a change causes problems.

The process of updating system diagrams, configuration records, IP address lists, and operational procedures after a change is implemented. Outdated documentation is a significant security and operational risk.

A security policy that governs which software is permitted to execute in an environment. Implemented through allow lists (only approved apps run) or deny lists (blocked apps can't run). A key technical control in change management.

A strategy for deploying changes to a subset of systems (a batch) first, verifying success, then proceeding to the remainder. Limits exposure — if the first batch fails, only a small number of systems are affected before the issue is identified.

A document or database entry recording the current configuration of a system — hardware, software, settings, and relationships. Must be updated whenever a change occurs to remain accurate and trustworthy.

A background process or service running on a Linux/Unix system. The Linux equivalent of a Windows service. Daemons can be stopped and restarted independently without rebooting the OS, similar to Windows service restarts.