Administrative Functions

ERM Community Wiki

Community Topic(s): ERM


From MoReq 2 (Model Requirements for the Management of Electronic Records). This specification has been prepared for the European Commission by Serco Consulting with funding from the IDABC programme. MoReq 2 is available in electronic form at the following urls:

* http://dlm-network.org/moreq2
* http://ec.europa.eu/transparency/archival_policy

9. ADMINISTRATIVE FUNCTIONS
This chapter covers the maintenance and system support functionality required by an ERMS.

Requirements are listed in this chapter for:

  • general administration (section 9.1);
  • system reporting (section 9.2);
  • changing, deletion and redaction of records (section 9.3).
    Closely-related features are described in chapter 4, namely;
  • access permissions in section 4.1;
  • backup and restore in section 4.3.
    These facilities allow administrative roles to manage change in the user population and parameters affecting the behaviour of the system. The ERMS needs to provide administrative roles with the ability to manage events such as maintaining the user base and, crucially, the permissions assigned to users, groups and roles. The system must also provide monitoring capability for system errors.
    Some of these facilities may be provided by an associated EDMS, database management system, operating system, or by other applications.

9.1 General Administration
This section includes requirements for managing system parameters, system management and configuration, and user administration.
In large organisations, the functionality described in this section may be assigned to an operations function rather than to an application administrator. However, in small organisations, it may be assigned to an administrator.

9.1.1 The ERMS must allow administrative roles to retrieve, display and re-configure systems parameters and settings made at configuration time.

These settings include, for example, configuration of access rights or classification codes.

9.1.2 The ERMS must allow administrative roles to:
  • allocate functions to users and roles;
  • allocate one or more users to any role.

9.1.3 The ERMS must monitor available storage space, and notify administrative roles when action is needed because available storage is below a level set at configuration time, or because of another error condition.

It is acceptable for administrative roles to be notified by means of separate system management software.

9.1.4 Where the storage supports error rate reporting, the ERMS should monitor error rates occurring on storage media, and report to administrative roles any medium or device on which the error rate is exceeding a parameter set at configuration time or at a later date.

This applies particularly to optical media.

It is acceptable for administrative roles to be notified by means of separate system management software.

9.1.5 The ERMS should allow administrative roles easily to move users between user groups and roles.

In particular, it should be possible to move a user without having to delete the user from the ERMS and re-enter the user’s details.

9.2 Reporting
Flexible reporting is an important feature in an ERMS. It is required so that administrative roles can manage the system; and so that management can monitor the ERMS to ensure that it is used appropriately.

An ERMS needs to be able to provide a number of management, statistical and ad hoc reports so that administrative roles can monitor system activity and status. This reporting is required across the entire system, including:
  • the classification scheme;
  • files and records;
  • user activity;
  • access and security permissions;
  • disposition activity.

The ERMS must provide a number of standard reports capable of being configured by administrative roles and should be flexible to enable ad hoc reports to be produced on demand.

Ideally the ERMS will include a flexible report-writing sub-system. However, it is not appropriate to attempt to reproduce here the requirements for a comprehensive report writing sub-system, so this section gives outline requirements only. The amount and complexity of reporting will be determined by organisational features including the size, complexity and levels of change to the classification scheme, the amount and nature of the records, and the user base.

9.2.1 The ERMS must allow administrative roles to produce periodic reports (daily, weekly, monthly, quarterly) and to specify ad hoc reports.

9.2.2 The ERMS must include features for printing reports, viewing them on-screen and storing them in electronic form.

As in section 8.3, “printing” is understood to include features normally associated with report production such as multi-page reports, page numbering, dated headings, configurable page headers and footers, and use of any configured printer). Sending screen image dumps to a printer is not normally considered sufficient for these requirements.

9.2.3 A user viewing an ERMS report should be able to capture it as a record.

This will be useful, for example, for storing securely reports that attest to the integrity of the records.

9.2.4 The ERMS should allow time periods covered by a report to be configured either as a date range (e.g. 24/12/2008 – 5/1/2008) or as a time interval specified in natural language (as in ‎8.1.29).

9.2.5 The ERMS must include features for sorting and selecting the information included in reports.

For example, users should be able to specify which columns of a columnar report are used to sort the report contents.

9.2.6 The ERMS should include features for totalling and summarising report information.

9.2.7 The ERMS should include features for graphical reporting.

For example, trend-reports showing changes in reported information over time, or histograms.

9.2.8 The ERMS must enable report requests to be saved for future re-use.

9.2.9 The ERMS must enable reports to be exported for use in other applications.

For example, users may wish to work with the contents of a report using spreadsheet software. MoReq2 does not specify the format(s) to be used for such exports.

9.2.10 The ERMS must be able to provide reports on the total number and location of:
  • files, sub-files and volumes;
  • records, sorted by file format and version;
  • files, sub-files and volumes, sorted by access control and security markings (where used);
  • electronic files, sub-files and volumes, sorted by size;
  • electronic files, sub-files and volumes, sorted by storage location;
  • vital records.

9.2.11 The ERMS must be able to provide reports on:
  • the rate of capture of records;
  • the rate of retrieval of records;
  • the rate of creation of new classes and files.

9.2.12 If the document management option described in section 10.3 is present, the ERMS must be able to provide reports on
  • the total number and location of documents;
  • the rate of capture/creation of documents;
  • the rate of retrieval of records.

9.2.13 The ERMS should allow the reports described in ‎9.2.11 and ‎9.2.12 to be for any combination of:
  • across the entire system or for specified classes;
  • specified user groups or users;
  • a specified range of dates.

9.2.14 The ERMS should be able to provide reports on actions on files and records sorted by user, by workstation and (where technically appropriate) by network address.

9.2.15 The ERMS should allow the reports described in ‎9.2.11 to cover a specified time interval within several days.

For example, showing hourly figures, to allow peaks and troughs of activity to be monitored.

9.2.16 The ERMS must be able to produce a report listing files, sub-files and volumes, for all or part of the classification scheme, structured to reflect the classification scheme.

9.2.17 The ERMS must be able to provide a report on the amount of system storage space currently in use and available.

9.2.18 The ERMS must allow administrative roles to produce reports on the audit trail. These reports must include, at a minimum, reporting based on any selected:
  • class;
  • file;
  • sub-file;
  • volume;
  • record;
  • user;
  • time period.

9.2.19 The ERMS should allow administrative roles to enquire on and produce audit trail reports based on selected:
  • security categories;
  • user groups;
  • other metadata.

9.2.20 The ERMS must be able to report on the outcome of a disposition process listing the classes, files, sub-files, volumes and records successfully disposed of and any failures.

9.2.21 The ERMS must be able to provide reports on the outcome of an export process listing the classes, files, sub-files, volumes and records successfully exported and any failures.

9.2.22 The ERMS must be able to provide administrative roles with reports on disposition activity, including disposition actions that are overdue.

9.2.23 The ERMS should allow administrative roles to restrict users’ access to selected reports.

9.2.24 The ERMS must be able to provide administrative roles with a report on attempted access control and other security policy violations.

This requirement only applies when the ERMS (and/or the operating system) is configured so as to allow an item’s existence to be visible to a user even though the user is not allowed access to it. It is not relevant when the ERMS is configured to hide the existence of an item which cannot be accessed.

9.2.25 Administrative roles should be able to specify the frequency of retention and disposition schedule reporting, the information reported and highlighting exceptions such as disposition overdue.

9.2.26 The ERMS should provide quantitative reports on the kinds of records to be reviewed within a specified period.

9.2.27 The ERMS should support reporting and analysis tools for the management of retention and disposition schedules by an administrative role, including the ability to:
  • list all retention and disposition schedules, sorted by reason or date;
  • list all entities to which a specified retention and disposition schedule is assigned;
  • list the retention and disposition schedule(s) applied to all entities in a class;
  • identify, compare and review retention and disposition schedules (including their contents) across the classification scheme;
  • identify formal contradictions in retention and disposition schedules across the classification scheme.

9.2.28 The ERMS should be able to accumulate statistics of review decisions in a given period and provide tabular and graphical reports on the activity.

9.2.29 The ERMS should be able to accumulate statistics of the imposition and lifting of disposal holds in a given period and provide tabular and graphical reports on the activity.

9.2.30 The ERMS must produce a report detailing any failure during a transfer, export, destruction or deletion. The report must identify any records, aggregations and associated metadata destined for transfer which have generated processing errors, and any entities which are not successfully transferred, exported, destroyed or deleted.

9.2.31 The ERMS must produce a report detailing any failure during an importation. The report must identify any records, aggregations and associated metadata destined for import which have generated processing errors, and any entities which are not successfully imported.

9.2.32 The ERMS should support the import process, by tracking and reporting on its progress and status, including the percentage completed and number of records imported.

9.2.33 The ERMS should provide the ability to sort electronic files selected for transfer into ordered lists according to user-selected metadata elements.

9.2.34 The ERMS should provide the ability to generate user-defined reports to describe electronic files and records that are being exported or transferred.

9.3 9.3 Changing, Deleting and Redacting Records
A basic principle of recordkeeping is that records cannot normally be changed, and (except at the end of their life cycle in the ERMS) files, sub-files, volumes and records cannot normally be destroyed.

This section deals with the requirements for exceptional situations where the content of a declared record may need to be amended, or a record deleted and replaced.

In some situations, administrative roles may need to “delete” records to correct errors to meet legal requirements. An example may arise under data protection legislation, though other scenarios are possible.
The action of deletion may mean one of two things:
  • destruction;
  • retention, accompanied by a notation in the record’s metadata that the record is considered removed from records management control.

In either case, deletion is to be exceptional, and so the ability to delete must be tightly controlled in order to protect the general integrity of the records. In particular, information about deletions must be stored in the audit trail.
If local legislation or regulation imposes different requirements, for example relating to the expunging of personal data (see ISO 12037), this should be addressed in a national chapter zero.

Administrative roles sometimes need to publish, or make available, records containing information which is still sensitive, without revealing the sensitive information. This can result from data protection rules, security considerations, commercial risk, etc. For this reason, administrative roles need to be able to mask the sensitive information, without affecting the underlying record.
The process is referred to here as redaction. When this process is carried out, the result is the original record (unchanged), and a copy of the record which has been masked in some way (the redacted copy, or redaction of the original record). The ERMS stores both the original record and the redaction.

In principle, redaction can apply to any kind of record – text, image, audio, video etc.

Note that deletion and change are also discussed in chapter 5.

9.3.1 The ERMS must allow a configuration option which prevents any record, once captured, from being deleted or moved by any administrative or user role; see also ‎9.3.3.

This requirement does not affect transfer or destruction of records in accordance with a retention and disposition schedule, as described in section 5.3. It is intended for environments in which the deletion of records (as described above) is either unnecessary or not permitted. The alternative to this option is specified in ‎9.3.2.

9.3.2 The ERMS must allow a configuration option, as an alternative to ‎9.3.1, that “deletion” of a record is implemented as destruction of that record, and that relocation of a record results in moving the record; see also ‎9.3.4.

This is not regarded as good practice in records management. It is included here only for situations in which it is considered unavoidable. In most situations, the option specified in ‎9.3.1 should be preferred. This option and the option in ‎9.3.1 are mutually exclusive.

9.3.3 If the option in ‎9.3.1 is selected, the ERMS must behave as follows:
  • If an administrative role “deletes” a record (as in ‎9.3.5) the record’s metadata must be marked accordingly, and the ERMS must hide the content and metadata of the record from all users save potentially for suitably-authorised administrative roles, as if it were deleted; and the ERMS must record this in the audit trail.
  • If an administrative role “re-locates” a record (as in ‎3.4.1), the ERMS must behave exactly as for a deletion but with the addition that a copy (or a pointer, depending on the storage method used) must be inserted automatically at the new location.

This assumes that either no administrative roles would have such authorisation, or else a particularly small number.
9.3.4 If the option in ‎9.3.2 is selected, the ERMS must behave as follows:
  • If an administrative role deletes a record (as in ‎9.3.5) the record must be deleted, along with its metadata except for metadata specified as part of its metadata stub (see ‎5.3.19); and the ERMS must log this in the audit trail.
  • If an administrative role re-locates a record (as in ‎3.4.1), the ERMS must behave exactly as for a deletion but with the addition that the record (or a pointer to it, depending on the storage method used) must be inserted automatically at the new location.

9.3.5 The ERMS must allow administrative roles to delete classes, files, sub-files, volumes and records outside the disposition process.

This is intended for use only in exceptional circumstances as described in this section. It must be read together with ‎9.3.1 and ‎9.3.2.

9.3.6 The ERMS must allow user roles to mark classes, files, sub-files, volumes and records as candidates for deletion.

The administrative role can then decide whether or not to carry out the deletion.

9.3.7 In the event of any deletion as defined above, the ERMS must:
  • log the deletion in the audit trail;
  • produce a report for administrative roles;
  • delete the entire contents of a class, file, sub-file or volume when it is deleted;
  • ensure that no documents are deleted if their deletion would result in a change to another record (for example if a document forms a part of two records, one of which is being deleted);
  • highlight to administrative roles any links from another file, or record to a file, sub-file or volume which is about to be deleted, requesting confirmation before completing the deletion;
  • maintain integrity of the metadata at all times.

In this context the phrase “maintain integrity of the metadata” means to ensure that no metadata in any entity (class, record etc.) refers to an entity that does not exist.

9.3.8 Administrative roles must be able to change any user-entered metadata element.

This functionality is intended to allow administrative roles to correct user errors such as data input errors, and to maintain user and group accesses. Good practice generally will require that users correct their errors whenever possible; this requirement does not prevent users from doing so.

9.3.9 Information about all changes to all metadata elements must be stored in the audit trail.

9.3.10 The ERMS must allow administrative roles to create one or more redaction(s) of a record while retaining the original record.

It may be necessary, in some cases, to provide redactions for several parties in which different parts of the record have been redacted.

9.3.11 The ERMS must allow removal or hiding of sensitive information within a redaction for all record formats required by the organisation.

If the ERMS does not provide these facilities, it must allow for other software packages to integrate with it and do so. It is acceptable for the ERMS to render a record to a different file format to permit the redaction of a copy, provided that the rendition maintains sufficient fidelity.

It is essential that, when this feature or any other redaction features are used, none of the removed or hidden information can ever be retrieved from the redaction, whether on screen, when printed, played back or in any other form of presentation. This is regardless of the use of any presentation features such as rotation, zooming or any other manipulation including opening the redaction in a different software package.

9.3.12 When a redaction is created, the ERMS must store automatically its creation in the metadata of the redaction and the record, including date, time and creator.

9.3.13 When a redaction is created, the ERMS must require the user creating it to enter a reason, and must store that reason in the metadata of the redaction and the record.

9.3.14 Upon creation of a redaction the ERMS should automatically declare redactions as records, classifying them in the same aggregation as the original record and prompting the creator of the redaction for:
  • a reason (see ‎9.3.13);
  • security category (where applicable);
  • optionally, an aggregation into which a copy of the redaction will be declared.

9.3.15 Upon creation of a redaction the ERMS should allow the copying of metadata elements to the redaction.

9.3.16 Subject to access control rights the ERMS should enable amendment of selected metadata values, for example title.

9.3.17 The ERMS should store a cross reference to a redaction in the same class, file, sub-file or volume as the original record, even if that class, file, sub-file or volume is closed.

This is in addition to the requirement to file a copy, in ‎9.3.14, to allow for cross referencing even in the same file, as the original and redaction may be separated by large numbers of records in the file.

9.3.18 When a record is retrieved the ERMS must show, or allow the user to see, the existence of all redactions made from that record and, subject to access and security controls, make them available for retrieval.

9.3.19 When a redaction is retrieved the ERMS must show, or allow the user to see, the existence of the original record and, subject to access and security controls, make it available for retrieval.

9.3.20 The ERMS must store in the audit trail any change made as a result of any requirement in this section.


The wiki text is available under the Creative Commons Attribution License agreement.

Blog email facebook linkedin Rss Twitter Youtube

Copyright © AIIM 2013 Privacy Policy