ISO TR 15801:2017 pdf free download.Document management Electronically stored information Recommendations for trustworthiness and reliability.
ISO TR 15801 defines recommended practices for electronic storage of business or other information In an electronic form. As such, complying with its recommendations is of value to organizations even when the trustworthiness of the stored information is not being challenged, especially in jurisdictions with e-discovery legislation.
Information originates from many sources. This document covers information in any form, from the traditional scanned images, word processed documents and spreadsheets to the more moderns forms which include e-mail, web content, instant messages, CAD drawing files, blogs. wikis, etc. Also included Is information stored In databases and other data storage systems. Recommendations In this document can be useful In systems that use local and/or cloud storage.
Users of this document should be aware that the implementation of these recommendations does not automatically ensure acceptability of the evidence contained within the information. Where electronically stored information (ESI) might be required in court or other adversarial situation, implementers of this document are advised to seek legal advice to ascertain the precise situation within their relevant legal environment.
This document describes means by which it can be demonstrated, at any time, that the Information created or existing within an Information management system has not changed sInce It was created within the system or imported into It.
Regardless of the original format, it will be possible to demonstrate that information stored in a trustworthy information management system can be reliably reproduced in a consistent manner and accurately reflects what was originally stored without any material modification.
Alternative versions of the information in a document might legitimately develop, e.g. revision of a contract. In these cases, the new versions are treated as new documents. The same principle can be applied when a significant change Is made to a document In a workilow environment.
Information technology based systems can store, in an electronic form, both documents and records. This document describes means for storing all types of ESI in a trustworthy and reliable manner, as part of an information governance strategy. Where records (as defined in ISO 15489-1) are stored, the requirements of this document can be used in conjunction with those specified in ISO 15489-1 to ensure that the policies and procedures described in this document work in conjunction with those specified in ISO 15489-1.
When Information preservation Is considered, the requirements olISO 14641 can be used in conlunction with this document. Readers are advised to use this document in coniunction with other local sources, particularly with relevance to governmental and legal requirements in their respective jurisdictions.
Document management — Electronically stored information — Recommendations for trustworthiness and reliability
This document describes the implementation and operation of information management systems that store and make available for use electronically stored information (ESI) in a trustworthy and reliable manner. Such ESI can be of any type, including page based information, information in databases and audio/video information.
This document Is for use by any organization that uses systems to store trustworthy ESI over time. Such systems incorporate policies, procedures, technology and audit requirements that ensure that trustworthiness of the ESI is maintained.
This document does not cover processes used to evaluate whether ESI can be considered to be trustworthy prior to it being stored or imported into the system, However, it can be used to demonstrate that, once the electronic information is stored, output from the system will be a true and accurate reproduction of the ESI created and/or Imported.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edlticm of the referenced document (including any amendments) applies.
ISO 12651 (all parts). Electronic document management — Vocabulary
3 Terms and definitions
For the purposes of this document, the terms arid definitions given in ISO 12651 (all parts) and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.nre/
— ISO Online browsing platform: available at http:i/wwwici.nrg/ohp
electronically stored information
data or information of any kind and from any source, whose temporal existence is evidenced by being stored in or on any electronic medium
Note 1 to entry: ESI includes traditional e-mail, memos, letters, spreadsheets, databases, office documents. presentations and other electronic formats commonly found on a computer, ESI also includes system, application and file-associated metadata such as imestanips, revision history, file type etc.
Note 2 to entry: Electronic medium can take the form of, but is not limited to, storage devices and storage elements,
[SOURCE: lSO/IEC 27040:2015, 3.16]
groups of related information
Note 1 to entry In specific applications, groups can be identified as sets, files”, collections or other similar terms.
EXAMPLE Invoices, financial documents, data sheets, correspondence.
ability to demonstrate authenticity, integrity and availability of ES! (ii) over time
information technology system with the capability of managing ES! (ii) in a trustworthy (i1) manner
4 Information management policy
Information is one of the most important assets that any organization has at its disposal. Everything an organization does involve using Information in some way. The quantity of Information can be vast and there are many different ways of representing and storing it. The value of Information used and the manner In which it Is applied and moved within and between organizations can determine the success or failure of those organizations.
Information, like any other asset, needs to be classified, structured, validated, valued, secured. monitored, measured and managed efficiently and effectively.
This clause describes documentation that states the organization’s policy for the management of ESI. Additionally, this clause provides guidance to organizations with respect to the level of documentation required to enable an organization to clearly establish how the ESI contained In a trusted system is reliable, accurate and trustworthy. Availability of this documentation can also be used to demonstrate that ESI management is part of normal business procedures.
Where an information management system manages ESI that might be used as evidence in any legal or business process, the appropriate legal advisors should be consulted (see Mi to ensure that compliance with relevant legal or regulatory requirements is demonstrable. As legal and regulatory requirements vary from country to country (and sometimes within a country), legal advice should cover all relevant lurisdictions
4.2 Information management policy document
An information management policy document (the policy document) should be produced, documenting the organizations policy on the storage of ESI, as applicable to the trusted system.
The policy document should contain sections which:
— specify what ESI is covered (see i2.2);
— state policy regarding roles and responsibilities for ESI (see iL):
— state ESI security classification policies (see 42A);
— state policy regarding storage media (see A2..i);
— state policy regarding electronic file formats and version control (see i2.);
— state policy for the use of outsourcing (see iZl);
— state policy regarding relevant information management standards (see jZJ);
— define ESI retention and disposal policies (see j2
— define responsibilities for Information management functions (see 42JIl);
— define responsibilities for monitoring compliance with this policy (see iZJJ.).
The policy document should be approved by senior management of the organization and should be reviewed at regular intervals.
Essential to this Implementation of this document is the agreement and Implementation of a retention schedule for ESI. Where reference Is made to the policy document In the rest of this document, the retention schedule is included in such a reference.
4.2.2 ESI covered
In order to define the organization’s Information management policy. InformatIon should be grouped Into types, the policy for all Information within a type being consistent. For example. information types can be specified either by reference to application (e.g. financial prolections, invoices, customer address list), by association with a specific business process (e.g. applications, complaints, renewals) or by reference to generic groups (e.g. accounting data, customer documents, manufacturing documents),
During the drafting of the policy document, specific information might need to be regrouped to ensure consistency of policy within an information type.
The policy document should list all types of Information that are to be stored in compliance with the policy. The policy document should Include, as an Information type, all Information produced, received and stored In compliance with the policy.
4.2.3 ESI roles and responsibilities
The individuals or teams responsible for the management of the ESI should be identified and their roles defined. These roles should include:
— following a systematic approach to ESI management;
— being business focused and aware of the current business requirements;
— being able to communicate at all levels within the organization;
— having a good understanding of risk management in relation to trustworthy ESI.
4.2.4 ES! security classification
In some applications, it may be appropriate to implement an ESI security classification system, typically
used to indicate the accessibility of particular information. In government and other public bodies, this
Is often Indicated by the use of security 9abels” such as “top secret”, “classified” or “publicly available”.
In the private sector, security classification schemes may be alIgned to departmental requirements
(such as accounts, credit control or customer services).
The ESI security classification system should be simple to use and should be based on risk, need. priority and the degree of protect ion appropriate. Excessive classification levels should be avoided.
Where an ESI security classification system Is in use, the policy document should include with each information type the relevant classification level,
4.2.5 Storage media
Different types of media have different long-term storage characteristics. Most organizations will manage ESI on a variety of media types: electronic (hard disk drives, cloud storage, paper, microform, optical (write-once and rewrltablc/erasable) or hybrid types. In some applications, specific pieces of ESI can, throughout their retention period, be stored on different media types.
The organization should have policies regarding the use of specific types of media for different information storage requirements (e.g. acces-s requirements, retention periods and security requirements). These policies should be detailed in the policy document.
The media type on which each information type (see i2) can he stored should be specified.
Where copies of ESI exist, It might be Important to be able to demonstrate that no changes have occurred to any purported copy. In the case of ESI that exist in different versions, for the purposes of this document, each version should be treated as a new source or original ESI.
The policy for the management of copies of ESI should be detailed in the policy document.
4.2.6 Data File formats and compression
The policy document should contain details of the approved data rile formats that can be used for each information type.
All ESI managed by information management systems require software for retrieval and display. This software is subject to change, either by the implementation of new releases or by changes to operating systems and/or hardware. By implementing a policy of approved data file formats and compression technologies (where utilized), the necessary data migration or alternative procedures can be implemented satisfactorily to ensure long-term retrieval of the ESI.
Where compression techniques are employed, policy on their use should be documented.
Where multiple versions of ESI can exist, a policy is required which ensures that all relevant versions are managed and their relationship maintained. The policy document should contain details of policy on the management of versions of ESI.
For additional Information on this, see 5..2. 2J. and lLZ3.
The policy document should contain guidelines on the use of outsourcing processes that can be used for each Information type. The policy should Include the use of specific contract clauses where this Is appropriate tin particular. where information about Individuals (personal data, P11) Is lnvolvedJ; this can be achieved by the use of standard contract clauses or the use of a draft contract. It may also be appropriate for the policy document to require an appropriate service level agreement to be Included In the final contract with the outsource organization.
For additional information, see
4.2.8 Standards related to Information management
Where the organization operates a quality management system (such as the ISO 9000- series) whose scope includes part or all of the trusted system, all relevant procedural documentation should be included in the quality management system.
Where national or international regulatory requirements are mandatory, or where national or International Standards are applicable, they should be listed and complied with.
4.2.9 Retention and disposal schedules
A retention schedule should be established for each information type.
Retention periods should be agreed by all relevant departments and personnel within the organization. Retention periods should be agreed upon after taking relevant advice to ensure that legal or regulatory issues, or both, are resolved.
All relevant system and procedural documentation that is produced should be covered by the retention schedule.
The retention schedule should include the organization’s policy for its periodic review.
The retention schedule should include the organization’s policy for the controlled destruction of ESI.
4.2.10 Infonnation management responsibilities
Individual or job function responsibilities for the policy document should be defined in the policy document. Individual or job function responsibilities for each Information type should be identified and Included in the policy document.
Individual or job function responsibilities should include the need to seek relevant advice when creating or updating the contents of the policy document.
4.2.11 Compliance with policy
Where it is important that compliance with the policy document can be demonstrated, the individual or ob function responsibilities for obtaining and maintaining such compliance should be identified and defined.
5 Duty of care
5.1.1 Trusted system
A trusted system Is one that ensures that all ESI managed by the system can be considered to be original
Information, or a true and accurate copy of the original information, regardless of the original format.
Trusted systems should include the following as a recommended minimum:
— the creation of at least one copy of the ESI on to a system that protects the ESI from modification, inappropriate additions or deletion throughout its approved lifecycle: this copy needs to be stored and maintained in a sale location that is separate and remote from other copies of the ESI;
— the utilization of hardware and storage media that protect the ESI from modification, Inappropriate additions or deletion throughout Its approved lifecycle (see also La);
— the ability to verify through independent audit processes of the software hardware and/or storage media methodology(ies) that the ESI can be rendered accurately throughout its approved lifecycle.
A trusted system utilizes a combination of organizational policies, operational procedures and appropriately installed and managed technologies as described in this document that will enable an organization to demonstrate trustworthiness and reliability.
It is essential that the organization be aware of the importance of designing and maintaining all aspects of the trusted system and that it execute its responsibilities under the duty of care principle.
To fulfil this objective, the organization needs to:
— establish a chain of accountability and assign responsibility for activities involving management of ESI at all levels:
— be aware of legislative and regulatory bodies pertinent to Its business:
— keep abreast of technical, procedural, regulatory and legislative developments by maintaining contact with the appropriate bodies and organizations;
— implement an information security policy.
5.1.3 Segregation of roles
The segregation of roles is a fundamental aspect of duty of care. It provides a check on errors and on the deliberate falsification of ESI (in this respect, separation of roles is particularly important in systems where there is risk of fraud or other malicious action).
There are several aspects of information management where a segregation of roles is considered:
— Input reconciliation (see A.a);
— quality control (see);
— data entry (see .Z);
— information deletion (see IJ.2);
— Information security (seei2).
It is also important to ensure that the physical and managerial segregations that exist around a trusted system are mirrored by the logical access controls within it.
The segregation of roles between initial operations and checking should be reviewed and implemented where appropriate.
5.2 Information security management
5.2.1 Information security policy
All ESI, irrespective of the media Ofl which It is stored, is vulnerable to loss or change, whether accidental or malicious. To protect ESI, security measures need to be developed and Implemented to reduce the risk of a successful challenge to its trustworthiness. These security measures need to be aligned to any ESI classification categories that are used.
Traditionally, information security is often considered a matter of confidentiality, to ensure that information is not accessible outside the requirements of the organization. However, while this is important (in some cases vital) to the operation of the organization, it is not the most important security issue relevant to this document. Trustworthiness relates to the ESI’s characteristics of authenticity, integrity and availability.
A key objective of the information security policy Is to ensure the protection of the trustworthiness of ESI. When developing security measures, It is necessary to compare the risk of trustworthiness being compromised or challenged with the cost of implementation of such measures, Security measures need to include backup and other copies of ESI. as their trustworthiness is of importance in circumstances where they have been used as replacements for live ESI.
Also of importance is availability (which includes the ability to read, search and retrieve information).
In some cases, it might be necessary to be able to demonstrate that all information on a specific topic
Is available for review at any time. In this category, topics such as indexing accuracy and business
continuity planning are Important.
Security is not singularly a concern of information management systems. Security and availability of the operating environment (including buildings, temperature controls, network links, etc.) and the auditable implementation of procedures by all staff are both key elements.
The organization should adopt an information security policy, covering all elements ofthe trusted system. Where the organization has an Information security policy for other systems, then the use of the trusted system should be incorporated within its scope.
The information security policy document should contain, as a minimum, the following:
— statement of management objectives in respect of security;
— sped [Ic policy statements;
— requirements for different ESI classification categories;
— definition and allocation of information security responsibilities:
— policy for dealing with breaches of security;
— policy regarding compliance with relevant legislation, regulation and/or contractual requirements;
— policy regarding compliance with relevant standards,
The information security policy document should be approved by the organization’s senior management. That approval should be documented.
The organization should agree and document appropriate levels of security for managing Its F.Sl. In compliance with Its information security policy documenL
Consideration should be given to compliance with ISO/IEC 27001. With reference to the trusted system, the requirements of this document should be taken into consideration when developing the required controls for compliance with ISO/IEC 27001.
5.2.2 Risk assessment
Security measures are often developed using an ad hoc approach, reacting to security incidents or to available software tools. Such procedures frequently leave gaps in security, which are only filled at some later date. A more structured approach is to review the information assets of the organization and assign risk factors (based on asset value, system vulnerability and likelihood of attack), An information security policy can then be produced and approved, against which security measures can be audited.
The organization should undertake an information security risk analysis and document the results obtained.
Of’ particular importance are the security measures implemented to control the information storage media, both the live media and the backup media. The risk analysis needs to include vulnerability risk factors consistent with the type of media being used (e.g. WORM or rewritable).
The impact on the risk analysis results should be reviewed in relation to all the different types of storage media in use.
Once the risk analysis has heim completed, It needs to be acted upon as part of a review of Implemented security measures. Factors such as the balance between the costs of Implementation, securIty achieved and risk evaluation need to be taken into consideration during the review process.
Based on the results of the risk analysis, existing security measures should be reviewed for effectiveness.
Where the review indicates that changes to security procedures are appropriate, the changes should be implemented.
For further Information, see ISO/TR 18128 and ISO 31000.
5.2.3 Information security framework
A management framework should be established to initiate and control the implementation of Information security within the organization. The framework should have as its objectives:
— approval and review of the information security policy;
— monitoring of threats to information security;
— monitoring and review of security breaches;
— approval of major initiatives to enhance information security.
5.3 Business continuity planning
From time to time, problems arise with trusted systems which require emergency procedures to be implemented to recover from the problem. Such procedures might involve the temporary use of additional or third-party resources. In order to ensure that the trustworthiness of ESI is not compromised during these operations, an agreed and approved business continuity plan (sometimes known as a disaster recovery plan) should be Implemented.
Procedures to be used in cases of major equipment, environmental or personnel failure should be developed, tested and maintained. Such procedures should ensure that the trustworthiness of ESI is not compromised during their implementation.
For further information, see ISO 22301 and ISO 22313.
The implications of using trusted systems can be significant to other organizations, such as:
— regulatory bodies;
— government bodies;
— external audit bodies;
— legal advisors (such as the organization’s lawyers).
The organization should consult with relevant organizations that are concerned with the trustworthiness of ESI prior to implementing the information management policy document.
These can Include the following:
— national and international law;
— industry sector.
The organization should consult with relevant organizations prior to implementing the information management policy document.
These consultations can include the following topics:
— legal issues;
— government regulations;
— financial regulations (such as payment of taxes);
— special regulations (applicable to particular sectors).
The results of al I consultations, including actions agreed, planned or Implemented, should be referenced or included in the policy document.
Where appropriate regulations and/or laws exist, they should be complied with
The policy document should state whether all or part of any relevant national or International Standards should be complied with.
Where the organization complies with relevant national or International Standards, such compliance should Include the trusted system.
6 Procedures and processes
This clause deals with procedures relating to the operation of a trusted system
6.2 Procedures manual
The organization should maintain a procedures manual for each trusted system. Where, in this subclause, documentation is required, this documentation can either be included in the procedures manual or referenced by it. This manual may include references to other controlled documentation as appropriate.
The relevant procedures detailed In, or referenced by, the procedures manual should be readily accessible to all appropriate users of the system.
The procedures manual should include or reference procedures for the operation of the trusted system and should include the following:
— ESI capture (see .i);
— document image capture (seeA);
— data capture (see 5);
— authenticated output procedures (see );
— file transmission (see .2);
— information retention (see .1j1);
— Information preservation (see fl);
— information destruction (see J.Z);
— backup and system recovery (see J.);
— system maintenance (see ta.1&);
— security and protection (see J.);
— use of contracted services tsee
— work flow (see 12j;
— date and time stamps (see J.);
— version control (see j.);
— maintenance of documentation (see Z1J.
For convenience, the procedures manual can be maintained as a numberof separate physical documents, relating to different Information management areas.
Where the organization has multiple trusted systems, the documentation can comprise a single procedures manual or multiple procedures manuals.
6.2.3 Compliance with procedures
In order to be able to comply with the procedures detailed In the procedures manual, stalT members need to be aware of them and have the ability to follow them. This situation Is frequently achieved by training, either by specific courses or during day-to-day working.
Procedures should be implemented that ensure that all staff members that operate the system adhere to requirements.
6.2.4 UpdatIng and reviews
It is important to ensure that the procedures implemented at any time during the storage life of any specific piece of ESI can be determined. This is achieved by ensuring that the procedures manual is kept up to date and that all previous versions are kept in compliance with the policy document.
Any changes to operational procedures should be documented. This documentation should include details olany change control procedures used and procedures to ensure that the new procedures are Implemented.
Where changes are being implemented, they should be checked to ensure that operational requirements and the requirements of the policy document are not compromised.
Superseded versions of the procedures manual should be kept in compliance with the policy document (which includes compliance with the retention schedule).
To confirm that documentation Is up to date, regular reviews are necessary. Such reviews might also be necessary where legal or regulatory changes are relevant.
A review should be carried out at least annually to ensure that any changes to procedures or technology are reflected in the procedures manual.
The results of periodic reviews should be documented and approved by the person responsible for the operation of the appropriate part of the system.
6.3 £51 capture
Where a trusted system is used for managing ESI. the procedures involved in the capture of the ESI should be documented.
6.3.2 Creation and importing
ESI can be created within a trusted system, or Imported Into it. The trustworthiness of the ESI at the time that it Is created or Imported Is of crltcal Importance, as the trusted system will consistently reproduce whatever ESI has been managed.
ESI is typically stored as either images or data. In either form. ESI can be imported into the trusted system in a variety of formats.
Image formats are typically obtained from:
— images such as that captured by cameras;
— automatic facsimile entry (through a lax server);
— capturing screen shots where multiple pieces of information are being displayed simultaneously (also referred to as compound transient documents).
Image formats are typically bit maps of an original analogue document. Details of procedures for capturing analogue documents In image formal are discussed In ,4.
Data formats store Information in native” format, maybe requiring the original software to retrieve the information contained. There are a number of standard” formats that can be retrieved by many software packages (e.g. text files, comma.separated delimited files). Examples of data formats are:
— office systems such as word processors, spreadsheets, etc.;
— database systems;
— CAD drawings;
— e-mail messages;
— electronic data interchange (EDI) files;
— Instant messages;
— XML messages.
In all cases, the information contained can be accessed through the use of an appropriate software application. Details of procedures for capturing analogue documents in data format are discussed in 5.,
NOTE It is also possbie to have ESI in mixed image and data formats (for example, a letter in Word format with an embedded bit•rnapped signature),
Where ESI to be managed by a trusted system originates from outside the boundaries of control of the organization employing the trusted system, there might be little or no control over, or knowledge of. the procedures or processes involved in the production or authorization of that F.SI. In these circumstances, the organization will need to take care that the ESI Is what It purports to he, that It has not been tampered with and that the Identity of the originator Is genuine. The level of checking of these criteria will depend upon the nature of the particular ESI In question.
Such boundary situations can also exist within an organization. In these circumstances, the part of the organization with the trusted system should not assume that ESI is what it purports to be, simply because it came from another part of the same organization.
6.3.3 Information loss
Where ESI is stored in a trusted system, potentially, there is the possibility of loss of some of the information. For example, when ESI is converted from one format to another, some metadata might be lost.
Where ESI contains macros or other set of instructions that might affect its information content, care needs to be taken to ensure that all the appropriate information is captured.
Where storage media is changed, physical evidence (such as fingerprints on CD media) might not be reproduced within the ESI. In such cases, the organization should review any potential loss of information and make a decision as to whether this loss Is acceptable to the business process. If such a loss Is unacceptable, steps should be taken to ensure that all thc required Information Is captured and/or retained.
When ESI is created or Imported, care should be taken to ensure that all the relevant rnetadata are also transferred. Care should be taken to ensure that all necessary metadata are captured, to ensure that the ESI has the correct interpretation placed on It.
The content of metadata might need to be reviewed for completeness and appropriateness. The availability of a full metadata set, with an appropriate content, will increase the evidential value of the ESI to which it pertains. The use of an appropriate metadata schema should be considered
6.4 Document image capture
This subclause includes recommendations relating to the procedures relevant to the creation of electronic images from analogue documents. Recommendations in this subclause are for users whose trusted systems include the capture and storage of analogue documents in an electronic form by the use of scanners or cameras. These recommendations cover procedures for:
— preparation of documents;
— document batching;
— image processing.
See also ISO/TR 13028.
6.4.2 Preparation of paper documents
All paper documents need to be examined prior to the scanning process. to ensure that a successful image is obtained. Attributes such as paper size, weight and binding, paper and print colour can all affect the physical scanning process.
Paper documents should be examined prior to the scanning process to ensure their suitability for scanning, Procedures for this examination process should be documented.
Factors such as their physical state (thin paper, creased, stapled, etc.) and the attributes of the Information (btack-and.whlte, colour, tonal range, etc.) should be considered.
Where paper documents are found that are unlikely to be accepted by the scanner, there are a number of techniques that can be used. For example, the original could be photocopied or transparent wallets could be used.
Procedures to be followed for paper documents that can cause scanning difficulties should be documented. When removing staples, clips or other paper document bindings, ensure that flO damage is caused to the original that can affect the capture of the Information From the document.
Where a paper document has physical attachments, for example, stick-on notes, the system should provide facilities for distinguishing these from the document to which they are attached.
This might be achieved, for example, by capturing a separate image of the attachment, with appropriate data to associate it with the source page. lIonly a single image is captured with the attachment in place, the data might record the fact that there is an attachment. Where there is a risk that an attachment might obscure, or be considered too obscure, Information on the paper document, It might be preferable to ensure that an image of the paper document without the attachment is captured.
Where a paper document has physical amendments, for example, white opaque paint, the system should ensure that the presence of such amendments is noted.
Procedures to be followed when scanning multi-page paper documents bound together with staples or clips should be documented.
All pages of multl•page paper documents should be kept together and in the appropriate order before, during and after scanning.
6.4.3 Document batching
Wherever appropriate, paper documents should he grouped Into batches for scanning.
This makes It easier to control the paper documents and to be able to perform quality control and other procedures on a sampling basis.
The definition of batch size should be decided on the basis of convenience.
The number of paper documents in a batch will be application-dependent. For example, if the documents are in file covers and the average number of documents per file cover Is relatively large, for example, 100 pages. then the documents In a single file cover can constitute a batch. If the file covers contain relatively few documents, for example, on average 10 pages, then a batch can consist of documents from more than one file cover. If the documents are on roll microfilm, the film roll can be a batch.
Choose the batch size so that it is not bigger than can be easily managed, nor so small that checking quality by sampling on a batch basis would result in significant process inefficiencies. Sample size might need to be determined using statistical sampling techniques.
For some applications, a hatch cannot be easily defined. In these cases, a batch can he defined as those paper documents input during a specified time period. Thus, for example, a batch could be all documents Input during an hour or a day.
For some applications (especially where workf low is implemented) where batching cannot be applied. alternative methods for ensuring that all paper documents are scanned should be established. Such techniques can include the marking of documents after scanning or additional checking of images against the paper originals.
It might be helpful for some paper documents to be photocopied prior to being scanned. Such documents include the following:
— documents that can be adversely affected by the scanning process, such as damaged or delicate documents;
— documents where there are substantial contrast or density variations over the area olthe original and where photocopying demonstrably improves the image quality;
— documents containing paper or ink colours that do not produce legible scanned images:
NOTE I Photocopiers and scanners might respond differently to different colours and it is only in
exceptional cases that the technique of photocopying prior to scanning does not produce satisfactory results.
— folded documents that are too large to be scanned as a single full-sized image.
NOTE 2 Photo reductions can be made which are then scanned and/or multiple scanned images can be captured from the original or from photocopies thereof.
Photocopies should be examined to ensure that there is no significant loss of information during this process.
Where paper document-s are photocopied prior to the scanning process, the procedures used should be documented In the procedures manual.
Additional quality control procedures should be adopted to ensure that no significant information Is lost in the scanning of photocopied paper documents.
11 photo reductions are made, checks should be made to ensure that there is no significant loss of detail in the scanned images compared to the paper original caused by the effective resolution of the image (compared to the original) being reduced.
If multiple Images are captured, these should be overlapped to ensure that there Is no significant loss of information at the edges between adoinlng Images.
Where an image was made Front a photocopy, it should be clear to a user of the image that this was the case. It should also be clear whether the photocopy was made from the paper document during document preparation or whether the paper document was known to be a photocopy. This is to ensure that an image can be correctly identified as a true facsimile of a paper document, even han intermediate photocopy has been taken as part of the preparation procedures and to distinguish such images from images of photocopies made under unknown conditions.
This can be done. for example, during document preparation, by stamping or marking the document as a photocopy or original photocopy or by electronically marking the Image as having been captured from a photocopy, distinguishing between photocopies made during document preparation and paper documents which are known photocopies.
Procedures to be used where it is not known whether a paper document is an original or a photocopy should be documented.
6.4.5 ScannIng processes
Details of procedures used in analogue document scanning should be included in the prDcedures manual.
Any variations in scanning procedures due to the type of document being scanned should be detailed in the procedures manual.
Such changes might apply to, for examples double.sided versus slngle•sided paper documents and colour versus black’andwhite images.
Procedures should ensure that all paper documents in a batch are fully scanned: no document should be left unscanned.
To check that all paper documents have been scanned, the count of captured documents can be compared with the number of documents in a batch. Where batching Is not used, alternative procedures for ensuring that all documents are scanned might be needed.
Where it is important that all pages in a rnulti.page paper document are scanned, procedures which ensure this should be implemented.
The count of captured images per paper document can be compared with the number of pages (i.e. sides) in each document, taking into consideration any blank page (or other) removal processes. However, errors in manually counting physical paper documents and the pages therein might make such a process Ineffectual. It might he satisfactory to Implement procedures whereby the probability and risk of any document not being scanned Is acceptably small. This risk should he evaluated and, where necessary, procedures should be reviewed against this risk.
Many scanners have automatic paper document feeders that can reliably detect bad feeds, therefore, minimizing the risk that a document might pass through the scanner without being scanned, If such devices are not used, the procedures are required to ensure that the scanner operator has to manually handle every document in order to reduce the probability that any document might not be scanned.
Where it is crucial to ensure that every sheet is scanned, users should consider counting or pre-indexing the paper documents In order to capture accurately the number of pages per document or batch of documents.
Using a double-entry technique can provide extremely high accuracy in the number of pages. These data can subsequently be compared with the scanned page count; any shortfall will indicate either that more than one page has been fed at once or that a page has been misplaced between pre-indexing and scanning.
If a simplex scanner (I.e. one that scans only one side of a paper document at a time) is used to scan double- sided documents, care should be taken to ensure that every double-sided document Is reversed and the other side scanned.
It a large paper document is scanned in sections. so that multiple images are captured, these sections should be overlapped to ensure there is no loss of information at the edges between adjoining images.
The scanning system should enable each electronic document to be uniquely identified, in such a way that its identity cannot be changed or removed, except as permitted as described in 2.11.
This unique identity could be a system-generated sequence number that can be used for internal control purposes only.
6.4.6 Quality control
220.127.116.11 Sample set
Procedures are required which reduce the risk of scanned images being of unsatisfactory quality. It will be easier to demonstrate trustworthiness if it can be shown that the images are of good quality and that the scanner was working to agreed standards at the time of scanning.
A sample set of paper documents should be assembled for the purposes of evaluating scanner results against agreed quality control criteria. Documents in the sample set should he representative of the complete set of documents that are to be scanned. Documents In the sample set should Include examples of paper documents whose quality Is poor relative to those of the maorlty of the documents.
Quality control criteria can cover:
— overall legibility:
— smallest detail legibly captured (e.g. smallest type size for text; clarity of punctuation marks. including decimal points);
— completeness of detail (e.g. acceptability of broken characters. missing segments of lines);
— dimensional accuracy compared with the original;
— scanner-generated speckle (i.e. speckle not present on the original):
— completeness of overall Image area (I.e. missing Inlormatlon at the edges of the Image area);
— density of solid black areas;
— colour fidelity.
Quality control criteria for Image quality should be realistic given the nature of the source material and the characteristics of the scanning equipment.
Quality control criteria should be documented for scanned image quality. The criteria should be agreed by all parties, whose use of images is likely to be affected by image quality, including internal and external users.
Quality control criteria should be based upon the sample set of paper documents.
18.104.22.168 EvaluatIng Image quality
Procedures that specify the process used for evaluating image quality on a day-to-day basis should be documented.
Image quality evaluation procedures should include details of the evaluation of results, including the characteristics of the Image retrieval device.
Care should be taken when evaluating the results of a quality control procedure. Results obtained can depend upon the specific output device (e.g. monitor or printer).
If a printer is to be used for quality control procedures, the printer resolution should be equal to or greater than the resolution of the scanned images.
The printer should be capable of accurate reproduction of grey scale or colour In applications where this is relevant.
Where greyscale or colour reproduction is relevant, the accuracy ut rendition of grey scale or colour should be evaluated.
Where dimensional accuracy is important, procedures should be documented for checking that dimensional information is reproduced within tolerance. This might involve, for example, checking that the nominal resolution of the scanner Is accurate, so that the dimensions in the electronic image can be determined by counting the number of pixels between specific points In the image.
If the scanner operator checks the quality of images during the scanning procedures, a second quality control procedure should be undertaken by personnel other than those responsible for the scanning. This second quality check might involve statistical sampling techniques.
Quality control procedures should be related to the batch process (if used) as defined in enabling acceptance or rejection of such a batch independently of any other batch.
The results of all quality control checks should be stored in the quality control log (which can be created manually or automatically).
In workf low environments where every electronic document is viewed within a workflow process and activities explicitly check images for quality and reject unacceptable ones, then these activities might be deemed to be a quality contr& process.
Where the quality control procedures involve sampling of the scanned Images and any related data (such as notes), the proportion sampled need not be fixed but can vary from time to time depending on the frequency of problems encountered or the nature of the source material. Where appropriate, statistical sampling techniques should be used to determine the percentage of scanned Images to be checked. For further details of sampling techniques, see ISO 2859-1.
It will not normally be practicable to check all processed material and generally only a proportion of the material processed will be checked. For example, at the start of scanning, initially a relatively large sample can be selected (e.g. 20 %), which can be reduced (e.g. to 10 % or even 5 %) as the consistency of meeting the required quality standards can be demonstrated.
Where quality control consists of sampling scanned Images, the frequency of sampling should be documented.
22.214.171.124 Checking scanner performance
Scanner performance checks should be used periodically to monitor the system. to check that It is within agreed tolerances.
Hard copy prints can be made ot the scanned Images of the test targets and compared with the test targets themselves to determine whether the quality criteria are met, as described in the procedures.
Test targets allow objective assessment and measurement of scanner performance. Regular use can show whether the scanner is performing consistently and in accordance with its specification. The test target given in ISO 12653-3 can he used for this assessment.
The frequency olscanner performance checks should be dependent upon system usage and related to expected deterioration In system performance. This might require recommendations From the system supplier and also experience in the use of the system. Initially, it might be appropriate to scan a test target for every few thousand pages scanned.
If double-sided (duplex) scanners are used, double-sided test targets should preferably be used. Single- sided test targets should only be used with duplex scanners if double-sided test targets cannot be obtained.
Test targets are not representative of the paper documents actually being scanned and are not to be regarded as a substitute for the sample set of documents.
Procedures for rescanning paper documents should be documented. Such rescanning might be required han original imagu has been re)ected. owing to poor quality or other factors.
Procedures should be implemented to ensure that images resulting from rescanning replace the original image and that batch numbering and audit trail procedures are not compromised.
6.4.8 Image processing
Image processing techniques used to improve the quality of an Image should be described in the procedures manual.
Where operator-controlled facilities are available for use, details of which facilities are used for a particular digital document should be documented.
6.5 Data capture
6.5.1 Data creation
Where external data is created and stored on the trusted system, required quality levels should be specified. These quality levels should cover accuracy and completeness of captured data.
Data (for example, for the creation of index or other reference information) can also be captured from existing analogue and/or ESI and entered Into a computer In a number of ways, Including manually (I.e. direct keyboard entry), automated (e.g. bar code reading, optical mark reading (OMR), optical character recognition (OCR), inteLligent character recognition (ICR)J, or semi-automated (for example, where data captured automatically, e.g. by OCR. Is confirmed by manual re-entry). In each case, the issue is to convey confidence that the correct data have been captured. In practice, it can be difficult, if not impossible, to ensure 100 % accuracy in captured data and the user has to assess the risk associated with the existence of errors.
The specified accuracy levels can vary depending on the application and the importance of each particular data Item.
Procedures should be defined for checking that the accuracy levels are maintained. These procedures will typically be based on random or quasi-random sampling of batches of captured data, with comparison against the source material. Batches that fail to meet the required accuracy levels will generally be reprocessed and the results checked again to ensure that the required accuracy levels are maintained.
Records should be kept of the results of all accuracy checking.
Where data is extracted from ESI. the ESI should be stored and associated with the extracted data.
6.5.2 Conversion and migration
Where data Is being received from another system (or part of a system), for example, as part of a storage system migration process. then procedures and processes need to be established, implemented and documented for this process.
Where ESI is converted from the current to a new file format, any potential loss of information (including audit trail information) due to this process should be documented.
6.6 Database consIderations
Application systems and information are the transactional lifeb]ood of most organizations. This information is typically managed in databases and is at the centre of the application systems that operationally power the organization on a day-to-day basis. The range of these systems managing Information in databases is wide and includes, amongst others, enterprise resource planning (ERP). finance and accounting, human resources, customer relationship management (CRM), etc.
In order for structured information held in databases to be relied upon in the event of disputes, there are many similarities with the trustworthiness aspects of unstructured information, The policy, duty of care, processes and procedures, enabling technology and audit of the trusted system are equally important.
Where information stored in databases is within the scope of the trusted system, the policies, processes, procedures, enabling technology and audit should each specifically reference this information.
In spite of many similarities, there are a number of areas that need to be considered specifically as they are not directly analogous to the trustworthiness issues of unstructured, document-centric, information,
6.6.2 Database systems
126.96.36.199 Extract, transform and load
Extract, transform and load (ETL) refers to a process in database Lisage, and especially in data warehousing that involves extracting data from outside sources and transforming it to fit operational needs, which can result in significant changes to the information.
Any such change should be able to be explained and ustl1led.
It is important to note that ETL. processes can Involve considerable complexity and significant operational problems can occur with improperly designed ETL systems. Where ETL has been deployed, all processes should be fully documented, as the source and target databases may have, as a consequence of the ETL process, what appears to be the same information that is not the same in the different databases involved.
Where ETL techniques are employed for information stored in structured databases within the scope of the trusted system then:
— changes or loss of information caused by extraction, translation or load should be evaluated and accepted by the organization;
— processes and acceptance criteria should be documented;
— test plans, scripts and results should be retained;
— where audit trails of ETL operations are generated, these should be retained for as long as the information itself.
A common approach to four basic functions implemented for information in databases is covered by the term CRUD; this acronym expands to:
There is commonality of the issues surrounding creation, reading and destruction between unstructured and structured Information. However, updating Is significantly different for structured Information In databases from unstructured information.
When unstructured information is updated, a new version is created (see on version control). In databases, the update will change the contents of a particular piece of data in the database.
The transaction that resulted in the update to a particular field in situ may or may not be retained. This is an area that should be considered and the results of that consideration documented. If the updating transaction and the content before the update are not retained, then It may be necessary that the be1ore and after” contents of the field are able to be re-created In the event of a challenge to trustworthiness. This could be within the audit trail.
The audit trail and/or the definition of the process/procedure should indicate who or what was responsible for the creation, updating, reading or deletion of information in the database. It is worth noting that this responsibility could be a person, a device or an application component/service.
ACID (atomicity. consistency, isolauoii, durability) are properties that ensure database transactions are processed reliably. 1’pically, relational database management systems achieve these automatically but it should be noted that a number of NOSQL. databases that have been introduced to meet the demands of big data do not include ACID transaction support.
A database system that does not include ACID transaction support might not he updated with every transaction posted to It. This may not he a problem for an organization using such a system.
If the database is not designed based on ACID, then the reliability and trustworthiness olthe information content in the database may be questionable.
If the database system deployed is not based on ACID, then the organization should evaluate the impact and formally record evaluations and decisions. It should be noted that suitable application design may meet the ACID transaction support criteria even ifthe database system does not.
6.6.3 Database scheinas
For a database, the schema defines the tables, fields and relationships of the database itself. This gives context to the data held In these tables and fields enabling It to be Information.
A field In a database may contain a number which could be a quantity of an item, a telephone number or a product code, The schema should describe which of these (or others) number actually means. In this respect, the schema can be regarded as metadata that gives context to the field enabling it to be regarded as information rather than simply data.
Sometimes organizations will use a field for a different purpose to that intended and this can be a cause of confusion if not properly considered and documented. In this event, the contents of a field and the schema expectation may be completely different. Such usage Is often because the organization does not wish to undertake a costly bespoke modification to a packaged application system. This type of field misuse should be avoided; if It Is employed, It shouLd be fully considered, approved and documented.
Another area of concern, especially with packaged application systems, is bespoke extension of the standardized schemas. This will frequently generate customized tables and fields with organization- specific relationships to the standard application system. All such custom schema and application components should be properly considered, justified and documented. This type of customization is frequently the cause of considerable cost and difficulty when the standard application is upgraded to a newer version and can result in compromise to the trustworthiness of the information within the database.
Special care needs to be taken when any schema is modified that the changes are justified and documented and that data migration during the change process is properly tested and results recorded.
When a schema is changed, it is quite common for additional checks to the contents of fields to be applied. However, in practice, the effort to retrospectively apply these additional checks to historic data can lead to a situation where the migrated data is not validated against the new rules but migrated “as ls when the new schema version is Introduced. This can lead to situations where old data is in a different format or does not match the validation rules of newer data In the same fields. Such situations need to be able to be explained satisfactorily In the event of a challenge to information trustworthiness.
When a database schema is changed, there are many aspects that should be addressed in order that the schema change is not the cause of unintended compromise to the trustworthiness of database content.
Access to previous schema versions maybe required so that, for example, if a database record or field
Is used as evidence, the database schemas that were In force at the time of its capture and since that
time can he described and attested to. If this Is not done, there is a risk that the trustworthiness of the
Information might be successfully challenged.
6.6.4 Master data management
A challenge facing many organizations is master data management (M DM). M DM aspires to ensure there is a “single version of the truth” across the systems used by an organization as opposed to multiple, inconsistent versions of the same thing held in separate systems.
MDM aims to avoid the need for separate updating of systems by keeping a single master that Is used by the different systems and is, as a result, consistent.
Where MUM is deployed, the responsibilities for the master need to be clearly documented.
Where MUM is not, or only partially, deployed, the different versions of the same information should be understood and documented so that a challenge attempting to discredit on the basis of differences between what appears to be the same Information can be rebutted.
6.6.5 Transactional vs. updating
There might be a need to be able to show, historically, what the contents of a database were at a specific point In time. In many systems utilizing a database system, there are requirements to he able to show what the information contents of a field were before and after an update or deletion, to avoid or resolve a dispute, while In other situations, this requirement may be superfluous.
The organization should evaluate and record decisions taken in this regard.
When the before and after update information is needed, then this may be achieved by either retaining the before and after update content or by retaining the transaction and being able to deduce the database state preceding the update (this latter procedure may not be feasible for particular updates.
Taking this to the next logical stage, there may be circumstances in which it Is necessary to be able to show what the information state of the whole database was at a particular point in time, rather than simply the contents of a particular field or table. This Is most likeiy to be in situations where information from the database is routinely required to be used as evidence.
Indexing is a vital part of the process of managing ESI on a trusted system, as it allows access to the relevant ESI. Where indexing information is lost, then the ES1 might also be lost.
Indexing can be either automatic (i.e. performed by the system without operator intervention), or manual. If manual indexing Is performed, It Is Important to ensure that the documented procedures he followed.
Some systems allow partial index information to be stored when the ESI is captured. This can then be combined with additional manual index entries at a later time.
Procedures and rules for indexing ESI should be documented.
6.7.2 Manual indexing
Manual indexing involves the visual examination of ESI captured by the trusted system, either during its capture or as part of post-capture processes,
Staff involved in manual indexing should receive specialist training in order to maximize accuracy. Indexing training requirements and procedures should be documented.
6.7.3 Autoniatlc Indexing
Automatic indexing can be achieved by, for example, the reading of bar codes or specified data fields, or the use of OCR/ICR techniques. Where automatic indexing is used, procedures to check and amend inaccurate index data should be documented.
6.7.4 Index storage
Index data should be retained for at least as long as the ESI to which it relates is retained.
Some systems require database indexes to be rebuilt penodically, typically to improve database performance. Procedures for rebuilding indexes should be documented.
6.7.5 Index amendments
Indexing processes can include procedures for the detection of missing ESI. Indexing from displayed ESI may not detect missing material unless the displayed ESI is checked against the original ESI or there Is a defined sequence of ESI (for example, by sequential page numberIng).
Procedures for the amendment and/or correction o’ indexing data should be documented. If an index entry is amended, details of index content before and after the change might need to be retained.
Where an index entry relates to deleted or expunged ESI, this status should be stored.
Where, by the amendment or deletion of index entries, deletion or expungement oIESI might be required
to comply with legal or regulatory requirements, procedures to be followed should be documented.
6.7.6 Index accuracy
Index data can be inaccurate. While accurate indexing will facilitate the retrieval of ESI, the trustworthiness of that F.SI may be demonstrated if its relevance and completeness can be indicated from the accuracy of the relevant Index data. Conversely, Inaccurate Index data can result In the user being unable to retrieve relevant ESI. or retrieving Irrelevant ESI.
Index data accuracy criteria can vary depending upon the application. In some cases, the accuracy can be defined as the maximum acceptable number of characters in error per thousand characters captured (or percentage equivalent). In other cases, the accuracy can be defined as the maximum acceptable number of words (or similar cluster of characters. for example, a customer or part number) containing any error (whether of one or more characters)
Criteria for Index data accuracy levels should be realistic, given the method used for Index data capture, the typical random error rates achieved by data entry personnel and the legibility of the source material. These accuracy levels can vary depending upon the type of ESI being indexed.
Where manual or automatic indexing is undertaken, accuracy levels should be agreed and documented. Procedures for index data accuracy checking should be documented.
6.8 Authenticated output procedures
Output from mformation management systems, either in the form of paper copies or as ESI on appropriate storage media, might need to be produced for use as evidence. Generally, these copies need to be confirmed as true copies of any related original, in accordance with local requirements, in order to reduce the likelihood of rejection or challenge.
Procedures for the creation of copies of ESI that might be required as evidence should be documented. Such procedures might, for example, require the use of standard system features for copying and written confirmation by an authorized person that the copying process has been conducted correctly. The procedures might specify how such copies are subsequently to he handled. The procedures might refer to audit trail data as a confirmation of the processes that occurred during copying.
Where a paper document is produced as part of the output, the procedures should include the use of an authorized signature or other procedure to confirm the trustworthiness of the copy document.
It is important that the nature and extent of any changes introduced by the retrieval facilities be understood and their relevance assessed. What is acceptable in normal usage might be unacceptable in other circumstances requiring output for use as evidence. For example:
— rendering a coloured Image in rnonochi’ome might be acceptable in situations where the colour is irrelevant, but in other situations, the colour might be vital, necessitating a different retrieval facility;
— viewing an image at a lower resolution than that used in scanning the original paper document might be acceptable in routine retrievals, but the fine detail which is thereby lost might be important in other situations where, for example, it might have forensic significance:
— where there is not an exact match between the resolution of a scanned image and the retrieval device, the dimensional accuracy of the reproduction can be lost;
where a stored data file is normally converted to another format for display or printing, information can be lost or presented In a different form, caused by loss of detail or layout differences; these differences might be unacceptable for disclosure and In these cases different retrieval facilities might be required, which do not Involve conversion.
If the system facilities used to retrieve, display and/or print ESI do not maintain the layout of the original (e.g. font, pagination), information retrieval characteristics should be agreed upon and documented.
6.9 ESI transmission
6.9.1 Intra-system ESI transfer
Intra-system ESI transfers are those that take place within the system as defined in 2.2. lntra-system file transfers include:
— local area network transmissions (see 691.2)
— movement between storage sub-systems tinder system control, e.g. in a hierarchical storage management system, or between cache and magnetic disk:
— transfer between storage sub-systems under operator control.
In such transfers, the procedures, both electronic and manual, are under the control of the organization. Procedures and processes should be Implemented to ensure that the trustworthiness of ESI transferred within the system is not compromised.
ESI transfers from one device to another should be controlled by the appropriate transmission software.
Where additional security measures are required, the use of digital signatures should be considered.
NOTE This subclause is nut applicable to the requirement for tile migration, where the media type and/or format of the data file might change for technology migration reasons. For further Information, see 2J,fl.
188.8.131.52 Local area network transmission
In some applications, ESI can be transferred under operator control from one storage device to another using a local area network as defined in 2.2. Local area networks can include connections between remote locations using fixed lines.
Where ESI is transferred using a local area network, procedures and processes should be implemented to ensure that the trustworthiness of transferred ESI is not compromised.
Where ES! Is transferred between remote locations using a fixed (e.g. leased) communications line, procedures and processes should be implemented to ensure that the trustworthiness ol transferred ESI is not compromised.
6.9.2 External transmission of files
This subclause deals with ESI transmitted between one system and another through external, wide area, communication systems. Such systems are external to the system described in Clause 7. The sending and receiving systems are remote from each other and can be within the same or different organizations. In either case, another party provides the transmission service.
The communication system can involve real-time transmission or deferred (store and forward) transmission such as occurs in e-mail services.
This document is concerned with the trustworthiness of ESI that has been transmitted to another party and with the trustworthiness of ESI received from another party. This document is not directly concerned with the transmission service. By following the recommendations in this document, users can show that a copy of ESI which was transmitted at some previous time to another party has not been altered since that time and that ESI received at some previous time through a transmission from another party has not been altered since the time of receipt.
ESI transfers fron one device to another should be controlled by the appropriate transmission software.
Where ESI is copied to another party through a transmission, the original ESI should be retained within the original system for as long as is appropriate. The date and time of any ESI transmission should be stored as part of the audit trail.
Where F.SI is received from another party through a transmission, that ESI should be stored within the receiving trusted system. The date and time of any ESI receipt should he stored as part of the audit trail.
Differences between sent and received ESI might be caused by errors in transmission or by deliberate alteration of ESI. There might also be appropriate changes (typically additions) to the metadata of the transmitted ESI Demonstrating that received and sent ESI contain identical information is no different from demonstrating that any two copies are equivalent. The primary need is to show which ESI is the source and which ESI is the copy, i.e. which ESI existed first. In some instances, this requirement can be met by comparing the times at which the two ESI were stored. If system time clocks are accurate (and bearing in mind differences in time zones), received ESI should have been stored later than that at which the source ESI was transmitted. Thus, the issue becomes one of being able to demonstrate the reliability and accuracy of the timings of the two events.
Hashes, digital signatures, seals and time stamps, for example, can be used to permit confirmation that electronIcally/digitally signed ESI is exactly the same as was sent and to confirm the identity of the sender. This confirmation of identity might be compromised if the original certificate is no longer valid and maintained by the certifying authority. If the electronic/digital signature certificate is no longer available or expired, the electronic/digital signature will provide information related to whether the £51 has been modified since the time of signing only.
Additional procedures (outside the scope of this document) can be adopted for security or other reasons, e.g. to prevent unauthorized disclosure of the information contained within ESI.
Where it is important to be able to demonstrate that ESI has been delivered, the sender might require that the receiving system transmit back to the sender a confirmation of receipt, which should include the transmission identifier and the date and time of receipt.
lithese procedures are followed, then the risk is reduced that ESI has been modified or has been sent from someone other than the identified sender.
The level of security risk being taken during external £51 transfers should be assessed to ensure compliance with the requirements of the Information security policy.
6.10 Information retention
£51 will be required to be retained for legal and/or business purposes for an agreed amount of time (as documented in the retention policy). Procedures should be developed and documented for the retention of ESI until the end of Its retention period.
Procedures for the identification of ES! for which fraud has been identified, or for which litigation is envisaged or ongoing, should be documented. Such procedures should include the suspension of disposal policies for this £51.
Where paper documents are scanned and the information management policy document states that it is general policy to destroy a specific type of paper document, there can be some instances In which an exception applies and the paper document should be retained. It should be noted that.
where an original paper document is retained, access might be required in order to demonstrate the trustworthiness of the electronic copy” ESI.
Procedures that identify specific paper documents that need to be retained should be documented. Circumstances where this might be required include the following:
— the paper document is of poor quality, so that a legible Image cannot be obtained;
— the paper document can be kept to reduce the possibility of it being suggested that the image was deliberately made illegible; this also avoids any risk of rejection ofan image on the grounds that it is not a facsimile of the paper document:
— a note can be stored which states that the original paper document was of poor quality and includes details of any visible information that needs to be stored;
— a paper document contains physical amendments or annotations that cannot be Identified as such on the scanned image;
— a separate record that physical amendments or annotations were present on the paper document, plus details of what the physical amendments were, can be sufficient;
— fraud has been identified or litigation is envisaged or ongoing;
— the paper document is of high value, such as the signed original of a large contract.
6.11 Information preservation
Procedures for the long-term preservation of ESI should be documented. Such procedures should take Into account the required retention periods and the expected life of the trusted systems. Where the retention period exceeds the likely life of the trusted systems, plans for the migration to new systems should be documented (see also LJ.Q). For further Information, see ISOITR 18492.
6.12 Information destruction
Procedures for the destruction or disposal of ESI at the end of the retention period should be documented.
These procedures should Incorporate security precautions appropriate to the sensitivity of the ESI being destroyed.
In the case of capture of analogue documents as ESI, no original documents should be destroyed until the images have been successfully written to storage and appropriate backup procedures have been completed.
6.13 Backup and system recovery
Effective procedares for the backup of ESI should be Implemented, with at least two up-to•date copies being created [or use in the event ut loss or corruption of part or all of the live ESI. It is vital that backup ESI includes all associated information (such as index files, audit trails), so that a complete new system can be built in the event of a total loss of the original system.
The procedures should include the secure remote storage of these backups.
System recovery procedures also need to be documented to demonstrate that such procedures are controlled and tested fOr reliability.
Issues surrounding the security of backup InformatIon might be important in the event of a dispute over trustworthiness. It can be argued that backup media had been compromised and then used to recover from an information loss, thus, affecting the trustworthiness of ESI. In some cases the availability of backup ESI which has been in secure storage, to be used only in the event of a challenge to the trustworthiness of the live ESI. can he used to enable the demonstration of trustworthiness of the ESI.
Facilities on the system should allow (or the backup and verification of all ESI and associated information, including audit trails, at regular intervals.
There should be information kept in the system audit trail of all backup activity, which should include details of any problems incurred during the proc:edure.
If the file structure of the ESI held on a backup is different to that of the original, the structure of the backup ESI should be detailed in the systems descrIption manual.
The audit trail should detail all ESI recovery activities and include a description of any problems experienced during the recovery procedures.
Procedures for checking that ESI trustworthiness has not been compromised after a restore should be documented. Where backup F.SI Is used to recover from a system failure, procedures should be documented to ensure that ESI trustworthiness has not been compromised.
Media used for backups do not necessarily provide permanent storage conditions. Media suppliers usually provide information regarding recommended testing frequency. Alternatively, if such specific information is not available, general recommendations can often be found in national or International Standards.
Testing media on the same hardware each time is no guarantee that the media can be read on other devices, even from the same supplier and of the same model type. Rackups are of no value if the only hardware that can read them Is lost.
Backup media should be tested at regular intervals, using a variety of hardware to read the media.
6.14 System maintenance
The trusted system should be maintained and corrective maintenance carried out only by qualified personnel to ensure that its performance does not deteriorate to such an extent that the trustworthiness of the ESI managed by the trusted system is affected.
For example, it is of specific importance in a paper document scanning system that it be maintained in accordance with the manufacturer’s specifications, In order that image quality Is maintained.
Preventative maintenance should be carried out regularly. iii accordance with the supplier’s recommendations. Preventative maintenance may Involve the maintenance of the patching history of the trusted system.
Procedures used for preventative maintenance should be documented.
These procedures can be performed by system operators or by specialized service personnel. A maintenance log should be kept, stating the preventative and corrective maintenance procedures completed.
Procedures to control the use of system maintenance hardware and/or software that can bypass system access controls should be documented. Access to such tools and facilities should be strictly controlled and monitored.
Information regarding system downtime and details of action taken should be stored in the maintenance log.
6.14.2 Scanning systems
Where paper document scanning is implemented, procedures described under the quality control section should be used to check that a scanning system continues to produce the output quality required of the system after the maintenance procedures have been completed.
These test results will serve to confirm, at any later date, that any poor quality images were not due to malfunction of the system. If there is any deterioration in the output quality, appropriate corrective maintenance is necessary.
6.15 Security and protection
6.15.1 Security procedures
Security guidelines that are applicable to the organization and application concerned should be implemented. Such guidelines, for example, might exist in company policies or practice, sector-specific guidance (e.g. financial, medical), national or International Standards, or as legal requirements.
In the absence of Internal guidelines, published Information can provide comprehensive security guidelines that are designed to meet the organization’s needs. They might provide an adequate basis for the creation of guidelines that would meet the organization’s requirements. Some organizations might consider the adoption of externally accredited security schemes as additional confirmation of compliance with their security policy.
Procedures implemented in accordance with the organization’s information security policy should be documented.
To control access to the various levels of the system (e.g. manager, data input and retrieval), a secure access control system should be Implemented.
The accommodation and operating environment for trusted systems and for the storage, labelling, handling, transportation and maintenance of storage media should be in accordance with suppliers’ recommendations and/or relevant national or International Standards.
The central part of the system (including servers and storage devices) should be installed In secure areas (as defined In the organization’s security procedures), with documented restricted access.
6.15.2 Encryption keys
Encryption techniques can be used to protect the trustivorthiness of ESI. ESI can be encrypted so that the information it contains cannot be retrieved without the use of a decryption key. Encryption is a complex topic and one that is constantly changing. Readers should refer to authoritative publications on this topic for detailed information.
The use of encryption for long-term storage can be problematic, should the keys and/or certificates become unavailable for any reason.
Where encryption is used, keys should be kept securely and should not be available except to those authorized as responsible for activities requiring access to the keys.
Procedures should be implemented for encryption key allocation and management and for certificate management.
Where encryption is used and additional benefits can be obtained from third-party key management/recovery and key escrow services, their use should be considered,
The person who originally was responsible for managing the keys and certificates securely within the organization might no longer be employed, so procedures are required to ensure their continued availability.
6.16 Use olcontracted services
Specialist service providers are often used for, for example, paper document scanning, indexing, data conversion, storage and other services.
a) A contract should be agreed upon with the service provider that details the services that are to be used.
b) If the contract does not require that the contractor comply with all relevant recommendations of this document, the user’s inspection procedures on services provided should be such that no assumptions are made regarding the completeness, quality and accuracy of the services.
The procedures and recommendations in this subdause cover any type of service, including those provided on a facilities management basis and is intended to ensure:
— that where work Is carried out by a service provider, the procedures for the demonstration of trustworthiness of the resulting ESI will be the same as if the work had been done wholly within the client’s organization;
— that the client can demonstrate compliance, many years after the event, even if the service provider has ceased to trade.
Where work is undertaken off-site, details of the procedures used in the transfer of information and/or media from the client to the service provider and from the service provider to the client should be documented.
If the service provider uses procedures which comply with the policy document, the client should hold a copy oI, or have access to when required, the service provider’s compliance documentation.
6.162 Procedural considerations
In ideal circumstances, where the service provider can demonstrate the implementation of procedures which comply with the information management policy document, the contract need only confirm this situation and contain agreed procedures for checking compliance.
Where the service provider operates in compliance with agreed procedures, the contract should include a statement detailing the extent to which the procedures are implemented and audited.
The following list defines procedures and processes that may need to he reviewed and Included within the contract as appropriate.
— The client should check that the service provider can produce output to agreed acceptable quality standards,
— The client should check that the service provider can process a sample of information to produce output on the proposed media and in the proposed format and which can be successfully loaded on the clients target system. This sample should he retained.
— The client should check that the service provider can supply a copy of the audit trails of the processing undertaken in a readable form.
— Where indexing services are provided, the client should check with the service provider that the proposed indexing data accuracy requirements are acceptable and documented.
— The client should check that the proposed location of the work is acceptable and meets security criteria appropriate to the client’s needs.
— The client should check that the proposed procedures and processes Involve no greater risk of damage to the client’s information than the client’s procedures.
— The client should check that, where the information to be processed is unique or particularly valuable, effective fire detection and prevention systems are implemented at the proposed production location.
— The client should check that, where security of the information to be processed is important, the service provider should vouch for the trustworthiness of the intended operational staff. It is an advantage If all employees of the organization sign a confidentiality agreement as part of their conditions of employment.
— Where paper documents are sent for scanning, the service provider and client should make arrangements for the documents to be accessible to the client while they are away from the client’s premises.
6.16.3 Transportation of paper documents
Where paper documents are physically moved from the client’s to the service provider’s premises, opportunities etist for their loss or damage. Procedures need to be agreed upon to ensure that this risk is acceptable. Each shipment of documents to or from the client and the service provider should be accompanied by a control document stating the identity and number of items included.
All documents being shipped should be adequately packed to avoid risk of damage in transit. The recipient should promptly check received documents against the despatch document and advise the sender of discrepancies as soon as is practically possible.
Transportation services can be provided by the user’s own organization, by a third party or by an independent courier.
Third parties providing transportation services should be organizations demonstrably meeting the quality and reliability criteria of the client.
Notes should be taken of the date and time at which the documents were handed over to the transportation service and the date and time at which it was received by the service provider and signed by the person handing over and receiving the documents. The same process should be implemented on receipt of returned documents.
6.16.4 Use of trusted third party
A secure means for detecting any tampering with ESI, or for verifying the contents of particular ESI, is to store a copy of the ESI or its hash value with a trusted third party
If such an approach is taken, art authenticated copy of the ESI should be made and delivered either physically or electronically to the trusted third party, using secure means.
The trusted third party should follow the relevant procedures for the management of ESI as recommended by this document and should be able and prepared to demonstrate, In the same manner as the owner, the effectiveness and security of its services.
NOTE Security requirements for trusted third parties are frequently more stringent than those for the organization whose £51 they are managing.
Where digital signatures are used for authentication, instead of storing digital signatures In its own system, the organization can transmit the digital signature associated with particular information to the trusted third party. The third party will store the digital signature in secure conditions, such that it can be retrieved later.
Some trusted systems Incorporate a workflow capability. Such systems provide the procedural automation of business processes, by the management of the sequence of work activities and the invocation of appropriate human and system resources associated with the activity step.
Where workflow systems are implemented, operational details (such as flow diagrams), process
definition classifications and process definitions should be documented.
Process definition Ilfecycles include:
All ESI (databases, audit trails, etc.) held on the worktlow system should be reviewed for retention requirements and, where applicable, stored in compliance with the information management policy document.
Where changes to the workilow system are implemented, change control procedures should be implemented to ensure that ESI is not lost during the procedure.
Where an ad hoc workflow Is Implemented (I.e. one In which the rules can be modified or created during the operation of the process), a full audit trail of the process should be kept together with the identification of personnel who perlormed the changes to the standard worktlow procedures.
6.18 Date and time stamps
Procedures for the regular checking of system clocks for accuracy concerning date and time should be documented. Any errors should be corrected and any actions taken documented.
If the clocks are changed on a seasonal basis. e.g. summer time, then the procedures to be followed should be documented.
Only authorized personnel should be able to change system clocks.
Where there is a particular need to demonstrate the accuracy of date and time stamps, the use of trusted third-party services for this can be consIdered. Where trusted time Is used, procedures for demonstrating the trustworthiness of a time stamp and its binding to particular ESI should be documented.
6.19 Version control
In some applications. ESI might be subject to change. Several different versions of ESI might be developed over a period of time; in this case, iterations should be allocated version numbers. It Is important in such applications to maintain each version as separate ESI and also to maintain the link between the versions.
Where changes to stored ESI are allowed, the procedures for authorizing and implementing such changes should be documented.
Documentation regarding any requirement to retain previous versions ofsuch ESI should be available.
A version control system should he implemented to ensure that the relevant version of any compliance document can be identified for any time In the life of managed ESI. A version control procedure should be established for all documentation.
Superseded versions should be kept for at least the same length of time as that for which relevant ESI is maintained
Records of this maintenance are required so that the policies and procedures which were in force at the time of its capture, and since that time, can be described and attested to. If this is not available, there Is a risk that the trustworthiness of the ESI might be successfully compromised. For example, lilt Is not possible to he certain of the scanning procedures used to capture the image of a paper document several years old and the storage procedures followed in the years since Its capture, then It might be difficult or impossible to refute a challenge concerning the trustworthiness of the ESI.
6.19.3 Procedures and processes
All changes to procedures and/or processes should he implemented In accordance with an approved change control procedure.
6.20 Maintenance of documentation
Compliance with the information management policy document requires the availability and use of specified documentation. Procedures for the maintenance of this documentation should be included in the procedures manual. Maintenance procedures should include the keeping of records of this maintenance.
Maintenance Is required because, over time, requirements will evolve and technologies and legeslation will change. In some cases, it will suffice for maintenance efforts to be driven by recognition of changes on an ad hoc basis. Additionally, typically for more important ESI, a routine regular review will be appropriate.
Procedures for ensuring that documentation is kept up to date should be documented.
This documentation should be subject to records management disciplines which are at least as good as those applied to the organIzation’s other business records.
In particular, whenever one of these documentation items Is revised, a copy of that item prior to the change should be kept at least as long as the ESI to which it relates.
The storage of this documentation should allow for appropriate authorized parties [e.g. auditors) to identify and retrieve all the documentation in force on any required date.
Documentation can be stored electronically In the trusted system, subject to the same controls as Included in thIs document, as paper or microform Insecure locations, or as any combination of these.
The policy adopted for the storage of compliance documentation should be documented in the policy document.
In most cases, it will be desirable for changes to be documented in a way that allows an interested party to track the changes between versions. This can be implemented by recording a simple change history for each part of the documentation.
7 Enabling technologies
This subclause deals with technology-related topics that are relevant to this document, Including the following:
— system description manual (see 22);
— storage media and sub-system considerations (see 22);
— access levels see Z
— system integrity checks (see 2.5);
— image processing (see 2k);
— compression techniques (see 21);
— form overlays and form removal (see La);
— environmental considerations (see La);
— migration (see L1.):
— Information deletion and/or expungement (see LW.
Where appropriate, the guidance given in ISO/TR 22957 should be taken into consideration when the
requirements for the trusted system are being analysed, selected and/or implemented.
7.2 System description manual
A description of hardware, software and network elements that comprise the trusted system and how they Interact should be Included In the system description manual.
Details of trusted system configurations should be documented.
Details of all changes to the trusted system should be documented. Such documentation should include details of any processes implemented to effect the change.
The system description manual should be structured so that details of the trusted system at any time during the period of Its use can he readily accessed. This can be achieved by creating a new version of the manual every time there Is a change, such that It is possible to gain access to a clear description of the trusted system as it was at a particular time in the past.
For information management systems already in operation, ESI managed by the trusted system prior to the achievement of compliance with the information management policy document cannot be considered as meeting its provisions unless the controls and procedures described in this policy document have been in place from the time of acquiring that ESI.
The user should assess whether the elements of the trusted system conform to the requirements of relevant national and/or International Standards. This enables system auditors to check the performance and reliability of the trusted system against these standards.
7.3 Storage media and sub-system considerations
The risk of stored ESI being modified inadvertently or maliciously varies with the type of storage subsystem and medium. The ability to detect any such modifications also varies. For example, where write- once media Is used, It is not normally possible to modify ESI once stored, as any such modification would have the effect of destroying at least some information, resulting in ESI being corrupted. II not made totally irretrievable. Conversely, In the case of trusted systems which use online storage (Including the use of cloud storage systems), unauthorized modification, which Is typically managed by access control. can never be totally guaranteed.
ES! stored on magnetic disc and other random access rewritable media can, in principle, be modified. With such media, the risk of modification is less to do with the medium itself than with the controls that are implemented by the storage sub-system and by the access software. The ability to alter ESI requires read-write access and well-designed trusted systems have controls to prevent unauthorized read- write access. Users with read-only access are unable to modify the F.SI. This alone Is unsatisfactory unless the trusted system also maintains a secure record of all read-write accesses. In a trusted system where there are very frequent ESI modifications, there might be a substantial overhead to record these modifications, but if a record is not kept, it might prove impossible to detect any unauthorized alterations by a skilled hacker or by anyone with the appropriate access privilege.
In the case of rewritable serial media, such as magnetic tape, unauthorized tampering can be more difficult than with random access media, since if the ESI that is modified is not usually the last ESI stored on the medium, then all following ESI needs to be copied and rewritten. Once the medium is off-line, it could be tampered with more easily if an attacker were able to gain access to it. The issue of physical security of the off-line medium and access control while it is online is important.
The point In the application processes at which ESI Is requested by the software to write LI) storage should be documented.
Storage media and associated sub-systems should be chosen such that inappropriate additions, alterations and/or deletions without detection are prevented. Detection procedures can involve use of electronic/digital signatures and/or copies that are stored in different locations, possibly involving trusted third parties.
In systems that do not Include facilities that In the course of normal operations would automatically detect unauthorized alteration to or removal of ESI, users should conduct random checks to verify that ESI which has been frozen has not been altered or removed.
Where write-once media is used, consideration should be given to the retention period of the ES! being managed. Where practical, ES! with differing retention periods should not be stored on the same physical piece of medium.
7.4 Access levels
Detail of all levels of access available in the system and procedures for their use should be documented.
These levels are usually available as follows:
— system manager;
— system administrator;
— system maintenance;
— authors or originators;
— information storage and indexing
— information retrieval.
Only staff with the relevant access rights should be permitted to enter or amend ESI.
System access rights should be granted only after the member of staff has successfully proved his or her competence.
7.5 System Integrity checks
Facilities should be provided within the system to ensure that the trustworthiness of ESI is preserved throughout the system, including during its transfer to and from the storage medium.
A suitable approach is to utilize a checksum or hash value calculated Immediately after the ESI has been captured. This technique ensures that any errors In ES! transfer between sub-systems can be detected automatically and with certainty. Such a method on its own does not cover the possibility of malicious manipulation of the ES! between the time of capture and the time of committal to the storage media. Such manipulation could be accompanied by the calculation of a new checksum or hash value if the checksum or the hash value algorithm were known or deprecated. To deal with this eventuality, other procedures are required. A simple method is to write each checksum or hash value to the audit trail after calculation and protect the audit trail from manipulation.
To protect the ES! from malicious software, appropriate protection software should be installed and kept up to date.
Where appropriate, hardware to protect the system from power failure should be installed.
7,5.2 DigItal and electronic signatures (Including biometric signatures)
Digital and electronic signatures oiler the possibility of demonstrating that retrieved ESI is exactly what was acquired. The implementation of these signature systems usually requires the cooperation of both parties. Signatures are either created with signature digitizing devices (electronic) or using a key (digital) and are associated with the ES!. In some cases, the retriever might use the signature to verify the identity of the original signatory and, with some signature systems, the trustworthiness of the ES!. This applies to storage, workflow or transmission, whether real-time or store-and-forward transmission systems are used. Signatures should be used in applications where It Is Important to be able to confirm the trustworthiness of received ESI and potentially the Identity of the sender. Signatures should be stored securely. Access to signature files, keys and algorithms should be allowed only to authorized personnel.
Digital and electronic signatures used to demonstrate the non-alterability of ES! should include a checksum or hash value embedded in the ESI and/or stored in a secure system bound to the original ES!.
Processes used for the Issue, maintenance and/or creation oldigital and electronic signatures should be documented. These processes should Include mechanisms for verifying the true identity of the person prior to that Individual being enrolled as a signatory.
If a query is raised about the trustworthiness of ES!, signatures can be used as evidence in demonstrating that any ES! received by transmission contains the same information as the original ESI. Processes to be implemented where a query is raised about the trustworthiness of ES! containing a digital signature should be documented.
7.6 Image processing
Where scanning processes have been used, post-scanning processes can be performed to achieve optimum image quality, or to improve recognition rates for an automated data capture process. Where post-scanning processes are performed, the effect on the image of each of these processes should be individually documented.
The term post-scanning processes is used to describe various image enhancement techniques using hardware and/or software that can singularly or independently have an effect on the presentation of image output and the size of the stored ES!. They can be Installed either on a scanner workstation or on a network server.
The more common techniques include:
— de-speckle/background clean-up;
— black border removal;
— form removal (see also 2fl).
Image processing facilities should be used with care. For example, the de-speckle process might remove decimal points, thus, altering the value of numbers.
Any processing performed on the digitized image should not affect the trustworthiness of the Image as a true facsimile of the original. To check that any Image processing does not affect the trustworthiness of the scanned images, a sample set of paper documents should be scanned with the image processing active and prints of these images compared with the originals.
Where image processing techniques are used, consideration should be given to storing images ol the sample set of paper documents with and without image processing.
The effect of processing performed on a grey scale image prior to conversion to a black-and-white image should be checked for acceptability.
Speckle removal should only be used with particular care and its use should he documented. Speckle removal results in the elimination of single pixels or small groups of pixels from an electronic image. resulting in a subjectively cleaner image, but it cannot be relied upon lust to remove noise from the image. With some kinds of paper document, there is a high risk that information might be removed, e.g. parts of already broken characters, punctuation marks or parts of fine detail in drawings.
If speckle removal is used routinely on images, then without explicit information on the identity of images to which it has been applied, it can be assumed subsequently that all images have had speckle removal applied. This could affect the ability to demonstrate the trustworthiness olthese images, if any doubt were raised about the completeness of the Images.
The use of speckle removal can be documented in the operator log, or elsewhere in the audit trail, or by using additional data associated with the relevant image.
Where it is important that there should be no loss of information in the scanned image, other than that due to the scanning resolution, there should be no image processing subsequent to the initial creation of the image file.
Where Image processing techniques might affect the trustworthiness of a stored image, consideration should be given to also storing the original (e.g. unprocessed) image.
7.7 Compression techniques
The use ofelectronic compression techniques should be in accordance with the information management policy document. Such techniques can be applied to ESl prior to, or during storage, to reduce the size of the ES) and/or to Improve system performance.
The type of compression used is usually application dependent, though some systems can have builtin compression that the user has no alternative but to use. For further infonnation on compression methods, see lSO/TR 12033.
Compression can use various mathematical approaches, but all can be classified into two classes. namely lossy or lossless.
The compression techniques used and their lossless or lossy attribute should be documented. The documentation should be quantitative and include the algorithm used to compute the extent of loss. This information can be stored as part of the ES) or Its related information, or using a separate log.
NOTE For example, in the case of image files stored In TIFF (and some other) format, the compression method is automatically stored within the image file.
Lossy compression techniques should be used with care. By definition. lossy techniques lead to irreversible data loss, even though in some instances, this loss is not visually apparent. Thus. decompressed ESI will not be identical to the original ESI. This might make the demonstration of trustworthiness of ESI more difficult. For example, on an image file, parts of text or drawings might be removed, being replaced by artificially generated information. Thus, there might be risk in using lossy compression on files primarily containing text (including handwriting) or line drawings.
Lossy compression can be suitable for photographic or other continuous-tone material, grey scale or coloured documents where it can be shown that there Es no significant loss of Information In the scanned Image.
If lossy compression is used, a sample set of decompressed ES) should be compared with the originals to check that there is no significant loss of information.
if lossy compression techniques are used, the compression ratios achieved should be documented.
The compression ratio should be chosen, where possible, so that all information that is required within the application context is present in the decompressed ESI.
The maximum compression ratio acceptable can be determined using the sample set or si and can vary between different ESI in the sample set. It might be necessary to decide whether to use different compression ratios for different ESI or to use a single ratio. lithe latter approach Is adopted, this will usually mean that the average size will be higher, but the speed of processing will also be higher because of reduced operator intervention.
Where it is important that there be no loss of information in a scanned image other than that due to the scanning resolution, lossy compression should not be used. Examples of information for which compression using iossy techniques is not recommended include radiographs [i.e. medical and engineering X-ray Images).
Where compression is used, the system should provide adequate facilities, preferably using automated means, to ensure that the requirements for quality control (e.g. checking of image quality after scanning, with the ability to rescan, if necessary, control over associated data accuracy, control over data integrity) on the compressed ESI can be met.
7.8 Form overlays and form removal
Where an original document consists ola form with overlaid Information, the form can be electronically removed from the scanned image prior to storage (known as form removal).
Where an electronically removed form is held separately from the scanned images to which it relates, it should be controlled as if it is part of the scanned image.
A record should be retained that the resulting image (without the form) has been the subject of form removal and an identifier of any template used for that removal should also be retained. This information should be stored in conjunction with the resulting image. A copy of any template used should also be stored.
A facsimile made by merging the template with the stripped form might not be a true facsimile of the original, although it can be sufficiently accurate for application use.
The trustworthiness of such a merged image can be difficult to demonstrate, particularly where misalignment of the form and the overlain information is evident on the merged image.
It might be appropriate to retain true facsimiles of the original forms, by retaining the originals, making a microfilm copy or retaining a complete image of the form.
7.9 Environmental considerations
A description of the hardware manufacturer’s recommendations for the operational environment of all
components of the trusted system and of storage media should be documented. Media handling and storage procedures should also be documented.
All types of storage media have a finite life. In order to ensure that ESI is retrievable, regular checking of the media in accordance with the manufacturer’s recommendations is necessary. Procedures for checking the condition of the media should be documented. Media should be checked regularly in accordance with the media manufacturer’s recommendations.
ESI might need to be retained for a considerable length of time and, importantly, for longer than the lifetime of the current technology. Thus, to ensure the trustworthiness of ESI, it is important to plan
from the outset that it might be subject to migration processes. Such processes might involve a change of media and/or change of computer hardware and/or software.
A reliable methodology for dealing with this potential problem is to ensure that £51 is stored in an industry standard format and/or that viewers for each stored format are maintained.
There should be provision for migrating ESI. including metadata, Index data and audit trails, to new technology without loss of trustworthiness and with sufficient migration process audit documentation to allow the trustworthiness of the ESI to be established at any time in the future.
7.11 Information deletion and/or expungement
It might be necessary to dispose/delete/expunge specific £Sl from trusted systems, for instance to comply with a legal or regulatory requirement.
Sometimes, circumstances might require that ESI scheduled for disposal under Its normal retention schedule is not to be disposed of at that time. There should be processes in place which can ensure ESI is reviewed prior to destruction, so that these special Instances can be accommodated.
Where £51 is managed using WORM media, deletion of specific ESI may not be possible (unless a controlled process of selective copying to new media is implemented). In some applications, It might be accepted that removal of all Index references to the F.Sl being deleted is, in practical terms, deletion of the ESI itself. In some applications, it might be acceptable to mark ESI as deleted. Where necessary, organizations should check that the implemented procedure is acceptable to the appropriate authority. Care should be taken with such processes, as in some circumstances there might still be a requirement to retrieve this “deleted ESI,
When positive removal of ESI from the trusted system is required, the identification and deletion of all copies of the ESI (including backup media) will ensure that the necessary action is taken.
The trusted system should have facilities to dispose of, delete or expunge ESI using an auditable process.
Where deletion and/or expungement is Implemented, appropriate authorization should be obtained prior to the action being implemented.
The trusted system should have the facility to amend incorrect ESI or remove unwanted £51.
Where amendment or deletion is performed in compliance with legislation, suitable records should be kept to enable compliance with the legislation to be demonstrated.
For more advice on deletion from writeonce systems, see lSO/TR 12037.
8 Audit trails
8.1.1 Audit trail data
When preparing ESI for use as evidence of a transaction or event, it is often necessary to provide further supporting Information. This information can include details such as date of storage of the ESI, details of movement of the £51 from medium to medium and evidence of the controlled operation of the trusted system. These details are known as audit trail information. The audit trail as described in this document consists of the aggregate ci the information necessary to provide a historical record of all significant events associated with ESI and the trusted system. These details can be split into two categories:
Records should be kept of trusted system historical activities or events that might need to be reconstructed in the future, in support of the managed ESI.
Audit trails should contain sufficient and necessary information to enable the demonstration of the trustworthiness of the managed lSl.
There are frequently a number of departments (or Individuals) within an organization (or external to the organization) who might need to access audit trail information, Including those representing user, audit and legal functions.
The content of the audit trail should be agreed upon with all relevant departments within the organization. In most organizations, the audit trail will consist of a collection of system- and operator-generated logs, The audit trail should contain information about changes to the ESI managed by the system.
Audit trail information should, as far as is practicable, be generated automatically by the system and the system description manual should describe the processes. It should not be possible to pause or stop the audit trail creation processes.
In the case of audit trail Information not generated automatically by the system, the procedures for generating such Information should he documented In the procedures manual. Consideration should be given to the scope of each audit trail. For example, where a particular piece of ESI Is created in draft form and progresses through many drafts, does each draft require a full audit trail, or just the final document?
Automatic audit trails are preferable, as they are easier to manage and authenticate. Where automatic audit trails are not available, the resources needed to create an automated process should be carefully reviewed.
Procedures to he followed when an audit trail storage area becomes full (and the identification of this situation) should be documented In the procedures manual.
8.1.3 Date and time
Audit trail information should have an associated date and time, which relates to the date and time of the audit train inlormation being stored.
The date and time of the event that is stored should be sufficiently accurate that a subsequent investigation can determine the train of events.
The date and time will normally be that of the creation of the audit trail information, but if this creation is made essentially contemporaneously with the event that is being documented, the time will be to all intents and purposes that of the event itself.
In the case of audit traIl Information that Is generated manually. it should be created as soon as possible after the event that Is being documented. For example, If the record is of when an operator started work, document the fact at that time. If the record is of when preparation of a particular batch of paper documents was started, document the fact just before the preparation oIthat batch commences.
Where the actual time that an event occurred is important, the use of trusted time should be considered.
The storage of audit trail information is a topic often not included in an organization’s information management policies. As they are frequently created automatically and rarely accessed, they are forgotten and thus, not subject to adequate control.
Some information management systems control the size of audit trail storage area by the use of looping. which sets the maximum size for the storage area, and when this size is reached, new information overwrites the oldest information. Thus, old audit trail information is lost.
Audit trail Information should be included as a specific document type in the policy document. Audit trail Information should be stored for at least as long as the ESI to which it refers.
Audit trail information needs to be accessed by relevant operators at relevant times. In some applications, access might only be needed on an ad hoc basis, and thus, it is important that the access and interpretation procedures are documented.
The procedures manual should describe how the audit trails can be accessed and interpreted.
Audit trail information should be available for inspection by authorized external personnel (such as
auditors) who have little or no familiarity with the system.
8.1,6 Security and protection
If the trustworthiness of ESI is questioned, the trustworthiness of the audit trail can be fundamental in establishing the trustworthiness of the ESI. The audit trail should be kept at the level of security appropriate to preventing any change to any information within it.
Audit trail information should be stored securely in accordance with the relevant information security policy. The audit trail should be subject to internal records management procedures at least as good as other records of the organization.
Secure backup copies of the audit trail should be kept. This applies to audit trail Information kept on electronic media and on paper/microfilm.
Audit trail information kept within the trusted system should not be modifiable. Where file recovery procedures have been implemented, sufficient audit trail information should be stored to demonstrate that the recovery did not affect ESI trustworthiness.
For least risk, audit trail Information should be stored on WORM media. If a rewritahle medium is used, then additional procedures need to be Implemented to prevent changes being made. The use of magnetic tape can make it relatively difficult to modify information, as magnetic tape Is normally a serially written medium.
If the possibility exists that the audit trail information could be modified, it will be more difficult to establish the trustworthiness of any ESI to which these trails apply.
Paper documents used for audit trail information should be frequently removed from the place of use and stored securely. The longer a document that is used for audit trail data e.g. operator logs) is left in a relatively Insecure place, for example, at a worksLatlon. the higher the risk of tampering. Users need to assess such risk when using paper for audit trail records. Where paper documents are used, storing copies of them on the trusted system Is recommended.
See also 2.i for protection over long time periods by the use of mig ration or other techniques.
These records include details on the following topics:
— audit trail information;
— migration and conversion.
8.2.2 Audit trail information
For all system audit trail information, it should be possible to
identify the process involved and the date and time of the event.
Depending on its importance, date and time information can be stored
on a batch (where relevant) or individual event basis. Where audit
trail information is manually stored by an operator, it might be
impractical and unnecessary to create audit trail information on a
per-document basis. For example, when undertaking paper document
preparation for scanning, it might be sufficient to document the time
at which preparation of a batch of documents started and ended. It can
suffice to document simply when the operator started and ended work,
provided it is possible to identify subsequently which operator
prepared which documents.
8.2.3 MIgration and conversion
Where ESI is moved from one storage device to another, as part of a
migration process, details of the move should be stored in the audit
Procedures for migration or conversion should include methods by which
It can he demonstrated that any related Information (such as metadata)
Is also migrated or converted.
In the case of hierarchical storage management systems (HSMs) or other
similar devices where ESI is routinely and automatically moved between
storage devices without user intervention, it might not be necessary
to generate audit trail information on these movements of ESI.
However, it might be necessary to demonstrate that the HSM was working
normally when ESI was transferred.
Where ESI has been converted from one tile format to another, details
of the conversion should be stored in the audit trail. For example, an
electronic document created by a word processor program can be
converted to an image format without changing the text within the
document. From one perspective. this might be considered not very
different from copying a [lie, but If formatting Is relevant to the
ESI content, there is the possibility that the Information content of
the converted ESI can be considered to have changed.
The audit records should include details on the following topics:
— ESI capture;
— batch information; Indexing;
— change control;
— use of digital signatures;
— destruction of ESI;
8.3.2 ESI capture
Audit trail information about the capture process provides invaluable
information to assist in the authentication of ESI. Details such as
capture time, operator, capture device and type of original can prove
vital when trustworthiness is challenged.
Information should be kept in the audit trail of key information concerning ESI captured by or imported
into the trusted system. Sufficient information should be stored relating to each processing procedure.
Information that can be stored in the audit trail will typically include:
— ESI Identification;
— process date and time stamp;
— batch reference (for batch input):
— number of pages (for document scanning) or data records (data capture);
— quality control check approval;
— an Identifier for each item that was indexed;
— operator or workstation identifier;
— final write to storage.
The choice of actual Information to be stored In the audit trail will depend upon the application and
184.108.40.206 File information
Information can be captured by the system on a file-by-file basis. This Is particularly true where ESI Is
Imported Into the trusted system. Where ESI Is captured on a Ille’by’flle basis, the following audit trail
Information should be stored:
— unique ESI identifier;
— number of documents/pages within the ESI;
— size of the ESI (e.g. kilobytes);
— file format;
— file codes (e.g. EDI values, DTD, etc.).
220.127.116.11 Scanned document information
ESI can be captured by the system by the scanning of original documents.
Where document scanning is involved, the following audit trail information should be stored:
— unique internal document identifier;
— number of page Images scanned;
— number of pages sent to storage device,
8.3.3 Batch information
a) Where ESI Is captured on a batch basis, particularly in document scanning applications, the following audit trail information should be stored:
— unique batch identifier;
— operator identifier;
— type of material scanned, e.g. paper documents, roll microfilm, aperture cards;
— quantity of material in the batch, e.g. number of documents, number of pages (single/double sided), number of microfilm frames;
— details of image processing performed during the scanning processes, where this is different from any default imaging processing described in the system description manual.
b) Audit trail Information should be stored so that It Is easy to check:
— that all required activity has been performed for that batch;
— details of any anomalies or discrepancies that have been encountered;
EXAMPLE Number of pages written to storage no agreeing with number of pages scanned
— that quality control procedures have been completed;
— that required exception processing has been completed.
Indexing information is vital to the ESI retrieval process, and thus, its accuracy is important when establishing the trustworthiness of ESI. Audit trail information detailing the creation and modification of indexes can be used to demonstrate that indexing procedures have been correctly utilized.
Information should be kept in the audit trail detailing the date and time of the creation, amendment and deletion of every index file. Audit trail information should include an identifier for each ESI that Is indexed.
Where index Information can be amended or deleted, audit trail information should be generated. If an index is being amended. details of the amendment can also be stored.
Where an index item relates to disposed of, deleted or expunged ESI this fact should be documented.
8.3.5 Change control
Where a change is made to ESI, audit trail information should be created and stored, identifying the nature of the change and the person who, or the program (where the change was made automatically by the system) that, initiated the change.
Where approprIate, previous versions of the ESI should be referenced in the audit trail information to identily the nature of the change
8.3.6 Digital signatures
Where digital signatures (or other electronic signing techniques) are used, audit trail information should be kept as follows:
— File Identilicatlon;
— certification of identification;
— authenticating authority identification:
— any algorithms used:
— date and time of signature:
— return receipt/confirmation;
— proof of validation.
8.3.7 Destruction of information
Audit trail information should be kept of the destruction of paper documents following document scanning. Audit trail information should also be kept of the disposal or destruction of ESI at the end of the relevant retention period. Audit trail Information should also be kept of the authorization for disposal or destruction.
There should he a record, for audit trail purposes, each time a new business process Is defined, or an existing definition Is changed.
Where workilow systems are In use, audit trail points should be detined at which audit trail information should be generated.
In most workflow systems, an audit trail point exists at each step in the workflow. However, for compliance with the policy document, audit trail inlonnation might not need to be kept for every audit trail point. The user should decide which audit trail points are relevant with regard to the potential evidential importance of the F,Sl within the workflow. These audit trail points should he selected for the generation of audit trail Information.
The selected audit trail points can change as the workflow processes are changed.
The system should permit an authorized user to select and de-select the audit trail points for which audit trail information is generated Any such selection/de-selection should be auditable.
ISO TR 15801:2017 pdf free download
ISO TR 15801:2017 pdf free download.Document management Electronically stored information Recommendations for trustworthiness and reliability.