Antonio Jose Segovia Changes are necessary in the information technology sector, mainly because every so often it is necessary to update servers, systems, etc. But risks (seen from an information security point of view) arise when changes are performed in an uncontrolled way, i.e., confidentiality, integrity, and availability of systems, applications, information… could easily be endangered.
Since we need to improve our ISMS constantly, because it is the philosophy of the PDCA (Plan-Do-Check-Act) cycle of the Information Security Management System according to ISO 27001, we need changes (updating software, hardware, etc.). When a change takes place, the question is – how to manage it. The best way for this is to have a procedure, which establishes steps that we need to follow. By the way, ISO 27001:2013 has in Annex A the control “A.12.1.2 Change management,” which requires that changes to the organization, business processes, information processing facilities, and systems that affect information security are controlled. As you can see, the requirement exists, but there are no particular instructions on how to implement the control (i.e., Change procedure is not a mandatory document), so in this article I’ll suggest one of the ways to manage changes.
Request for change
Each change can be initiated as a Request – better known as a “Request for Change” or “RFC.” This request will also serve as a record and as evidence that a particular change has been requested. The change can be initiated internally (by an employee) or externally (by a customer), and will be registered in a specific form. Changes may affect assets of the organization (hardware, software, networks, etc.), but can also affect processes, services, agreements, etc. Therefore, it is important that detailed information about the type of change is recorded in the RFC.
It is also important to record more information, such as the person requesting the change, the date, the department (or interested party) affected, etc.
Approval process
The RFC is received by a person who is responsible for analyzing it, so this person is the first filter. This person is only responsible for studying the details of the request and identifying the potential impact to the business, including economic impacts and impacts related to the information security (e.g., if the change is to upgrade the operating system of a server that is in the production environment – that can be critical for the business).
Further on, another person (typically the person responsible for changes, e.g., IT Manager or Change Manager), based on the information generated previously, will decide if the change is approved or rejected. For that decision, it is important to consider all the implications that the change may have, including internal ones (departments, compliance with information security requirements, objectives, etc.) as well as external ones (customers, suppliers, etc.).
Finally, if the change is approved, another person (typically appointed for change implementation, e.g., Project Manager) is responsible for planning the change and its implementation. That same person will also plan tests that allow for checking that changes are performed in the correct way.
These three persons can be the same person (this may be recommended for small companies), although it is recommended that they are different for bigger companies, because in such way it will be possible to separate roles/functions.
Finally, not all the changes are equally important, so it is necessary to classify them (for example: Low, Medium, and High). This classification can be based on the impacts to the business and to the ISMS.
Communication
It is also important that the company (for example, through the person responsible for changes) keeps in contact with the person who initiated the change, or interested parties involved in the change (stakeholders, users, customers, public, etc.), because they must be informed of every decision or action that is carried out in relation to the change that is being managed. These communications can be via phone or email (in order to be registered), meetings, etc.
Fall-back and emergency changes
Another important issue to consider is when an error takes place during the implementation of the change. In this case, it is important to have a fall-back procedure to return to the previous state. The person responsible for executing the fall-back procedure can be the same person responsible for the change implementation. Finally, this fall-back procedure can be defined during the planning-for-implementation step, establishing what needs to be done to return to the previous stage. For example: the Windows 8 operating system is updated to Windows 10, but one application fails (we can think of this as an information security incident, because we lost the availability of the system), so in this case it will be necessary to return to Windows 8.
Improving your business by managing changes
Changes in technology are very frequent, and so are changes that affect our ISMS (not only for the sake of improvements, but also in daily business). But, if we don’t manage them according to a procedure, we might find surprises that can (often) involve an information security incident or an interruption of the business, which can also affect our customers. So, if you manage the changes, I am sure that you can improve your organization, because managing activities in any type of business is the best way to improve it – which also means that controlling the changes decreases the headaches and the costs.
To learn how to become compliant with every clause and control from Annex A and get all the required policies and procedures for controls and clauses, sign up for a 14-day free trial of Conformio, the leading ISO 27001 compliance software.
