ISO 27001:2022 Example of Procedure for control of documented information

1 Introduction

“Documented information” is defined by ISO as “information required to be controlled and maintained by an organization and the medium on which it is contained”. This term covers what used to be referred to as “documents and records” and for reasons of clarity this procedure still draws a distinction between these two types of documented information. The use of documented information is an essential part of the Information Security Management System (ISMS) in order to set out management intention, provide clear guidance about how things should be done and provide evidence of activities that have been performed. The ISO/IEC 27001 standard requires that all documented information that makes up the ISMS must be controlled to ensure that it is available and suitable for use, where and when needed, and is adequately protected. Such control is essential in order to ensure that the correct processes and procedures are in use at all times within the organization and that they remain appropriate for the purpose for which they were created. The general principles set out in the standard and adopted within this procedure are that all documented information must be:
➤ Readily identifiable and available
➤ Dated, and authorised by a designated person
➤ Legible
➤ Maintained under version control and available to all people and locations where relevant activities are performed
➤ Promptly withdrawn when obsolete and retained where required for legal or knowledge preservation purposes
This procedure sets out how this level of control will be achieved within XXX.

2 Document Control Procedure

This procedure applies to “documents” (as opposed to “records” which are covered later) which are generally created via a word processor (or similar office application) and describe management intention such as policies, plans and procedures.

2.1 Overview
The overall process of control for documents is shown in the diagram below.

Each of these steps is described in more detail in the remaining sections of this procedure.

2.2 Creation of Documents
The creation of documents will be at the request of the XXX management team and may be done by any competent individual appropriate to the subject and level of the document. However, there are a number of rules that must be followed when creating a document to be used in the ISMS.

2.2.1 Naming Convention
The convention for the naming of documents within the ISMS is to use the following format:

ISMS-DOC-xx-yy Document Title Vn Status dd

where:

  • ISMS = Information Security Management System
  • DOC = Document
  • XX = Dept
  • yy = Unique document number
  • Document Title = Meaningful description of document
  • Vn= Version n
  • Status = Status of document (Draft or Final)
  • dd = Number of draft, if appropriate

2.2.2 Version control

A unique number will be allocated for each document and an index of document references maintained within the ISMS Quality System.

Document version numbers will consist of a major number only e.g. V2 is Version 2.
When a document is created for the first time it will have a version number of 1 and be in a status of Draft. Each time a draft is distributed, any further changes will result in the draft number being incremented by 1 e.g. from 1 to 2.
For example, when a document is first created it will be Version 1 Draft 1. A second draft will be V1 Draft 2 etc. When the document is approved it will become V1 Final.
The version number will be incremented when a subsequent version is created in draft status.
For example, a revision of an approved document which is at V1 Final will be V2 Draft 1 then V2 Draft 2 etc. until approved when it will become V2 Final.
Documents must include a revision history as follows:

Version DateRevisionAuthorSummery of change
Revision History

Once the document reaches its final version, only approved versions should be recorded in this table.

2.2.3 Document Status
The status reflects the stage that the document is at, as follows:
Draft = Under development and discussion i.e. it has not been approved
Final =Following approval and release into live work environment

2.2.4 Documents of External Origin
Documents that originate outside of the organization, but form part of the ISMS will be allocated a reference and a header page attached at the front of the document, setting out information that is normally included in internal documents i.e.:

  • Document reference
  • Version
  • Date
  • Status
  • Distribution

Such documents will then be subject to the same controls as those that originate internally.

2.3 Document Review

Draft documents will be reviewed by a level and number of staff appropriate to the document content and subject.
Guidelines are as follows:

Document TypeReviewer
Strategy
Policy
Procedure
plan

Once approved, the date of next scheduled review should be recorded in the Information Security Management System Documentation Log.

2.4 Document Approval

All documents must go through an approval board to ensure that they are correct, fit for purpose and produced within local document control guidelines. The board will differ dependent upon the type of document and may go to numerous groups prior to being approved. In standard terms, approval boards are:

Document TypeApprover
Strategy
Policy
Procedure
plan

Each document that requires approval should have a table for the purpose as shown below:

Approval

NamePositionSignatureDate

Once approved a copy of the document must be printed and signed by the approver. [Note – you may choose to do this electronically rather than by printing a copy]. This copy will then be retained in a central file
Upon approval of a new version of a document, all holders of previous versions will be instructed to obtain a new version and destroy the old one.

2.5 Communication and Distribution

A distribution list will be included as follows:
Distribution

Name Title

This list must be accurate as it will be used as the basis for informing users of the document that a new version is now available.

2.6 Review and Maintenance of Documents

All final documents must be stored electronically and in paper format both locally and off-site to ensure that they are accessible in any given situation.
ISMS documents are stored electronically on the shared drive under the relevant sub-folder (e.g. Management responsibility, Management review etc.). The drive is a shared drive to which all appropriate members of XXX have access, in line with the published Access Control Policy.
Final documents are stored in paper format in a filing structure that mimics the electronic version. [State the location of the paper files].
A full copy of final documentation will be reproduced and stored within the Definitive Media Library.

2.7 Archival of Documents

Approved documents exceeding their useful life are stored in a Superseded Folder on the shared drive in order to form an audit trail of document development and usage. They should be marked as being superseded in order to prevent them being used as a latest version by mistake.

2.8 Disposal of Documents

Paper copies of approved documents that have been superseded are to be disposed of in secure bins or shredded, in line with agreed Asset Handling Procedures.

3 Records Lifecycle

This section describes the control of the type of documented information that generally shows what has been done i.e. is a “record” of activity, such as a completed form, security log or meeting minutes.

3.1 Identification

There is a variety of types of record that may form part of the ISMS and these will be associated with the specific processes that are involved, such as:

  • Security incidents
  • Change requests
  • Configuration items
  • Security event logs

In addition, there will be more general items such as meeting minutes which could apply across processes. In terms of identification, in many cases this will be dictated by the tool creating the record, for example a unique numbering system such as INC000001 for security incidents or CHG000001 for changes will be used by the tool.

3.2 Storage

Many records within the ISMS will be stored in application databases specifically created for the purpose e.g. the security incident database. For non-database records, a logical filing structure will be created according to the area of the ISMS involved. Where possible, all records will be held electronically; paper documents should be scanned in if an original electronic copy is not available.

3.3 Protection

Records held in application databases will be subject to regular backups in line with the agreed backup policy. File storage areas will also be backed up regularly, with all latest backups held at an offsite location. Access to the records will be restricted to authorised individuals in accordance with the XXX’s Access Control Policy.

3.4 Retrieval

Records will generally be retrieved via the application that created them e.g. the service desk system for security incidents and an event viewer for logs. Reporting tools will also be used to process and consolidate data into meaningful information.

3.5 Retention

The period of retention of records within the ISMS will depend upon their usefulness to XXX and any legal, regulatory or contractual constraints. Security- related service desk records are useful for historical trend analysis and so will be kept for a period of at least 7 years. Particular care will be taken where records may have some commercial relevance in the event of a dispute e.g. contracts and minutes of meetings with suppliers and these should be kept for the same length of time. Records that are particularly detailed and only relevant for a short period of time such as server event logs should only be kept as long as there is an immediate requirement for them. Specific retention periods are set out in the Records Retention and Protection Policy.

3.6 Disposal

Many systems provide for the concept of archiving and in most cases, this should be used rather than deletion. However, once it has been decided to dispose of a set of records they should be deleted using the appropriate software e.g. the service desk system will provide a facility to delete security incident records. If such records are held on hardware that is also to be disposed of then all hard disks must be shredded by an approved contractor.Paper copies of records that are to be disposed of should be shredded in line with agreed Asset Handling Procedures.

Leave a Reply