Checklist for assessing business systems
- Why assess business systems?
- Prioritising your assessment according to level of risk
- Is the business system the best place for all the records?
- Spreadsheet tool for documenting business systems assessments
- Monitoring business systems recordkeeping strategies over time
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 only offers a basic assessment. Organisations should also consider requirements for recordkeeping and information that relate specifically to the business being conducted and also consider the context in which the system operates when making decisions about any remedial work that may be required. State Records’ Strategies for documenting government business: the ‘DIRKS’ Manual provides a useful methodology for considering all these factors when evaluating and improving systems for recordkeeping.
For this guide, the following definitions apply:
Business systems are automated systems that create or manage data about an organisation’s activities. They include applications whose primary purpose is to facilitate transactions between an organisational unit and its customers – for example, an e-commerce system, client-relationship management system, purpose-built or customised database, or finance or human resources systems. Business systems are typified by containing dynamic data that is commonly subject to constant updates (timely), able to be transformed (manipulable) and holds current data (non-redundant). (International Council on Archives, Principles and Functional Requirements for Records in Electronic Office Environments, Module 3:Guidelines and Functional Requirements for Records in Business Systems (2008))
A digital record is digital information, captured at a specific point in time that is kept as evidence of business activity. Digital records means 'born digital' records such as emails, web pages, digital photographs, digital audio files, GIS files or database records, as well as scanned versions of paper records that have been digitised in business processes.
Digital recordkeeping system:
A system that captures, maintains and provides access to digital records over time. A digital recordkeeping system can be:
- a business system with recordkeeping functionality, or
- a business system linked with a dedicated records management / information asset management system, or
- a dedicated records management / information asset management system.
In many organisations, business systems that conduct significant business are not able to perform as recordkeeping systems. They have often been introduced without full consideration of recordkeeping issues, and as a consequence do not manage, preserve and make accessible necessary evidence of business operations.
Through not making and keeping business systems records, organisations can:
- place themselves at significant risk
- incur unnecessary expenditure, and
- deny themselves access to significant, reliable organisational information.
Therefore it is worth dedicating time and resources to ensuring that where they are required to do so, business systems are also meeting recordkeeping requirements.
Public offices should prioritise the assessment of business systems based on the level of risk associated with poor recordkeeping for the business they support.
The order in which systems are assessed should be determined based on an assessment of the risk associated with the business concerned and recordkeeping for that business. The aim is to assist public offices to:
- define those digital records that are needed to support high risk business processes using existing ICT systems
- ensure that existing ICT systems supporting these high risk business processes have appropriate functionality and metadata
Criteria for identifying your organisation’s high risk business processes
Identifying high risk business processes will depend on the nature of your organisation’s business. High risk business processes are likely to involve one or more of the following:
- regular, routine or direct contact with individuals (for example, a regulatory, enforcement, health or welfare activity)
- impact on citizens' rights, entitlements and wellbeing
- the creation of policy for offices with impact on individuals and communities
- the making of legal agreements on behalf of NSW Government
- the making of laws
- the determining of policy on government functions and activities
- a significant investment by Government
- an investigation by the ICAC, Ombudsman or other watchdog agency with recordkeeping issues relating to the process being identified
- processes that are open to corruption or the potential of corrupt behaviour
- a significant contribution to the economic and social development and management of NSW either directly or indirectly
- a significant contribution to the economy, the management of natural resources, the protection and security of the state, and/or infrastructure of NSW
- a major program of international/national/state significance
- records that are included in the organisation’s vital records register
- significant records relating to Aboriginal people and heritage
- profiling in the media for matters that indicate possible recordkeeping failures
- the production of State archives.
A welfare organisation conducted an inventory of its business systems with a view to addressing recordkeeping for the high risk ones first. It determined that the system used to record the details of client contact was a high risk system while the purchasing system used for office supplies was low risk.
An infrastructure organisation determined that the system used to manage tenders from contractors for work worth millions of dollars was high risk based on the fact that there had been cases of fraud in the past.
This checklist is in three parts:
- Determine whether the system is subject to any recordkeeping requirements
- Assess the system’s existing recordkeeping functionality
- Determine strategies to bridge any gaps in recordkeeping capability
1. Determine whether the system is subject to any recordkeeping requirements
This part of the checklist is designed to help you to decide whether a business system will require remedial work and/or connection with a dedicated recordkeeping system to ensure records are made and kept of the business it supports.
|1||Is the information kept in this system unique evidence of official business? (i.e. not published or duplicate information)||If the information in the system is required by officers and agencies to demonstrate that they performed their work appropriately then there is a need for a recordkeeping assessment.
If the system contains duplicate information that has already been captured in an official recordkeeping system or which does not relate to official business of the organisation, there is no need for the recordkeeping assessment to continue.
|The whole of government e-Recruitment system is being used by many NSW government agencies as a key component for managing information and records of recruitment processes.|
|2||Does the system relate to a business activity for which there is an identifiable disposal class in a General Retention & Disposal Authority or your organisation's Functional Retention & Disposal Authority?||If a there is a disposal class for records of the business the system supports in an authorised disposal authority which indicates a retention period, that is in effect a recordkeeping requirement.||There are a range of requirements for the recruitment process ranging from relatively short periods (2 years after recruitment has been finalised) to long term retention (7 years after employment ceases) or retention as State archives (for notable employees).|
|3||Are there any legislative or business requirements to make and keep records of the business the system supports? Are these records already being created and kept in another system?||See Step C of the DIRKS Manual, ‘Identification of recordkeeping requirements’ for more guidance on how to identify requirements.
List recordkeeping requirements on a separate sheet. See the ‘DIRKS’ Manual for information on using risk assessment to determine the final set of requirements.
|Recruitment attracts a number of legislative and business requirements for records to be kept. There are short term business requirements to retain records of recruitment to help manage the interview process. There are also regulatory requirements associated with screening processes for certain jobs, such as criminal history or working with children checks.|
|4||Did this system replace a previous system or systems? If yes, were records kept of the business supported by the previous system?||If the answer is yes to this question, it is likely that this system will need to keep the same types of records.||For many agencies, e-Recruitment replaces a paper based system of documenting recruitment either manually or using an EDRMS.
|5||What are the records that are defined for the business supported by the system?||A public office should define the digital State records that it will make and keep. It notes that the level of detail used by the public office to define the digital records to be made and kept should be adequate for implementation purposes and based on an assessment of the risk associated with the records and the business they document.||For example, in the recruitment process; Application including resume and references, evidence of education qualifications and personal particulars, offer, acceptance (not an exhaustive list).|
In the example of the recruitment system above, there are clear recordkeeping requirements warranting an assessment of whether the system can meet all recordkeeping requirements on its own.
2. Assess the system’s existing recordkeeping functionality
The following criteria can be used to assess the extent to which the system operates as a recordkeeping system, and where there are gaps.
Against each requirement below is an explanation of the requirement and an example of how the requirement is met with real systems; whole of government e-Recruitment system, or a property management application used by a city council.
|1||Can the system capture read only versions of the digital records you have defined?||The 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.
The system should be able to maintain relationships between all components where the record is made up of more than one component.
The system should have the capacity to capture externally generated records in addition to any that are created within the system if these have been defined as required records of the business supported by the system.
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.
|In a property management system used by a city council, all communications between users are recorded and viewable, as are any uploaded documents such as reports. It is possible to retrieve all these records for a property by using the property ID. Once added to the system these records cannot be altered.
|2||Can the system retrieve and present the defined digital records in human readable form?||The system should be able to store and retrieve the defined records along with their associated metadata and including all components of the records, for example attachments to messages along with messages.||It is possible when retrieving records such as candidate applications in the whole of government e-Recruitment system to view not only the required information on the candidate but also all linked documents appropriate for their specific applications (for example resumes) and the audit log for actions on the application. These elements are all linked using a tab system.|
|3||If required, can the system restrict or permit access to the defined records by specified individuals or groups?||Based on defined access rules and user identification the system should be able to permit or limit access to records or groups of records.||Access to information in many business applications is managed via user permissions linked to the users’ logins.
If the business being conducted is highly sensitive or confidential, consideration may be given to exporting these records to an external recordkeeping with more sophisticated access controls.
|4||Minimum required recordkeeping metadata||
The system should be capable of capturing and managing core recordkeeping metadata.
This may mean the ability to:
Metadata may be applied to individual records or aggregations of records up to whole systems.
|Much of the metadata in business systems is preset 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. For example, in the e-Recruitment system, metadata such as an identifier for each requisition (position being advertised) or candidate registered is automatically generated by the system, while other metadata in each candidate ‘file’ is pulled in from the jobs.nsw website or another external recruitment website.
|4.1||Point of capture metadata||The system should be capable of generating / capturing / recording certain metadata with the creation / capture of each record (see 4.1.1 – 4.1.7).||When a communication is sent between officers and contractors using a property management system at a city council, each communication is automatically registered in the system with certain information, including the senders and recipients, date sent and a unique identification for the communication.|
|4.1.1||Unique identifier||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. Each requisition and candidate file created in the e-recruitment system has an automatically generated reference number.||
Each communication or uploaded document in the property management system has a unique identifier, as does each property. In this way, the IDs are similar to IDs applied at document / file level in an EDRMS.
|4.1.2||Title||The system should be capable of capturing and retaining information indicating what each record is – for example, a subject line from an email, a system generated report name or a manually entered document title.||In the property management system communications are automatically labelled with the subject line. In the e-Recruitment system each candidate file inherits the candidate’s name from jobs.nsw or another external recruitment website.|
|4.1.3||Date of creation||The system should be capable of capturing and retaining the date of each record’s creation.||The date the candidate file or requisition was created in the e-Recruitment system is logged in the ‘tracking’ information.
|4.1.4||Who/what created the record||The system should be capable of capturing and retaining information on who or what created the record – for example a name, a user ID or a system ID. In some cases this metadata might be captured from an external identity management system.||Metadata for requisition files in the e-Recruitment system shows the name of the officers who created them. Metadata for the candidate files shows whether they weregenerated from jobs.nsw or another recruitment site.|
|4.1.5||The business function/process it relates to||The system should be capable of capturing and retaining information on the business function or process the record relates to. This may be met by information which is also used as the ‘Title’, or it may be met at a higher level of aggregation; for example at the level of a group of records or all records in the system (for example all records generated by the Finance system are tagged accordingly).||Records retained within the e-Recruitment system are clearly identified as recruitment records. Any records exported and stored in external systems would need to be classified as recruitment records.|
|4.1.6||The creating application||The system should be capable of capturing and retaining information indicating the application used to create the record. In many business systems this information will be automatically generated, and will apply across aggregates of records. It may be found in audit trail information.||Reports exported from business systems such as the e-Recruitment or property management systems for capture into external recordkeeping systems indicate the relevant application’s names and version numbers.|
|4.1.7||Record type (e.g. letter / memo / report / contract / fax)||Is the system capable of capturing and retaining metadata which indicates the record’s type or form? In business systems there may only be a limited number of types – for example reports and transactional records. It is possible to apply this metadata via another element such as Title and/or at an aggregate level (e.g. across the entire system).||In the e-Recruitment system certain records have standard names eg offer letters that are stored within the offer model. Other more generic records are simply registered as letters, emails etc.
Similarly, the council has established a set of standard names for records commonly registered in the property management system, such as contract, invoice or purchase order.
|4.2||Process metadata||The system should be capable of capturing and retaining metadata which records certain actions performed on the records (see 4.2.1-4.2.4)||In many business systems process metadata is kept in audit logs, showing which officers added, accessed or performed other actions on records in the system.|
|4.2.1||Registration into a recordkeeping system||The system should be capable of capturing and retaining metadata which records the date the record was registered (may be the same as the date of its creation particularly if the record is being retained within the business system), and an identification of who/what registered the record. May be found in audit trail information. A contacts database used by State Records NSW automatically generates a copy of any email messages sent to contacts, and sends it to a specified action officer. The action officer is then responsible for saving the message into a recordkeeping system. In this example the date of registration of the record will be the date the action officer adds it to the recordkeeping system.||In the e-Recruitment system, communications between recruiters and candidates are saved to the system and automatically made ‘read only’. The date that this occurs is the registration date in this example. Requisitions (details of the job advertised) are created and maintained in the e-Recruitment system and then on completion of the action are exported in the form of a report for capture into an external recordkeeping system. The date of this capture is recorded with the report in the external system.
|4.2.2||Changed access rules||The system should be capable of capturing and retaining metadata which records the date the access rule was changed, what the new rule is and an identification of who/what made the change. May be found in audit trail information for aggregates of records.||Access permissions are managed in the e-Recruitment system via user logins. Any changes to these are recorded in the audit trail in the administration component of the system.|
|4.2.3||Transfer of control – for example records being transferred to a different agency in the event of administrative change||The system should be capable of capturing and retaining metadata which records the date the record was transferred, an identification of who/what undertook the transfer and the name of the receiving organisation.
An authorisation reference for the transfer (e.g. FA234 2.4.5; GA27 1.2.3; By court order; NAP etc.) should also be recorded.
This metadata is very likely to be applied to a group of records rather than to individual records.
This type of metadata is likely to be generated at an aggregate level for groups of records being transferred as part of administrative change. For example when, on the conclusion of a building project, the records kept in an online project management application are transferred to the responsible agency, they are in a folder on a disk that is labelled with the date the records were exported, and the details of the authorisation for their transfer. This information should be captured into the agency’s recordkeeping systems along with the records.
|4.2.4||Destruction||The system should be capable of capturing and retaining metadata which records the date of the destruction, an identification of who/what undertook the destruction and an authorisation reference (e.g. FA234 2.4.5; GA27 1.2.3; By court order; NAP etc.).||The deletion of any information in the property management system is recorded in the audit log.|
|5||Persistence of metadata||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.|
|6||Disposal of metadata||The system should not permit the removal or deletion of the metadata specified in section 4.||Metadata in audit logs and other places such as titles of candidate files cannot be deleted by users.|
|7||Export||The system should be able to export the defined digital records and their associated metadata to another system or to an external medium e.g. a disk or hard drive.
The export process should not degrade core characteristics such as record relationships, data quality or metadata.
Some change to look and feel of the records may be permitted (see State Records’ Policy on digital records preservation).
Mappings help with indicating which metadata elements are required to be exported with records.
In the e-Recruitment system, selection Reports are manually completed and attached to the requisitions and are then saved externally in the same format.
3. 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. Options for bridging those gaps may derive from technology, policy/ procedures, user training and other strategies. One of the most commonly adopted strategies where a business system is not capable of keeping records is to link it with an external recordkeeping system, such as an EDRMS.
In the examples provided above relating to the use of the e-Recruitment system to create and keep recruitment records, there are certain recordkeeping requirements which can only be met by exporting reports and other information from the system to a dedicated external recordkeeping system such as the records of the requisitions, or job descriptions, which the system cannot make read only and retain. Therefore this class of records is exported to an external recordkeeping system ar the completion of each recruitment action, such as an EDRMS.
Sources which may be useful for bridging recordkeeping gaps in business systems include:
- State Records, Strategies for documenting government business: the ‘DIRKS’ Manual, Step E: Identification of strategies for recordkeeping
- International Council on Archives, Principles and Functional Requirements for Records in Electronic Office Environments, Module 3: Guidelines and Functional Requirements for Records in Business Systems (2008).
Where records are identified as having long term or archival retention requirements, consideration should be given to whether export from a business system to an external dedicated recordkeeping system is in fact a better option than retaining the records in the business system once the operational need for the information has ceased.
Over time records in business systems can be subject to a range of risks such as alterations, data cleansing, de-commissioning, upgrades or migrations of the system which can affect the data contained in the system., In addition, records in business systems can suffer from a lack of visibility and/or control by the organisation’s records management program. Records captured into dedicated recordkeeping systems such as an EDRMS can be managed using more sophisticated functionality and are at a lesser risk of loss or damage as a result of technology obsolescence and other threats.
In the case of the e-Recruitment system, requirements to retain short term value records such as the applications of unsuccessful candidates can be met by the functionality available in the e-Recruitment system. However while the system has basic recordkeeping capability, it is deemed not to be the best solution for management of long term records such as the applications of successful applicants. Using risk assessment, the decision is therefore taken to export these records to an external recordkeeping system. This also has the advantage of more closely linking these records with the staff member’s other personnel records.
State Records has produced a simple spreadsheet tool that public offices can use to document:
- digital records that have been defined for a particular business system
- their assessment of the business system in line with the checklist above.
Business system assessment worksheet (MS Excel, 35 KB)
The documentation kept in this spreadsheet can be used as a reference for any improvements or remedial action on the business system.
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.