Control A.10.1.1 of the standard requires the organization to document the operating procedures that were identified as necessary in the security policy and which are being discussed at length through the pages of this book. As discussed in Chapter 3 (system integration), the document control principles of ISO9000 are applicable to ISO27001, and all the operating procedures that are part of the organization’s ISMS should be treated in accordance with these requirements, including appropriate management approval.
Again as discussed elsewhere, the best way to make the entire ISMS available to staff is through an intranet and the best way to make it available to third-party contractors is through an extranet. The key benefits of such an approach are that documentation can easily be kept completely up to date and users can be sure that they are seeing the most recent version of ISMS requirements.
While the organization will adopt those procedures that it finds most useful in implementing its information security policy, ISO27002 recom- mends that there should be detailed procedures and operations (or work) instructions (and the level of detail should be appropriate to the size of the organization, with more detail required for larger and more complex ones), which should be worked out between the information security adviser and the responsible operational staff, for:
ᔢ Processing and handling information – which covers, in particular, confi- dentiality requirements and information classification (see Chapter 8).
ᔢ Back-up, which is dealt with in more detail in control A.10.5.
ᔢ Work scheduling requirements, explaining where necessary interdepen- dencies with other systems (so that no one has to find these out the hard way) and earliest job start/latest job completion times (for instance, for back-up procedures).
ᔢ Instructions for handling errors or other exceptional conditions, including restricting use of system utilities, although the organization should have due regard for the comments in Chapter 4 and elsewhere about the need to recruit and retain an information security specialist who has sufficient skill and experience to respond flexibly to new and unusual circumstances. These instructions might, therefore, set out reporting requirements and general guidance, with more specific instructions for junior operatives and inexperienced staff to follow.
ᔢ Contacting appropriate support in the event of unexpected operational or technical difficulties, and what records should be kept of the contacts.
ᔢ Instructions for handling special outputs, such as special stationery, or what to do with failed output for special jobs. Uncontrolled versions of these instructions should be posted near the machines to whose use they relate.
ᔢ Detailed system restart and recovery procedures to follow in the event of system failure. These procedures should be in the ISMS, and controlled copies should be visibly posted near the equipment to which they relate, to enable them to be easily used when required.
There should also be detailed procedures (based on manufacturer’s instruc- tions or user manuals) for all the basic housekeeping functions, including computer start-up and power-down, back-ups, equipment maintenance, mail handling, computer room usage, etc. These procedures should, wherever possible, be reflected in visible reminders as to requirements, posted in the vicinity of where they are relevant. Staff should be trained in their use. Consideration should be given to the possibility that unauthorized staff could see these procedures, and therefore what their classification level is (see Chapter 8) would be relevant to how they are posted.
Remember that overly detailed or infrequently used procedures are as likely to lead to problems as no systems at all. Organizations that outsource their IT services should specify the requirement for proper and appropriate system documentation, to ISO9000 and ISO27001 standards, in the outsourcing contract.
Change management
Control A.10.1.2 of the standard requires an organization to control changes to its information processing facilities, operational systems and application software. These changes usually cause major disruption to the business even when they go well. Inadequate control of these sorts of changes is a common cause of system failures or vulnerabilities. It is also a common cause of unnec- essary expenditure. Formal, documented change control procedures need to be in place, which could be adopted from or be the same as existing project management or change control procedures within the organization. What is important is that for all changes to information processing equipment, software or security procedures, there should be a formal method of control, preferably within an appropriate project governance structure. There is further information about project governance at www.itgovernance.co.uk/ project_governance.aspx.
Procedure change is easy to control, particularly if the ISMS was set up with the information security management forum as the body that steers implementation of the ISMS. It will have to approve all procedural changes, which should be issued under formal document control and supported, where appropriate, by additional staff training.
Changes to operational programs and applications can impact on one another, and the change control process should ensure that this risk is considered. The specialist input of the IT manager, or vendor-certificated experts, should if necessary be considered as part of the change management process. There needs to be a clearly formulated policy dealing with updates,
patches and fixes to major operational and application software; there may not always be a valid business or information security reason for making the upgrade, and therefore the organization’s policy needs to set out the criteria for upgrade decisions and their timings.
In general, the change control procedure for operating programs and appli- cations could be on a standard single-page document that includes:
1. an identification of significant changes, and the business reasons (including, if necessary, a cost–benefit assessment);
2. the planning process for testing changes and gaining user acceptance of the changed system;
3. an assessment of their potential (security and other) impacts, including their impacts on other operational or application software and any hardware changes that might be required;
4. formal approval for the changes to be made;
5. communication to all relevant people of the changes, perhaps by means of copying, or e-mailing, to them uncontrolled versions of the change control form;
6. procedures for aborting and recovering from planned changes that go wrong.
On a more substantial level, any significant change to the network would necessitate a review of the main information security risk assessment and the statement of applicability that was derived from it. Provision should be made in the change control procedure to ensure that this possibility is considered. Any dependent records would need to be amended.