Documented procedures for operating information processing and communications facility activities should be prepared including computer start-up and closing down, backup, maintenance of equipment, media handling, computer room and mail management, and safety. Operating procedures must be documented and readily available to the teams for which they have relevance. These procedures should cover methods that reduce the likelihood of introducing or enhancing risks due to accidental or ill-advised changes. Before authoring documentation, it is often very important to identify up-front who the intended audience is. For instance, documentation that is intended to have value for new hires (continuity) often requires a greater degree of detail than steps for staff who regularly perform operations tasks. It is very important that operating procedures be treated as formal documents that are maintained and managed with version and approval processes and controls in place. As technology and our systems infrastructure changes, it is an absolute certainty that operational procedures will become out of date or inaccurate. By adopting formal documentation and review processes, we can help reduce the likelihood of outdated procedures that bring forth their own risks — loss of availability, failure of data integrity, and breaches of confidentiality. This control deals with the concept of information security as an operational activity, with its constituent elements being carried out and/or managed by one or more individuals. and outlines a series of operational procedures that ensure an organisation’s information security facility remains efficient and secure, and in line with their documented requirements.
Control
Operating procedures for information processing facilities should be documented and made available to personnel who need them.
Purpose
To ensure the correct and secure operation of information processing facilities.
ISO 27002 Implementation Guidance
Documented procedures should be prepared for the organization’s operational activities associated with information security, for example:
- when the activity needs to be performed in the same way by many people.
- when the activity is performed rarely and when next performed the procedure is likely to have been forgotten.
- when the activity is new and presents a risk if not performed correctly.
- prior to handing over the activity to new personnel.
The operating procedures should specify:
- the responsible individuals.
- the secure installation and configuration of systems.
- processing and handling of information, both automated and manual.
- backup and resilience.
- scheduling requirements, including inter dependencies with other systems.
- instructions for handling errors or other exceptional conditions (e.g. restrictions on the use of utility programs) which can arise during job execution
- support and escalation contacts including external support contacts in the event of unexpected operational or technical difficulties
- storage media handling instructions
- system restart and recovery procedures for use in the event of system failure
- the management of audit trail and system log information and video monitoring systems
- monitoring procedures such as capacity, performance and security
- maintenance instructions.
Documented operating procedures should be reviewed and updated when needed. Changes to documented operating procedures should be authorized. Where technically feasible, information systems should be managed consistently, using the same procedures, tools and utilities.
Operating procedures must be documented and then made available to all users who need them. Documented operating procedures help to ensure consistent and effective operation of systems for new staff or changing resources, and can often be critical for disaster recovery, business continuity and for when staff availability is compromised. Where information systems are “cloud-based” traditional operational activities such as system start-up, shut-down, backup etc become less relevant and may often be outsourced to a cloud provider. In more traditional computing environments and architectures operating procedures are much more likely to be required. It is important that documents are maintained in a correct and current state and should therefore be subject to formal change management and periodic review procedures – this is key, as the auditor will be specifically looking to see this. We often get asked about how much detail is needed, and what areas of the business need to have documented procedures. Take a common sense approach. For example, if you have real staff stability, the implicit procedures are very well understood and resilience is in place across that resource pool, simple bullet points may be enough to form a checklist style documented procedure.
Similarly if procedures are evolving or regularly changing e.g. because of fast growth you want to have procedures that can be easily and quickly updated too. Again if lots of new resource is being added and the area has risk and complexity around it, then more depth to the procedures may be needed so it is unambiguous about what, when, how, who etc. The areas of the business that need to be considered for documented procedures should be where your information assets are at risk through incorrect operation, which of course will be identified as part of the risk assessment . That might include software development, IT management, through to financial accounting, customer management, consulting or manufacturing work etc depending on the nature of the business.
What should we document?
The decision on what areas deserve documentation must be informed by an understanding of organizational risks including issues that have previously been observed. However a good list of items to consider include the following items:
- Configuration and build procedures for servers, networking equipment, and desktops.
- Automated and Manual Information Processing
- Backup procedures
- System scheduling dependencies
- Error handling
- Change Management Processes
- Capacity Management & Planning Processes
- Support and escalation procedures
- System Restart and Recovery
- Special Output
- Logging & Monitoring Procedures
- Any individuals responsible – both incumbents and new operators.
- A set of guidelines that maintain security during the installation and subsequent configuration of any related business systems.
- How information is processed throughout the activity.
- BUDR plans and implications, in the event of data loss or a major event
- Linked dependencies with any other systems, including scheduling.
- A clear procedure for dealing with “handling errors” or miscellaneous events that have the potential to occur
- A full list of personnel to be contacted in the event of any disruption, including clear escalation procedures.
- How to operate any relevant storage media associated with the activity.
- How to reboot and recover from a system failure.
- Audit trail logging, including all associated event and system logs.
- Video monitoring systems that monitor onsite activities .
- A robust set of monitoring procedures that cater to the operational capacity, performance potential and security of said activity.
- How the activity should be maintained, in order to be kept at optimal performance levels.
All of the above procedures should be subject to periodic and/or ad-hoc reviews, as and when required, with all changes being ratified by Management in a timely manner to safeguard information security activity across the organisation.ocedures and documented procedures for system operations should be treated as managerial authorized formal documents and alterations. Where technically feasible, IT systems should be consistently administered using the same procedures, tools, and utilities.
