IS.AR.230 Record-keeping

Records are required to document results achieved or to provide evidence of activities performed. Records become factual when recorded and cannot be modified. Therefore, they are not subject to version control. Even when a new record is produced covering the same issue, the previous record remains valid.

When complying with the requirements under points (a)(1)(iv) and (a)(4), the competent authority should establish a data retention policy defining procedures to:

(a)manage relevant information security data files;

(b)establish the periodical assessment of their content; and

(c)define the criteria to allow deletion of records of information security events when the objective of requirement (a)(4) has been met.

The objective of the requirement (a)(1)(iv) is to ensure detection of possible indication of information security incidents or vulnerabilities which are not obvious by normal operation (e.g. previously unknown situations), while the objective of the requirement under (a)(4) is to allow the necessary flexibility to control the volume of the stored information security events. Records of information security events include those events identified within the scope of the detection activities under IS.AR.215(a), as well as other information security data produced by assets that have been identified under IS.AR.205. A data retention policy clarifies what information should be stored or archived and for how long. Some guidance about data retention can be found in EUROCAE ED-206, Chapter 2.6. Once a data set completes its retention period, it can be deleted or moved as permanent historical data to a secondary or tertiary storage.

When complying with the requirements under points (c) and (d) for all the records required by points IS.AR.230 (a) and (b), the competent authority should consider the following:

(a)Records should be kept in paper form or in electronic format or a combination of both media. The records should remain accessible whenever needed within a reasonable time and usable throughout the required retention period. The retention period starts when the record has been created.

(b)Records data integrity, availability and authenticity should be protected in consistency with protection of corresponding operational data, and as such, should be within the scope of the ISMS.

(c)Storage systems should be protected against unauthorised access (i.e. data leakage attempts against personal data/modification of records) and thus should have information security measures implemented in consistency with the level of information security risk associated with them.

(d)Once records are not required to be retained anymore, the destruction of records and decommissioning of assets used for their storage should be implemented appropriately.

RECORDS ACCESSIBILITY THROUGHOUT THE RETENTION PERIOD It is recommended to follow best practices for data retention, for data that may need to be restored, backup strategies, such as the use of automated backup tools, segregation or geographic separation of backup storage location(s), and to consider offline backups to prevent ransomware risks. These practices should be considered also when record-keeping is contracted to service providers with distributed resources. Special attention should be paid to significant hardware and software changes, ensuring that stored digital records remain accessible and readable (e.g. file system, application file format, forward compatible database versions, etc.). Paper-based information needs to be archived in an adequate environment, in which records are protected against degradation factors (e.g. excessive heat, light or humidity). RECORDS DATA INTEGRITY AND PROTECTION FROM UNAUTHORISED ACCESS A commonly used method to achieve authenticity and integrity protection is the use of digital signatures at document level. Digital signatures can be added to the document’s file (e.g. PDF) to ensure that a record has not been modified by someone other than its author (integrity) and that the author is who is expected to be (authenticity). Moreover, to prevent unauthorised access, records can be protected, for example, by implementing a role-based access control (RBAC) approach, or certain records can be password protected at the file level. Commercial applications feature built-in basic password protection functions for their file formats. Access protection can also be achieved by protecting the environment where the individual records are stored (e.g. access protection on databases, file shares, directories, etc.).