In the third part of this blog post, I will continue describing individual safeguards in greater detail, as you already know from the second part.
Include maintenance work and maintenance intervals in your documentation
The requirement to document any maintenance work that has been performed is often neglected. The same applies to scheduling periodic maintenance activities. However, it is important to give this topic the consideration it deserves. Regular maintenance can indeed decrease the probability that a system will fail, translating into increased availability of your IT services, no matter which IT system is concerned. Office workstations of course tend to get dirty much easier than server systems which are located (hopefully) in a separate room where only few people come and go and that is less subject to environmental influences. Soiled fans and dusty air vents cause an increase in temperature inside the device, which, in turn, means higher energy consumption. For more information, read our blog post titled “Does it make sense to document maintenance work?”.
It is important to keep records of the maintenance work performed and, in case this work is assigned to an external service provider, to make sure that the applicable IT security requirements are adhered to in practice. It is obvious that during maintenance work, information and data are often not protected against unauthorised access. For this reason, make sure to select the external service providers carefully and contractually bind them to comply with all applicable data privacy requirements.
Errors do happen – document them!
An IT documentation would not be complete if errors that occurred were not recorded. Ticketing systems naturally lend themselves for this purpose. In many IT systems, it is possible to specify an e-mail address where error messages will be sent. If you use the e-mail address of your ticketing system, the error message will cause the creation of a ticket and consequently, it will neither be forgotten nor lost. Then, the error case can be forwarded directly to the responsible technician who documents his activities and the chosen solution in the ticket. This allows you to check at any time what was done and when it was done. Link the ticket to the IT system, e.g. by using the inventory or serial number. The result is a device history so that you can later trace how often a device was repaired and even how much was spent on these repairs. This way, you obtain a documentation that covers the entire device life cycle.
Clarify and document all responsibilities
There must be one responsible person and a corresponding substitute for each IT system. Of course, you may bundle responsibilities in order to stay on top of things. For example, you might assign one person who is responsible for the entire server hardware, one for all firewall systems, one for all switches, etc. It is important that you document these responsibilities (including the substitutes) properly so that everybody can look up quickly whom to contact in case of a failure or question. You can use the comment feature in the Docusnap documentation tool for this purpose. If required, create user-defined fields or have them created. The Customizing module will assist you with this task.
Document your data backups
Another very exciting task is the documentation of data backups. Document for each IT system when backups were performed and which data were backed up to which medium. Even if this information is available in the data backup software, you need to document the should-be state. The structure to adopt and the safeguards to take when documenting data backups have already been described in the first part of this post.
Do not forget to describe security incident workflows
It goes without saying that the actual security incidents must be documented. But what can be more beneficial than being prepared for them? So test the applicable procedures virtually before an incident really occurs and then describe them. This ensures that the necessary measures will not have to be devised only at the time of emergency. In this context, remember to document the reporting chain so that you are well prepared for emergencies. Other members of staff must be informed or may decide on immediate action, and managers surely want to be kept informed about the current state of things. In day-to-day business, dealings of the IT department are not of interest to them, but in case of security incidents, you can be sure they will knock at your door. In emergencies, competencies may change: If a security patch must be applied to an IT system urgently, the firewall admin might be allowed to decide this on his own and would not wait until the next periodic maintenance is due for that IT system. Of course, this admin must inform the others, but it does not make sense to wait and thus waste valuable time. Documenting these procedures and the decision-making procedures is a must, and this documentation must be consistent and be filed at the intended location. This is essential for the assessment of past incidents and for process improvement.
As you can see, IT documentation covers many more aspects and activities than just creating a few datasheets for each IT system. It requires a certain effort and includes a broad range of topics to be dealt with. Thus, IT documentation means much more than just a single document and a complete IT documentation is at the same time a valuable collection of information from various sources. Create an IT manual as the parent document that contains all this information and explains the relations between the different topics and items. It can be consulted at any time to find out which information is available from which system. Only this way, you can keep the overview and third persons will be able to find the information they need.
