Business System Recordkeeping Assessment - Digital Recordkeeping Compliance

Transcription

1 Introduction The following assessment will assist to identify whether the system complies with State Records Authority of NSW Standards on Records Management The broad Principles of this standard are as follows; 1. Principle 1: Organisations take responsibility for records and information management 2. Principle 2: Records and information management support business 3. Principle 3: Records and information are well managed Purpose: 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 For further information go to: This information will enable system owners 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. Part 5 Risk Assessment Checklist for Storing Records Outside NSW with Cloud Service Providers, will need to be completed for systems that will utilise a service provider that is outside the State of NSW. This checklist will For further information go to Please forwards all completed assessments to records@newcastel.edu.au D10/20767 Page 1 of 14

2 Instructions The checklist is in five parts; 1. System identification details 2. Determine whether the system is subject to any recordkeeping requirements 3. Assess the system s existing recordkeeping functionality 4. Determine strategies to bridge any gaps in recordkeeping capability 5. Risk Assessment Checklist for Storing Records Outside NSW with Cloud Service Providers Part 1: System identification details System being assessed Date: Summarise the business function the system undertakes/supports Business Process Owner (Who owns the data?) Name: Position: Phone: Business Unit/Faculty: System Administrator Name: Details of person completing form Name: Phone: Position and Faculty/Business Unit D10/20767 Page 2 of 14

3 Part 2: 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. Requirement Explanation Response a) 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. - If please complete part 3 No - If No there is no requirement to complete part 3 b) 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? c) Are there any legislative or business requirements to make and keep records of the business the system supports? d) Are these records already being created and kept in another system? If 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. (refer to State Records NSW disposal authorities below) GDA 23 University Records Disposal Authority GA28 Administrative Records Disposal Authority 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. - If please complete part 3 No - If No there is no requirement to complete part 3 - If please complete part 3 No - If No there is no requirement to complete part 3 - If there is no requirement to complete part 3 No - If No please complete part 3 D10/20767 Page 3 of 14

4 e) 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. No If please complete part 3 Part 3. Assess the system s recordkeeping functionality Complete all questions to identify potential gaps in system compliance. Based on your responses enter the following information in the Comment/Action Column : YES Explain how the system complies with the requirement Partial (requirement can be met with configuration / procedure changes). Explain how the gap can be remedied NO (where the system is not capable): The system may need to be re-developed/enhanced, or another system used for recordkeeping purposes such as TRIM. Requirement Response Comments 3.1 Can the system capture read-only versions of digital records? 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. Partial - can be done with changes to D10/20767 Page 4 of 14

5 3.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. 3.3 Can the system restrict read/write access to digital records to specific individuals or groups as required? Based on defined access rules and user identification the system should be able to permit or limit access to records or groups of records. Minimum Required recordkeeping metadata The system should be able to capture and manage core recordkeeping metadata. This may mean the ability to: automatically capture metadata acquired directly from an authoring application or operating system where the record is received by the business system rather than created by the business system, and/or automatically capture metadata acquired from an EDRMS or IAMS system, where records are retained in the business system but managed by an IAMS, and/or automatically capture metadata generated by the business system itself, such as a date, reference number or user ID, and/or permit the manual entry of metadata by an operator. Metadata may be applied to individual records or aggregations of records up to whole systems Point of Capture Metadata Requirement Response Additional Detail 3.4 Does the system create a unique identifier for records? (e.g. URI uniform resource indicator, or Primary Key) 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. D10/20767 Page 5 of 14

6 3.5 Does the system capture a Title or Subject for each record? The system should be capable of capturing and retaining information indicating what each record is for example, a subject line from an , a system generated report name or a manually entered document title. 3.6 Does the system capture the date each record was created? The system should be capable of capturing and retaining the date of each record s creation. 3.7 Does the system identify who or what process 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. 3.8 Does the system identify the business function and/or process that the record 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). 3.9 Does the system identify the application used to create the record? 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; capable of this capable of this. capable D10/20767 Page 6 of 14

7 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) Does the system identify the format or record type? 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). of this. capable of this. Process metadata Requirements Response Additional Detail 3.11 Does the system capture the date each record was first registered into the 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 3.12 Does the system identify who or what process registered the record? No the system is not capable to do this Changed access rules Requirement Response Additional Detail 3.13 Does the system capture the date access rights on the record were applied and/or changed? D10/20767 Page 7 of 14

8 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 Does the system identify who or what process changed an access rule? 3.15 Does the system identify what access rule was applied or changed? Transfer of control Requirement Response Additional Detail 3.16 Does the system identify that a record was transferred from UoN control in the event of administrative change? The system should be capable of capturing and retaining metadata about the date the record was transferred Does the system capture the date a record was transferred from UoN control? The system should be capable of capturing and retaining metadata about the date the record was transferred. D10/20767 Page 8 of 14

9 3.18 Does the system identify who or what process transferred the control of a record? The system should be capable of capturing and retaining metadata about who/what undertook the transfer Does the system capture the reference number of the authorisation for the transfer of records from the UoN control? An authorisation reference for the transfer (e.g. FA ; GA ; By court order; NAP etc.) should also be recorded Does the system identify who the control of a record was transferred to? The system should be capable of capturing and retaining metadata about the name of the receiving organisation. Destruction/deletion of records Requirement Response Additional Detail 3.21 Does the system identify that a record was destroyed/deleted from the system? The system should be capable of capturing and retaining metadata which records that a record has been destroyed Does the system capture the date a record was destroyed/deleted from the system? The system should be capable of capturing and retaining metadata which records D10/20767 Page 9 of 14

10 the date a record was destroyed Does the system identify who or what process destroyed/deleted the record from the system? The system should be capable of capturing and retaining metadata which records who/what undertook the destruction Does the system capture the reference number of the authorisation for the destruction/deletion of the records from the system? The system should be capable of capturing and retaining metadata which records an authorisation reference (e.g. FA ; GA ; By court order; NAP etc) 3.25 Is the system able to maintain a metadata profile over time maintaining links to the record and accumulating process metadata for the record as events occur? 3.26 Is the system able to export the records and their associated metadata to another system or to an external medium? 3.27 Are the records and their associated metadata able to be exported in suitable formats? (eg non-proprietary, readable, able to be managed in successor system/s?) D10/20767 Page 10 of 14

11 Risk Assessment Checklist for Storing Records outside NSW with Cloud Service Providers Public cloud computing usually involves transferring content to or creating content in data stores maintained by the provider and geographically remote from the customer. As a result, there are particular risks around ensuring compliance with: legislative requirements for the management of information, e.g. managing personal information government requirements, e.g. managing information security, disaster recovery and business continuity community expectations, e.g. ensuring that the University information is safely and securely stored and not available to be used for unauthorised purposes. State Records has approved the General authority for transferring records out of NSW for storage with or maintenance by service providers based outside of the State (GA35). This general authority gives approval to transfer records outside of NSW for storage with or maintenance by service providers based outside the State. However, this permission is given on the condition that an appropriate risk assessment has been made and the records are managed in accordance with all the requirements applicable to State records under the State Records Act In addition, all other legislative requirements for the management of information should also be met before entering any arrangements. In particular the University must: assess and address risks involved in taking and sending records out of the State for storage with or maintenance by service providers based outside of NSW ensure that the facilities, systems and services (including software products, storage systems) of the service provider conform to requirements in standards issued by State Records ensure that contractual arrangements and controls are in place to ensure the security, safe keeping and on-going accessibility of records ensure that contractual arrangements are in place to ensure the exportability and return of records and information is addressed ensure that the ownership of the records remains with the University ensure appropriate controls are in place to manage lawful, approved deletion or disposal of information and records monitor the arrangement to ensure the service provider is meeting all relevant requirements. There are potentially a number of business and information risks associated with using cloud computing services. These risks include: Sensitive data is hosted or stored outside of the organisation s own networks and servers. D10/20767 Page 11 of 14

12 Critical data is only accessible through the cloud service provider. This may build too much dependency on the provider. As data is managed and/or stored externally, business continuity and disaster recovery processes are outside the organisation s control and in the hands of the provider. The organisation may not be able to control the relevant information and records hosted in the cloud adequately, and may therefore fail to meet the requirement of s.11(1) of the State Records Act to ensure the safe custody and proper preservation of State records. A person in another State or country may claim ownership or otherwise take control of the records. The records may be subject to local laws and therefore be discoverable in those jurisdictions. The service provider may not have in place robust backup and disaster recovery strategies/systems. The service provider may not be able to preserve records with long retention periods. The service provider may destroy or deleted records without approval, unlawfully or inappropriately. The service provider may not be able to perform and document common records management tasks such access control, transfer and disposal. The records may not be returned upon request or at the conclusion of the contract. The records may be returned to the organisation but in a format that the organisation cannot readily access or use. The provider or owner of the business may go out of business and the data may not be recoverable. In order to manage the recordkeeping risks associated with cloud computing, the University should complete the checklist below and forward to the Records Management Office. Can the University confirm that.? /No 1. A risk assessment of keeping University records under cloud computing arrangements has been conducted and the service provider complies with the conditions listed in the General Authority for transferring records out of NSW for storage with or maintenance by service providers based outside of the State (GA35)? 2. The records to be made and kept in the cloud are not highly sensitive in nature? If so adequate safeguards are in place. 3. The ownership of records remains with the University? 4. Records are kept in accordance with the recordkeeping functionality and metadata requirements of the NSW Standards on digital recordkeeping? D10/20767 Page 12 of 14

13 5. The service provider has offsite back-up and disaster recovery measures in place? 6. A full restoration of information is possible within a reasonable timeframe in the event of an incident? 7. The provider will return all required records and associated metadata in readable formats to the University when requested? Can the Service Provider confirm.. 1. How they will meet the recordkeeping requirements specified by the University, for example additional metadata fields, to meet regulatory or business recordkeeping requirements. 2. Whether any additional charges would be levied by the service provider in the event of the University seeking to remove information from the cloud 3. If they will commit to storing and processing University information in specific jurisdictions that have legal frameworks more compatible with Australia environment. 4. That they can offer long term information accessibility. 5. That they can partition data so that key long term information can be exported and preserved and time expired data destroyed. 6. Whether they will make a contractual commitment to comply with privacy requirements on behalf of their customers both local to the University and in the location or locations(s) where the information is stored. 7. An assurance that no copy of the records or information is retained by the service provider after the termination of the contract. 8. That the University is able to regularly specify records to be destroyed? And that the provider is prepared to provide the University with certificates of destruction? 9. Whether they are regularly subjected to external security audit or certification processes. 10. How many administrators will have access to your records and details of controls over their access? 11. That University records cannot be used for applications not specified in the contract (for example, to data match with databases owned by other clients of the contractor) 12. That the University will be consulted regarding any third parties seeking to access to our records? 13. How third party access to records would be managed, for example if required by a government watchdog organisation in the jurisdiction in which the records are stored. D10/20767 Page 13 of 14

14 14. If they have measures such as multiple geographically separated back-up sites in place, so that they can do a complete restoration of your records if needed, and how long this would take. 15. How will they go about finding and restoring particular specified records or sets of records that need to be restored and what timeframes will they guarantee for this. For example, if someone accidentally deletes some records or if some data becomes corrupted. 16. When restoring records, can they ensure that the structure of records (not just the content) and associated metadata is maintained? 17. Whether service providers subcontract part of their service offering to third parties and, if so, what contractual agreements they operate under. 18. If there any standards they are certified as meeting? 19. Will the service provider guarantee acceptable parameters for service provision in respect to possible disruptions? What actions will they take in the event of service disruption, do they offer any recompense? D10/20767 Page 14 of 14