ELECTRONIC RECORDKEEPING SYSTEMS STANDARD

PART B > FUNCTIONAL SPECIFICATIONS

4 > CONTROLS AND SECURITY

Access

The electronic recordkeeping system must:

4.1	allow the Administrator to limit access to records, aggregations and recordkeeping metadata to specified users or user groups.
4.2	allow the Administrator to attach to the user profile attributes which determine the features, recordkeeping metadata fields, records or aggregations to which the user has access. The attributes of the profile will: prohibit access to the electronic recordkeeping system without an accepted authentication mechanism attributed to the user profile; restrict user access to specific records or aggregations; restrict user access according to the user's security clearance; restrict users access to particular features (e.g. read, update and / or delete specific recordkeeping metadata fields); deny access after a specified date; allocate the user to a group or groups. An example of an accepted authentication mechanism is a password.
4.3	be able to provide the same control functions for roles as for users. This feature allows the Administrator to manage and maintain a limited set of role access rights rather than a larger number of individual users. Examples of roles might include Manager, Claims Processing Officer, Security Analyst, Database Administrator.
4.4	be able to set up groups of users that are associated with an aggregation. Examples of groups might be Personnel, or Sales team.
4.5	allow a user to be a member of more than one group.
4.6	allow only Administrators to set up user profiles and allocate users to groups.
4.7	allow changes to security attributes for groups or users (such as access rights, security level, privileges, password allocation and management) to be made only by the Administrator.
4.8	provide one of the following responses (selectable at configuration time) whenever a user requests access to, or searches for, a record, volume or aggregation that they do not have the right to access: display title and recordkeeping metadata; display the existence of an aggregation or record (i.e. display its file or record number) but not its title or other recordkeeping metadata; do not display any record information or indicate its existence in any way. These options are presented in order of increasing security. Note that the requirement in the third option (i.e. the most stringent) implies that the electronic recordkeeping system must not include such records in any count of search results.
4.9	never include, in a list of full text or other search results, any record which the user does not have the right to access. Note that if the first option of requirement specification 4.8 is chosen, specification 4.9 may appear to be in conflict with it. This apparent conflict is intentional, for if this requirement is not present users may be able to use text searches to investigate the contents of documents to which they are not allowed access.

If the electronic recordkeeping system allows users to make unauthorised attempts to access aggregations (and their volumes) or records, the electronic recordkeeping system must:

4.10	log all unauthorised attempts to access aggregations (and their volumes) or records in their respective audit trails. It will be acceptable for this feature to be controllable so that it only applies to administrator-specified security categories.

If the electronic recordkeeping system maintains a list of aggregations, the electronic recordkeeping system must:

4.11	be able to limit users' access to parts of the list (to be specified at the time of configuration).

The electronic recordkeeping system should:

4.12	allow a user to stipulate which other users or groups can access records that the user is responsible for. This function should be granted to the user by the Administrator according to the agency's policy.

Audit Trails

The electronic recordkeeping system must:

4.13	be capable of creating an unalterable audit trail of recordkeeping actions (actions to be specified by each agency) that are taken upon records, aggregations, or the classification scheme. The audit trail should include the following recordkeeping metadata elements: type of recordkeeping action; user initiating and/or carrying out the action; date and time of action. The word "unalterable" is to mean that the audit trail data cannot be modified in any way or deleted by any user; it may be subject to reorganisation and copying to removable media if required by, for example, database software, so long as its content remains unchanged.
4.14	track events, once the audit trail functionality has been activated, without manual intervention, and store in the audit trail information about them.
4.15	maintain the audit trail for as long as required.
4.16	provide an audit trail of all changes made to: electronic aggregations (including volumes); individual electronic records; recordkeeping metadata associated with any of the above.
4.17	provide an audit trail of all changes made to administrative parameters (for example, changes made by the Administrator to a user's access rights).
4.18	be capable of capturing and storing in the audit trail information about the following actions: the date and time of capture of all electronic records; re-classification of an electronic record in another electronic volume; re-classification of an electronic aggregation in the classification scheme; any change to the disposal authority of an electronic aggregation; any change made to any recordkeeping metadata associated with aggregations or electronic records; date and time of creation, amendment and deletion of recordkeeping metadata; changes made to the access privileges affecting an electronic aggregation, electronic record or user; export or transfer actions carried out on an electronic aggregation; date and time at which a record is rendered; disposal actions on a electronic aggregation or record.
4.19	ensure that audit trail data is available for inspection on request, so that a specific event can be identified and all related data made accessible, and that this can be achieved by authorised external personnel who have little or no familiarity with the system.
4.20	be able to export audit trails for specified records and selected groups of records without affecting the audit trail stored by the electronic recordkeeping system. This functionality can be used by external auditors who wish to examine or analyse system activity.
4.21	be able to capture and store violations (i.e. a user's attempts to access a record or aggregation, including volumes, to which he or she is denied access), and (where violations can validly be attempted) attempted violations, of access control mechanisms. It is acceptable for this feature to be controllable so that it only applies to administrator-specified security categories.
4.22	be able, at a minimum, to provide reports for actions on records and aggregations organised: by record or aggregation; by user; in chronological sequence.

The electronic recordkeeping system should:

4.23	allow the audit trail facility to be configurable by the Administrator so that the functions for which information is automatically stored can be selected. The electronic recordkeeping system must ensure that this selection and all changes to it are stored in the audit trail.
4.24	be able to provide reports for actions on aggregations and records organised by workstation and (where technically appropriate) by network address.

Backup and Recovery

Electronic recordkeeping systems must have comprehensive controls to create regular backups of the records and recordkeeping metadata that they maintain. These backups should enable the electronic recordkeeping system to rapidly recover records if any are lost because of system failure, accident, or security breach. In practice, backup and recovery functions may be divided between electronic recordkeeping system administrators and information technology staff.

The electronic recordkeeping system must:

4.25	provide automated backup and recovery procedures that allow for regular backup of all or selected classes, aggregations, records, recordkeeping metadata and administrative attributes of the electronic recordkeeping system repository.
4.26	allow the Administrator to schedule backup routines by: specifying the frequency of backup; selecting classes, aggregations or records to be backed up; allocating storage media, system or location for the backup (e.g. offline storage, separate system, remote site).
4.27	allow only the Administrator to restore from electronic recordkeeping system backups. Full integrity of the data must be maintained after restoration.
4.28	allow only the Administrator to roll-forward the electronic recordkeeping system from a backup to a more recent state, maintaining full integrity of the data.
4.29	allow users to indicate that selected records are considered to be 'vital records'. Vital records are those records that are absolutely necessary to the organisation's ability to continue its business either in terms of its ability to cope with emergency/disaster conditions or to protect its financial and legal interests. The identification and protection of such records, therefore, is of great importance to any organisation.

The electronic recordkeeping system should:

4.30	be able to notify users whose updates may have been incompletely recovered, when they next use the system, that a potentially incomplete recovery has been executed.
4.31	allow vital records and other records to be restored in distinct operations.

Tracking Record Movement

The electronic recordkeeping system must:

4.32	provide a tracking feature to monitor and record information about the location and movement of both electronic and nonelectronic aggregations.
4.33	record information about movements including: unique identifier of the aggregation or record; current location as well as a user-defined number of previous locations (locations should be user-defined); date item sent/moved from location; date item received at location (for transfers); user responsible for the move (where appropriate).
4.34	maintain access to the electronic record content, including the ability to render it, and maintenance of its structure and formatting, over time and through generations of office application software. This may be, but does not have to be, by use of a multi-format viewer application.

Authenticity

The electronic recordkeeping system must:

4.35	restrict access to system functions according to user's role and strict system administration controls.
4.36	be able, where possible and appropriate, to provide a warning if an attempt is made to capture a record which is incomplete or inconsistent in a way which will compromise its future apparent authenticity. For example, a purchase order without a valid electronic signature, or an invoice from an unrecognised supplier.
4.37	prevent any unrecorded change to the content of the electronic record by users and Administrators.

Security Categories

The specifications in this section only apply to agencies that are managing classified records within their electronic recordkeeping system.

The electronic recordkeeping system must:

4.38	allow security classifications to be assigned to records.
4.39	allow one of the following to be selected at configuration time: security classifications to be assigned to aggregations (including volumes) and records; security classifications to be assigned to individual records.
4.40	allow one of the following security clearances to be assigned to users:²¹ Unclassified; In Confidence (policy and privacy); Sensitive (policy and privacy); Restricted (national security information); Confidential (national security information); Secret (national security information); Top Secret (national security information).
4.41	deny users access to electronic records that have a security classification higher than their security clearance. Note that the correct level of security clearance may not be sufficient to obtain access. Access to the electronic records may in addition be restricted to specified users, roles and / or groups.
4.42	support the automated application of a default value of 'Unclassified' to an aggregation or record not allocated any other security category.

The electronic recordkeeping system should:

4.43	enable its security subsystem to work effectively together with general security products.
4.44	be able to determine the highest security category of any record in any aggregation by means of one simple enquiry.
4.45	support routine, scheduled reviews of security classifications.

If security classifications are assigned to aggregations as well as individual records (as per specification 4.39), then the electronic recordkeeping system must:

4.46	deny users access to aggregations that have a security classification higher than their security clearance. Note that the correct level of security clearance may not be sufficient to obtain access. Access to the electronic records may in addition be restricted to specified users, roles and / or groups.

If security classifications are assigned to aggregations as well as individual records (as per specification 4.39), then the electronic recordkeeping system should:

4.47	be capable of preventing an electronic aggregation from having a lower security classification than any electronic record within that aggregation.

21. Security in the Government Sector. Chapter 3.