It needs to be remembered that no cybersecurity program can exist as a perfect, static implementation. Continuous improvement is needed and encouraged to fine-tune the cybersecurity program to address your small business’s risk appetite and specific needs. However, change can be difficult and will easily cause chaos and disruption if not addressed properly. You also need to have a clear understanding of which changes are feasible and which are not.
Changes can be divided into minor changes and major changes. A minor change to your cybersecurity program would be something like changing the second authentication factor in an MFA deployment from a One Time Passcode to a Push Notification. Assuming you have a flexible authentication provider implemented, this change shouldn’t be a huge deal. A major change, however, will likely require careful assessment, planning, and testing. A major change to your cybersecurity program would be something like migrating from an on-premises Active Directory environment to a cloud-hosted Microsoft Entra ID environment. Making this change would require a completely new iteration of the framework to address things like identity inventories, plans and schedules, and stakeholder communication.
To carefully manage change, every good change management program should start with a standardized way to request change. A Request for Change (RFC) document is an industry-standard document that a party can use to formally request a change. A proper RFC should contain the following elements:
- A description of the desired change.
- An explanation of the expected impact on the business as a whole.
- An assessment of the risk(s) that may be involved with making the change.
- A rollback plan to be used if the change fails.
- Identities of specific individuals/groups that will be involved with the change.
- Proposed schedule for implementing the change.
- The systems and services that will be affected by the change.
Minor changes can usually be approved by individual administrators in a less formal approach. For example, a request for a change to a specific Wi-Fi or Operating System setting can usually be fully assessed and approved by you (the business owner) and your IT consultant in a few minutes.
Major changes need to be approved by a responsible group of individuals known as the Change Advisory Board (CAB). Since this documentation is exclusive to addressing your organization’s cybersecurity program, we can assume that all change requests made in this context will be related to cybersecurity program components. In that case, you can designate the program’s Steering Committee as the Change Advisory Board. Since the Steering Committee assesses and approves all of the controls and features of the cybersecurity program, it seems only natural that they will assess and approve/reject any requested changes. Major change requests may require several meetings of the Steering Committee/CAB to make an informed decision. If a major change has been approved, then it will likely become necessary to repeat Stage 2: Plan of the CyberLadder framework within the context of the specific change. Major Requests for Change (RFCs) and Audits (covered later) are the two main drivers for embarking on a new iteration of the framework.
To organize change requests and keep them accountable, you should document them in a Change Register, also known as a Change Log. Each change should be assigned a unique change ID, a basic description of the desired change, and the status of the change request. Ensure that the change register stays updated throughout the change process and is stored securely with other official program documents.
A blank template for a Change Register can be downloaded below: