Overview
This guide provides a checklist against which an existing or new business system may be assessed to determine:
- whether the business the system supports is subject to any recordkeeping requirements
- how well the system is currently functioning as a recordkeeping system
- what action may be required to enable the system to meet recordkeeping requirements.
The checklist offers a basic recordkeeping functionality assessment. When planning to procure or implement new systems, or when prioritising further developments of existing business systems, organisations should consider:
- the value of the records that are or will be created in and/or managed by the business system
- the risks associated with the business that the system supports
- inherent information risks
- any recordkeeping requirements that relate specifically to the business being conducted
- the organisational context in which the business system operates (when making decisions about any remedial work that may be required).
Why assess business systems?
In many organisations, business systems are or have been implemented without full consideration of relevant recordkeeping requirements. As a consequence, the business is unable to assure that records created and stored in these business systems are authentic, reliable, trustworthy, complete, meaningful, useable and available whenever they are required.
By assessing business systems against recordkeeping requirements, organisations can:
- operate efficiently and effectively with the assurance that business systems provide sufficient and appropriate evidence to support business outcomes
- identify and manage the risks associated with the loss of records and information assets
- recognise gaps in recordkeeping functionality and help make decisions on potential strategies for closing or addressing those gaps.
Benefits of using this checklist
Using this checklist will help organisations to:
- identify recordkeeping requirements relating to the business outcome/s which the system supports or delivers
- identify any statutory requirements which apply to the records or information in your new system or service offering
- determine whether the proposed or existing business system has sufficient recordkeeping functionality
- identify critical controls, inefficiencies and issues with the business system
- provide tangible evidence to support proposals for remedial work or the implementation of potential solutions, controls, strategies or approaches.
We recommend assessing the recordkeeping functionality of new business systems from the planning to procurement phase to during the system design and project implementation phase. Doing the assessment upfront helps define technical specifications needed to ensure that the organisation’s recordkeeping requirements are addressed and considered.
The assessment can also be undertaken for existing business systems, specifically during systems changes or upgrades to help identify issues and gaps in recordkeeping functionality. Doing the assessment provides a foundation for making decisions on strategies or potential solutions.
Back to topPrioritising your assessment according to level of risk
Undertaking an assessment of all existing or proposed business systems in an organisation can take up a lot of time and resources. We recommend public offices take a risk-based approach in determining which business systems should be prioritised for assessment.
The order in which systems are assessed should be determined based on the:
- risks associated with the business supported by the system
- value of the records that are or will be created in and/or managed by the business system
- the risks associated with records that are or will be created in and managed by the business system
We recommend organisations focus on business systems supporting core functions, strategic business areas, high risk or public facing business processes.
For more information, see “Identifying and managing high value and high risk records and information.”
Back to topChecklist
This checklist is in two parts:
- Determine whether the system is subject to any recordkeeping requirements
- Assess the system’s existing recordkeeping functionality
1. Determine whether the system is subject to any recordkeeping requirements
This part of the checklist has two purposes:
- It will identify whether an existing or proposed system has recordkeeping requirements and therefore requires further assessment. Some systems may contain only duplicate information and require no further action.
- It will assist in prioritising systems for assessment and determining the extent to which remedial work and/or connection with a dedicated recordkeeping system will be required to ensure records are made and kept of the business it supports.
Answering ‘Yes’ to any of the questions below warrants an assessment of whether the system have recordkeeping requirements.
| Requirement | Standard on records management minimum compliance requirements | Explanation | |
|---|---|---|---|
| 1 | Does the business system hold unique evidence of official business? (i.e. not published or duplicate information) | 2.1 |
The main purpose of implementing business systems is to support a business activity. Determining whether the business system holds or will hold unique information upfront ensures that resources (time, effort, money) are allocated accordingly. If the system contains duplicate information that has already been captured in an official recordkeeping system or which does not relate to the official business of the organisation, there is no need for the recordkeeping assessment to continue. |
| 2 | Are there any regulatory or business requirements to make and keep records of the business the system supports? | 2.1 |
Regulatory requirements are imposed upon your organisation by laws, regulations, whole-of-government policies, directives, standards or similar instruments. Regulatory requirements will be most common for business activities or operations that are tightly controlled or monitored. Business requirements are internal requirements that result from the activities and business processes of your organisation. They specify what information is necessary for the organisation to carry out its operational work and responsibilities. |
| 3 | Does or will the business system replace a previous system or systems? If yes, were records kept of the business supported by the previous system? | 2.1, 2.3, 2.4, & 2.6 |
If the answer to this question is ‘yes’, it is likely that this system will need to keep the same types of records. ‘Previous systems’ include paper-based systems for keeping records. |
| 4 | Does or will the business system support the core function/s or high risk areas of the organisation? | 2.2, 2.3, 3.4 |
We recommend organisations focus on business systems supporting core functions and high risk business areas. These areas of the business require trustworthy, reliable, usable, interoperable and secure business systems. If the answer to this question is ‘yes’, please ensure appropriate mechanisms are in place for quality assurance, and that security measures and business continuity strategies and plans are developed for this system. For more information, see “Identifying and managing high value and high risk records and information” and “Identifying information risks that might be impacting on high risk business.” |
| 5 | Does or will the business system support the operational needs of the organisation (e.g. administrative/corporate functions such as HR, Finance)? | 2.1, 2.2, 2.3 |
Many high value records and information are generated by common organisational functions. The value of records is dependent on a number of factors such as their currency and usefulness. If the answer to this question is ‘yes’, specify the functions and check the retention requirements. See GA28 for more information. |
| 6 | Does the business system relate to a business activity for which there is an identifiable disposal class in a retention and disposal authority? | 2.1, 2.5, 3.6 |
Retention and disposal authorities provides authorisation for the disposal of State records and for deciding which records will be retained as State archives. If the answer to this question is ‘yes’, check the retention requirements and consider the expected life of the business system in your assessment. If retention periods are longer than the expected life of the business system, take into account:
|
2. Assess the system’s existing recordkeeping functionality
This section contains functional requirements for recordkeeping which can be used to assess the extent to which the system operates as a recordkeeping system, and where there are gaps.
This section is based on the International Council on Archives’ ICA-Req Module 3: Guidelines and Functional Requirements for Records in Business Systems (ISO 16175-3:2010).
The functional requirements are divided into four broad areas:
- creating records in context – it is necessary that business systems reflect what the records were at any point of time to provide evidence of the business.
- managing and maintaining records – it is necessary that records managed and maintained in these business systems are reliable, authentic, trustworthy, accurate, useful and available whenever they are required.
- migration and interoperability – requirements in this area are critical during decommissioning; or when there is a need to share records with another agency for collaboration or as part of the agency’s open data release management plan.
- retention and disposal of records as required – requirements in this area are critical when there is a need to keep records for longer than the expected life of the business system. In most cases, compliance may still be adequately addressed by having business process rules on retention and disposal of records created or received by the business system.
Each requirement below is mapped with the Standard on records management minimum compliance requirements. It also includes an explanation of the requirement and actions to take and consider.
| Functional Requirement | Standard on records management minimum compliance requirements | Explanation | Action | |
|---|---|---|---|---|
Creating records in context |
||||
| 7 |
Does or will the business system capture records created or received, regardless of format and technical characteristics? Capturing means that:
|
3.1 |
The business system needs to be able to save records entered by the user. In some cases records are captured automatically. The business system should be able to keep a fixed and complete version of each record that is defined, whether in documentary form or a collection of data representing a transaction. Some business systems are designed to be current with minimal redundancy of data. If a business system that is being assessed for its recordkeeping capabilities allows for the continual updating of information without keeping a record where required the option of exporting records to an external recordkeeping system should be employed. |
If yes, document how this requirement is supported by the business system. If no, flag this as a gap and explore options for addressing this requirement. Take a risk-based approach in deciding which option is the most appropriate way to proceed. |
| 8 | Does or will the business system uniquely identify each record and store this identification as metadata? | 3.2 and 3.3 | The system should be capable of uniquely identifying each record as defined, for example with a system generated reference, a document number or other identifier. |
If yes, document how this requirement is supported by the business system. If no, flag this as a gap and explore options for addressing this requirement. Take a risk-based approach in deciding which option is the most appropriate way to proceed. |
| 9 | Does or will the business system capture and show core recordkeeping metadata? | 3.2 and 3.3 |
The system should be capable of capturing and managing core recordkeeping metadata. Much of the metadata in business systems is present in the system, imported from another system or is generated as a natural part of the operation of the system. Some may be added by system users. Metadata may be applied to individual records or aggregations of records. It can also be applied to entire systems (e.g. system documentation can provide the required information about the business context of records in the system). For more information please see our guidance “Minimum requirements for metadata for authoritative records and information.” |
If yes, include in your system documentation information describing the content and context of records, its structure, relationship with other records, and business actions or events the system supports or will support. If no, flag this as a gap and explore options for addressing this requirement. Take a risk-based approach in deciding which option is the most appropriate way to proceed. |
| 10 | Does or will the business system support the creation of additional metadata elements (database fields) detailed in relevant standards or any other metadata required to support the organisation’s business requirements? | 2.1, 2.3 and 3.1 |
Metadata in digital systems is abundant and permeating. Organisations should identify what metadata in business systems is necessary to meet specific requirements and/or to support organisational business requirements. More information about metadata can be found in “Metadata for records and information.” |
If yes, document how this requirement is supported by the business system. If no, assess whether there is a need to create additional metadata elements. If there is a need, flag this as a gap and explore options for addressing this requirement. Take a risk-based approach in deciding which option is the most appropriate way to proceed. |
| 11 | Does or will the business system store metadata over time, regardless of whether the related record has been archived, transferred, deleted or destroyed? | 3.1, 3.2 and 3.3 |
The system should be able to maintain a metadata profile over time – maintaining links to the record and accumulating process metadata for the record as events occur. The metadata should remain linked to the record even if the records are migrated out of the original system. Mappings can assist with ensuring that metadata remains linked to records for as long as required, including through and beyond system migrations. |
If yes, document how this requirement is supported by the business system. If no, assess whether it is possible to export any metadata that must be retained beyond the life of a record to account for what was destroyed and when to a separate system. Take a risk-based approach in deciding how to proceed. |
| 12 | Does or will the business system allow or restrict “edit” rights on record metadata? | 3.4 | Based on defined access rules and user identification the system should be able to permit or limit access to records or groups of records. |
If yes, document how this requirement is supported by the business system. If no, flag this as a gap and explore options for addressing this requirement. Take a risk-based approach in deciding which option is the most appropriate way to proceed. |
Managing and maintaining records |
||||
| 13 | Does or will the business system prevent the deletion of records and associated metadata at all times, except when deletion or destruction takes place as part of an authorised disposal activity? | 2.5, 3.2, 3.4 and 3.7 |
Inclusion of this requirement ensures that unauthorised and accidental deletion of records in the business system is prevented. It also ensures the integrity of the business system. Most importantly, the business system should not permit the removal or deletion of the metadata specified in requirement #9. The system should be able to maintain a metadata profile over time - maintaining links to the record and accumulating process metadata for the record as events occur. The metadata should remain linked to the record even if the records are migrated out of the original system. |
If yes, document how this requirement is supported by the business system. If no, flag this as a gap and explore options for addressing this requirement. Take a risk-based approach in deciding which option is the most appropriate way to proceed. |
| 14 | Does or will the business system generate, log and show all actions carried out on the record or in the system? | 3.1, 3.2 and 3.3 |
This requirement ensures that actions are accountable and transparent. The business system should have a mechanism to log and show events such as additions, alterations and deletions carried out on the record, date of the action and by whom. In addition from an information security perspective, event logging increases the security of a system by improving the chances of detecting malicious behaviour. |
If yes, document how this requirement is supported by the business system. If no, flag this as a gap and explore options for addressing this requirement. Take a risk-based approach in deciding which option is the most appropriate way to proceed. |
| 15 | Does or will the business system set and manage access and security permissions? | 3.2 and 3.5 | This requirement addresses the need for business systems to provide access to authorised users for as long as they are required to meet accountability, legislative and business requirements. |
If yes, determine the information security classification of the records in the business system to ensure that appropriate security controls and permissions are in place. Check the NSW Government Digital Information Security Policy and NSW Government Information Classification, Labelling and Handling Guidelines for more information. If no, identify what processes are in place or will be needed to ensure that only authorised users have access to the system. |
Migration and interoperability |
||||
| 16 | Does or will the business system export all or select records (including associated metadata and system logs) regardless of format, without loss of content or metadata? | 2.4, 2.5, 2.6, 3.2, 3.3 and 3.4 |
Most business systems have the ability to export records to another system or to an external medium, e.g. a disk or hard drive. However, this requirement is also about the maintenance or preservation of the quality and integrity of the records exported. We recommend that this requirement be looked at closely during implementation to ensure that quality control mechanisms are in place to ensure that when needed, records and associated metadata can be exported with nil or minimal loss (e.g if the system is decommissioned or the records are required as State archives). To do this, agencies have to define and set their quality criteria for exported records and associated metadata. Some change to look and feel of the records may be permitted. If the organisation has a need to share the data as part of open data or other initiatives, the capacity to export manipulable data is important. |
If yes, document the export process or function. If no, assess whether this functionality is required (e.g. records of long term value will likely need to be exported from the system when the system is decommissioned). Take a risk-based approach in deciding which option is the most appropriate way to proceed. |
| 17 | Does or will the business system produce a report detailing success or any failure during the export process (including identification of those records which generated errors or were not successfully exported)? | 2.6 |
This requirement enables verification of the success or failure of the export process. In addition, exceptions identified can then be resolved and documented. Also, this requirement is useful for quality assurance purposes. |
If yes, document how this requirement is supported by the business system. If no, flag this as a gap and explore options for addressing this requirement. Take a risk-based approach in deciding which option is the most appropriate way to proceed. |
Retention and disposal of records as required |
||||
| 18 | Does or will the business system support controlled disposal or deletion of records legally authorised for disposal? | 2.1, 2.5, 3.6 and 3.7 |
Controlled disposal or deletion of records in business systems means:
|
If yes, document how this requirement is supported by the business system. If no, this requirement may still be adequately addressed by manually mapping the appropriate disposal class/es and having a business process and policy / rules on disposal of records created or received by the business system. |
| 19 | Does or will the business system produce reports relating to deletion of records and associated metadata? | 3.6 and 3.7 |
The deletion of any records in the business system must be captured or recorded in the audit log. The business system must automatically capture the following:
|
If yes, document how this requirement is supported by the business system. If no, this requirement may still be adequately addressed by having a business process and rules on disposal of records in the business system. |
Determine strategies to bridge any gaps in recordkeeping capability
Having carried out an assessment of the system against the requirements listed above, you should have information on where there are gaps in its operation in terms of recordkeeping.
Strategies for bridging those gaps include:
- changing the configuration of the system, e.g. by turning on additional functionalities or changing the data schema
- integrating the business system with an external recordkeeping system such as an EDRMS
- exporting records and saving the exported records into an external recordkeeping system such as an EDRMS
- business process re-engineering or introduction of new work processes
- implementing policies, procedures, business rules or guidelines to ensure the recordkeeping requirements are met.
Monitoring business systems recordkeeping strategies over time
Systems and requirements change as a normal part of business, and so recordkeeping strategies put in place for records of business systems should be routinely monitored to ensure they are continuing to meet the organisation’s needs. Times when these strategies may be at risk include administrative change, process change or system upgrades or migrations.
Published 2005. Revised 2010/ February 2015/ December 2017/ July 2018
Back to top