ISO 16175-3:2010

Information and documentation - Principles and functional requirements for records in electronic office environments - Part 3: Guidelines and functional requirements for records in business systems

ISO 16175-3:2010 specifies general requirements and guidelines for records management and gives guidelines for the appropriate identification and management of evidence (records) of business activities transacted through business systems. It gives guidelines to understand processes and requirements for identifying and managing records in business systems; to develop requirements for functionality for records to be included in a design specification when building, upgrading or purchasing business system software; to evaluate the records management capability of proposed customized or commercial off-the-shelf business system software; to review the functionality for records or assess compliance of existing business systems. ISO 16175-3:2010 specifies requirements for export supports preservation by allowing the export of records to a system that is capable of long-term preservation activities, or for the ongoing migration of records into new systems. It does not specify requirements for the long-term preservation of digital records. ISO 16175-3:2010 is not applicable to records management in highly integrated software environments based on service-oriented architectures. ISO 16175-3:2010 does not specify a general system management, nor the design requirements such as usability, reporting, searching, system administration and performance. It also does not specify developing design specifications, procurement and evaluation processes in any detail.

Information et documentation — Principes et exigences fonctionnelles pour les enregistrements dans les environnements électroniques de bureau — Partie 3: Lignes directrices et exigences fonctionnelles pour les enregistrements dans les systèmes d'entreprise

Informatika in dokumentacija - Načela in funkcionalne zahteve za zapise v okoljih elektronske pisarne - 3. del: Smernice in funkcionalne zahteve za zapise v poslovnih sistemih

Ta dokument bo organizacijam pomagal zagotoviti, da ustrezno identificirajo dokaze (zapise) poslovnih dejavnosti, ki so bile opravljene prek poslovnega sistema, in da z njimi ustrezno upravljajo. Natančneje, organizacijam bo pomagal: – razumeti postopke in zahteve za identifikacijo zapisov in upravljanje z njimi v poslovnih sistemih; – razviti zahteve za vključevanje funkcionalnosti zapisov v specifikacije zasnove pri oblikovanju, nadgradnji ali nakupu programske opreme za poslovne sisteme; – vrednotiti zmogljivost upravljanja z zapisi predlagane prilagojene ali nabavljene komercialne programske opreme za poslovne sisteme; in – pregledati funkcionalnost za zapise ali oceniti skladnost obstoječih poslovnih sistemov. Ne zagotavlja celotne specifikacije, ampak okvirno določa številne ključne zahteve za upravljanje z zapisi skupaj s priporočeno stopnjo obveznosti, ki se lahko uporabi kot izhodišče za nadaljnji razvoj. Kot je navedeno v dokumentu, bodo organizacije še vedno morale oceniti, popraviti in izbrati svoje zahteve glede na svoje poslovno, tehnično in sodno okolje ter omejitve. Ta modul se nanaša samo na zahteve za upravljanje z zapisi in ne vključuje splošnega upravljanja s sistemom. Zahteve zasnove, kot so uporabnost, poročanje, iskanje, skrbništvo sistema in zmogljivost, v tem dokumentu niso obravnavane. Prav tako predvideva dobro znanje o razvoju specifikacij zasnove ter postopkih nabave in vrednotenja, zato teh vprašanj ta del podrobno ne zajema. Zahteve za dolgotrajno shranjevanje digitalnih zapisov izrecno niso obravnavane v tem dokumentu. Vendar pa vključitev zahtev za izvoz podpira shranjevanje, saj omogoča izvoz zapisov v sistem, ki omogoča dolgotrajno shranjevanje, ali nenehno migracijo zapisov v nove sisteme. Čeprav se navodila v tem modulu uporabljajo za upravljanje z zapisi v programskih okoljih z visoko stopnjo integracije, ki temeljijo na v storitve usmerjenih arhitekturah, pa taki scenariji niso izrecno obravnavani. V takih okoljih sicer veljajo podobna načela in postopki, vendar je potrebna dodatna analiza, da se določi, kateri postopki in podatki v več sistemih predstavljajo zahtevane dokaze ali zapise o kateri koli posebni transakciji. Uporaba izraza »sistem« se v tem dokumentu nanaša na računalnik ali na sistem IT. To je v nasprotju z razumevanjem izraza pri upravljanju z zapisi, ki vključuje širši vidik ljudi, politik, postopkov in praks. Organizacije bodo morale upoštevati te širše vidike, da zagotovijo obstoj osnovnih podpornih orodij za upravljanje zapisov, kot so organi za odstranjevanje zapisov, klasifikacije informacijske varnosti in kultura zbiranja zapisov, da zagotovijo ustrezno upravljanje z dokumenti iz poslovnih sistemov.

General Information

• Status: Withdrawn
• Publication Date: 24-Nov-2010
• Withdrawal Date: 24-Nov-2010
• ICS: 01.140.20 - Information sciences
• Technical Committee: ISO/TC 46/SC 11 - Archives/records management
• Drafting Committee: ISO/TC 46/SC 11 - Archives/records management
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 05-Oct-2020
• Completion Date: 13-Dec-2025
• Ref Project: SIST ISO 16175-3:2013 - Information and documentation -- Principles and functional requirements for records in electronic office environments -- Part 3: Guidelines and functional requirements for records in business systems

Relations

• Revised: ISO/TS 16175-2:2020 - Information and documentation - Processes and functional requirements for software for managing records - Part 2: Guidance for selecting, designing, implementing and maintaining software for managing records
• Effective Date: 29-Jul-2017

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 16175-3
First edition
2010-12-01
Information and documentation —
Principles and functional requirements
for records in electronic office
environments —
Part 3:
Guidelines and functional requirements
for records in business systems
Information et documentation — Principes et exigences fonctionnelles
pour les enregistrements dans les environnements électroniques de
bureau —
Partie 3: Lignes directrices et exigences fonctionnelles pour les
enregistrements dans les systèmes d'entreprise

Reference number
©
ISO 2010
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2010 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
ISO 16175-3 was prepared by the International Council on Archives (as International Council on Archives and
the Australasian Digital Recordkeeping Initiative Principles and Functional Requirements for Records in
Electronic Office Environments — Module 1: Overview and Statement of Principles) and was adopted, under a
special “fast-track procedure”, by Technical Committee ISO/TC 46, Information and documentation,
Subcommittee SC 11, Archives/records management, in parallel with its approval by the ISO member bodies.
ISO 16175 consists of the following parts, under the general title Information and documentation — Principles
and functional requirements for records in electronic office environments:
⎯ Part 1: Overview and statement of principles
⎯ Part 2: Guidelines and functional requirements for records in electronic office environments
⎯ Part 3: Guidelines and functional requirements for records in business systems
Blank page
iv © ISO 2010 – All rights reserved

International Council on Archives

`
Principles and functional requirements for
records in digital office environments
Module 3
Guidelines and functional
requirements for records in
business systems
Published by the International Council on Archives. This module was developed by the National Archives of
Australia and Queensland State Archives in conjunction with a joint project team formed by members of the
International Council on Archives and the Australasian Digital Recordkeeping Initiative.
© International Council on Archives 2008
ISBN: 978-2-918004-02-8
Reproduction by translation or reprinting of the whole or of parts for non-commercial purposes is allowed on
condition that due acknowledgement is made.
This publication should be cited as: International Council on Archives, Principles and Functional
Requirements for Records in Digital Office Environments – Module 3: Guidelines and Functional
Requirements for Records in Business Systems, 2008, published at www.ica.org.
vi © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
CONTENTS
1 INTRODUCTION 1
1.1 Scope and purpose 1
1.2 Audience 2
1.3 Related standards 3
1.4 Terminology 3
1.5 Structure 4
2 GUIDELINES 5
2.1 Why is it important to have evidence of business processes and
activities? 5
2.2 The business systems landscape and records 6
2.3 Determining needs for evidence of events, transactions and decisions
in business systems 7
2.3.1 Analyse the work process 7
2.3.2 Identify requirements for evidence of the business 8
2.3.3 Identify the content and its associated management
information that record this evidence 9
2.3.4 Identify linkages and dependencies 15
2.3.5 Devise strategies to address core records processes based
on an options assessment 16
2.3.6 Risk and options assessment 20
2.3.7 Implementation 21
2.4 Using the functional requirements 23
2.4.1 Key outcomes 24
2.4.2 Developing a software design specification for a business
system with records management functionality 25
2.4.3 Reviewing, assessing and auditing existing business
systems 26
2.4.4 Undertaking the review process 27
2.5 Entity relationship models 29
2.5.1 Record categories and the records classification scheme 29
2.5.2 Aggregations of digital records 30
2.5.3 Digital records 31
2.5.4 Extracts 31
2.5.5 Components 31
3 FUNCTIONAL REQUIREMENTS 32
3.1 Creating records in context 34
3.1.1 Creating a fixed record 35
3.1.2 Record metadata 38
3.1.3 Managing of aggregations of digital records 39
3.1.4 Records classification 40
International Council on Archives Records in Business Systems
3.2 Managing and maintaining records 40
3.2.1 Metadata configuration 42
3.2.2 Record reassignment, reclassification, duplication and
extraction 43
3.2.3 Reporting on records 44
3.2.4 Online security processes 44
3.3 Supporting import, export and interoperability 47
3.3.1 Import 48
3.3.2 Export 48
3.4 Retaining and disposing of records as required 49
3.4.1 Compliance with disposition authorisation regimes 50
3.4.2 Disposition application 52
3.4.3 Review 54
3.4.4 Destruction 55
3.4.5 Disposition metadata 55
3.4.6 Reporting on disposition activity 56
4 APPENDICES 58
A Glossary 58
B Integrating records considerations into the systems development life
cycle 67
1 Project initiation 67
3 Requirements analysis 68
4 Design 68
5 Implementation 69
6 Maintenance 69
7 Review and evaluation 70
C Further reading 71
viii © ISO 2010 – All rights reserved

INTERNATIONAL STANDARD ISO 16175-3:2010(E)

International Council on Archives Records in Business Systems
1 INTRODUCTION
Organisations implement business systems to automate business activities and
transactions. As a result, the digital information generated by a business system
increasingly serves as the only evidence or record of the process, despite the system
not being designed for this purpose. Without evidence of these activities,
organisations are exposed to risk and may be unable to meet legislative,
accountability, business and community expectations.
Because of the dynamic and manipulable nature of business systems, the capture of
fixed records and the ongoing management of their authenticity, reliability, usability
and integrity can be challenging. Organisations are therefore faced with a significant
risk of mismanagement, inefficiency and unnecessary expenditure.
While these same organisations may have an electronic records management
system (ERMS), it may not capture all records of the organisation. This document is
designed to address the records management gap caused by the increasing use of
business systems.
It provides guidelines on identifying and addressing the needs for records, and a set
of generic requirements for records management functionality within business
systems software. It aims to:
• help organizations understand digital records management requirements;
• assist organisations to improve digital records management practices;
• reduce the duplication of effort and associated costs in identifying a minimum
level of functionality for records in business systems; and
• establish greater standardisation of records management requirements for
software vendors.
The document does not prescribe a specific implementation approach. The intent of
these specifications can be realised through interfacing or integrating the business
system with an electronic records management system or by building the
functionality into the business system.
1.1 Scope and purpose
This document will help organisations to ensure that evidence (records) of business
activities transacted through business systems are appropriately identified and
managed. Specifically, it will assist organisations to:
• understand processes and requirements for identifying and managing records
in business systems;
An electronic records management system is a type of business system specifically
designed to manage records. However, in the interests of clarify and brevity, for the
purpose of this document, ‘business system’ should be taken as excluding an electronic
records management system.
International Council on Archives Records in Business Systems
• develop requirements for functionality for records to be included in a design
specification when building, upgrading or purchasing business system
software;
• evaluate the records management capability of proposed customised or
commercial off-the-shelf business system software; and
• review the functionality for records or assess compliance of existing business
systems.
It does not provide a complete specification but rather outlines a number of key
records management requirements, with recommended levels of obligation, which
can be used as a starting point for further development. As outlined in the document,
organisations will still need to assess, amend and select their requirements based on
their business, technical and jurisdictional environments and constraints.
This Module only addresses records management requirements and does not
include general system management. Design requirements such as usability,
reporting, searching, system administration and performance are beyond the scope
of this document. It also assumes a level of knowledge about developing design
specifications, procurement and evaluation processes, therefore these related issues
are not covered in any detail.
Requirements for the long-term preservation of digital records are not explicitly
covered within this document. However, the inclusion of requirements for export
supports preservation by allowing the export of records to a system that is capable of
long-term preservation activities, or for the ongoing migration of records into new
systems.
While the guidance presented in this Module should be applicable to records
management in highly integrated software environments based on service-oriented
architectures, such scenarios are not explicitly addressed. Similar principles and
processes will apply in such environments, but additional analysis will be required to
determine what processes and data constitute, across multiple systems, the required
evidence or record of any particular transaction.
Use of the term ’system’ in this document refers to a computer or IT system. This is
in contrast to the records management understanding of the term that encompasses
the broader aspects of people, policies, procedures and practices. Organisations will
need to consider these wider aspects, and to ensure that fundamental records
management supporting tools such as disposition authorities, information security
classifications and a records culture are in place, in order to ensure records from
business systems can be appropriately managed.
1.2 Audience
The primary audience for this document is staff responsible for designing, reviewing
and/or implementing business systems in organisations, such as business analysts

A formal instrument that defines the retention periods and consequent actions authorised
for classes of records described in the authority.

2 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
and groups overseeing information and communications technologies procurement
or investment decisions.
The audience also includes records professionals who are involved in advising or
assisting in such processes and software vendors and developers who wish to
incorporate records functionality within their products.
Given the target audience for this document, the use of specific records
management terminology has been kept to a minimum. Where the use of such
terminology is necessary, definitions can be found in the Glossary at Appendix A.
Some key definitions are also provided in Section 1.4: Key definitions.
1.3 Related standards
Under its Electronic Records and Automation Priority Area, the International Council
on Archives has developed a suite of guidelines and functional requirements as part
of the Principles and Functional Requirements for Records in Digital Office
Environments project:
• Module 1: Overview and Statement of Principles;
• Module 2: Guidelines and Functional Requirements for Records in Digital
Office Environments; and
• Module 3: Guidelines and Functional Requirements for Records in Business
Systems.
This document is Module 3 of the broader project. It has been developed with the
support of the Australasian Digital Recordkeeping Initiative.
While this Module may be used as a stand-alone resource, for a broader
understanding of the context and principles that have informed its development,
readers should also refer to Module 1.
The functional requirements identified in Part 2 are based on the minimum
requirements for records functionality as defined in the International Standard for
Records Management, ISO 15489.
The reference metadata standard for these requirements is ISO 23081 – 1: 2006,
Information and documentation – Records management processes – Metadata for
records, Part 1 – Principles, and ISO 23081 – 2: 2009, Information and
documentation – Records management processes – Metadata for records, Part 2 –
Conceptual and implementation Issues.
1.4 Terminology
It is recognised that many of the terms used in this document have different
meanings for different disciplines. It is therefore important that this document is read
in conjunction with the Glossary at Appendix A. A number of the key concepts used
in this document are also detailed below:
• Records are information created, received and maintained as evidence and
information by an organisation or person, in pursuance of legal obligations or

International Council on Archives Records in Business Systems
in the transaction of business. They provide evidence of business
transactions and can exist in any format.
• Business systems, for the purposes of this document, 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). For the purposes of this document, business
systems exclude electronic records management systems.
• Electronic records management systems (ERMS) are specifically
designed to manage the maintenance and disposition of records. They
maintain the content, context, structure and links among records to enable
their accessibility and support their value as evidence. Electronic records
management systems are distinguished from business systems, for the
purpose of this document, because their primary function is the management
of records.
1.5 Structure
This document is divided into four main parts:
• Part 1: Introduction – describes the scope, purpose, audience and structure
of the overall document.
• Part 2: Guidelines – provides background information on the importance of
records management, describes key terms and concepts, and outlines a
process for determining an organisation’s need for records and identifying
records within business systems. It also outlines some of the issues and
processes to be considered when reviewing, designing, purchasing or
building business systems to incorporate functionality for records.
• Part 3: Functional requirements – provides an overview of the high-level
functional requirements for records that may be incorporated into a business
system, and outlines a recommended set of mandatory and optional records
management functional requirements for business systems (referred to as the
‘functional requirements’).
• Part 4: Appendices – provides a glossary of key terms and a list of
additional reading.
International Standard on Records management, ISO 15489.

4 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
2 GUIDELINES
2.1 Why is it important to have evidence of business processes and
activities?
A key way organisations account for their activities is through evidence of business
transactions in the form of records. Records are valuable business assets that
enable organisations to defend their actions, improve decision-making, prove
ownership of physical and intellectual assets, and support all business processes.
Records are ‘information created, received, and maintained as evidence and
information, by an organisation or person, in pursuance of legal obligations or in the
transaction of business.’ They must be retained for a period of time that is in line
with an authorised retention schedule or ‘disposition authority’.
Organisations with business systems that have insufficient functionality for managing
records risk loss of this evidence, resulting in inefficiency, an inability to meet
accountability and legislative requirements, and a lack of corporate memory.
A record is not just a collection of data, but is the consequence or product of an
event. A distinguishing feature of records is that their content must exist in a fixed
form, that is, be a fixed representation of the business transaction. This can be
particularly challenging in a business system that, by nature, contains data that is
frequently updated and dynamic.
Records comprise not only content but also information about the context and
structure of the record. This information can be captured through metadata.
Metadata fixes the record in its business context and documents the record’s
management and use over time. Records metadata therefore serves to identify,
authenticate and contextualise the record, not only at the point of creation, but
continues to document its management and use over time. It allows records to be
located, rendered and understood in a meaningful way. The International Standard
on Information and documentation—Records management processes—Metadata for
records, Part 2, ISO 23081, provides a generic statement of metadata elements.
Organisations may also have jurisdictional-specific elements sets to which they must
adhere.
An appropriately managed record will:
• aid transparent, informed and quality decision-making and planning;
• provide an information resource that can be used to demonstrate and
account for organisational activities; and

International Standard on Records Management, ISO 15489.
Philip C Bantin, Strategies for Managing Electronic Records: Lessons Learned from the
Indiana University Electronic Records Project, available at
http://www.indiana.edu/~libarch/ER/ecure2000.pdf, 2003.
International Standard on Information and documentation—Records management
processes—Metadata for records, ISO 23081-1:2006.

International Council on Archives Records in Business Systems
• enable consistency, continuity and efficiency in administration and
management, among other benefits.
The International Standard on Records management, ISO 15489, provides best-
practice guidance on how records should be managed to ensure they are authentic,
reliable, complete, unaltered and usable.
2.2 The business systems landscape and records
Business systems are normally mapped against some form of business process.
Given that records are the product of transactions and transactions, collectively, form
business processes (for example, the transactions involved in processing an
application for a licence), it follows that the integration of records functionality in
business systems should be undertaken from the perspective of the business
process.
Business processes having the greatest potential for reflecting good records
management are those that are highly structured with well-defined transactions
where the identification of where in the business process records should be
generated and even what they should look like (for example, forms) is relatively
clear. Similarly it follows that records management has great potential for being
integrated successfully in the business systems supporting such business processes
because, by necessity, their design has to be mapped to the transactions supporting
the business processes. Furthermore, the development of business systems
supporting defined business processes normally proceeds through a series of
structured steps based on the use of generally accepted systems development tools
and techniques that address each phase of the systems development life cycle, from
planning and design to implementation and review. In addition, in well-managed
business systems development projects, accountability for the integrity of the design,
development, and maintenance of the systems (including the integrity of the data
generated by the systems) is clearly assigned across all of those communities in the
organisation that have a responsibility for the systems (that is, from business users
of the systems to the specialists responsible for developing the systems). All of these
factors heighten the potential for records considerations to be integrated in the
design of business systems supporting structured and well-defined business
processes.
Records management integration is challenged significantly in an environment where
business processes are poorly defined, where tools and techniques for
systematically designing and developing systems are weak, and where
accountability for the technologies supporting the environment (and especially the
information generated in the environment) has not been assigned clearly. In such an
environment individuals (often ‘office workers’ at all levels of the organisation) have a
high level of autonomy in deciding what information they create and share, how they
share it, where they put it, how they organise, describe and retain it, and how they
dispose of it. Such an environment is often dominated by email messages and their
attachments where there are few business rules to guide their creation, transmission
and management. The integration of records management in such an environment is
extremely difficult because the foundation of defined business processes (or
workflow in the parlance of the modern office), structured approaches to systems

6 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
development and assigned accountability are not in place (for more information, see
Appendix B).
2.3 Determining needs for evidence of events, transactions and
decisions in business systems
Not all information contained in a business system will necessarily be required to be
recorded as evidence. Prior to reviewing, designing, building or purchasing business
systems software, it is necessary to determine an organisation’s needs for records in
order to develop and implement appropriate strategies. This process is outlined in
Figure 1 and discussed in the following sections.
Figure 1: Steps to determine requirements for records

Step 1: Analyse the work process

Identification of Identification of

requirements
the information
for evidence of
that forms the
the business evidence
being
conducted in
the business
system
Step 2: Identify
linkages and
dependencies
Step 3: Devise
strategies, based on
options assessment
Step 4: Implement
2.3.1 Analyse the work process
Business systems typically store large volumes of data that are frequently updated.
Because of this, it can be difficult to know what information in the system needs to be
managed as a record to provide evidence of the business process or transaction.

International Council on Archives Records in Business Systems
Business systems may consist of:
• a collection of data elements (or structured data) that are linked and
controlled by the system, for example, entries in a database;
• distinct digital objects controlled by the system that have a clearly defined
data format (or unstructured/semi-structured information), for example,
documents, emails or spreadsheets; or
• a combination of the above.
The process of identifying records must commence by stepping back from the IT
system itself, and undertaking an analysis of the work processes, including related
regulatory and business requirements, to determine what evidence is required to be
kept.
As records are directly linked to business processes, identifying the records is
assisted by standard business process analysis techniques and tools, such as
activity diagrams, process decompositions and flowcharts.
It is important to work closely with the organisation’s records management and
archives professionals during this process, as much of this work may have been
undertaken when developing the organisation’s records management program
(including its disposition authority).
The process of identifying the records entails two main tasks. These are:
1 identification of requirements for evidence of the business being conducted in
the business system; and
2 identification of the information that records this evidence, that is, the ‘record’.
2.3.2 Identify requirements for evidence of the business
Step 1 – determine the broad business functions and specific activities and
transactions carried out, in full or in part, by the business system
This analysis may include consideration of business process documentation and
system inputs, outputs, and related policies and procedures. In highly integrated

7 This document primarily focuses on the management of records arising from structured
rather than unstructured data.

Refer to National Archives of Australia, DIRKS Manual: A Strategic Approach to
Managing Business Information, available at http://www.naa.gov.au/records-
management/publications/DIRKS-manual.aspx for further information.
For further information on modelling business process, see the Business Process
Modelling Notation website at http://www.bpmn.org/.
While tailored to a particular jurisdiction, see Queensland State Archives, Guideline for
the Development of Retention and Disposal Schedules available at
http://www.archives.qld.gov.au/downloads/rdschedule.pdf for guidance on developing a
disposition authority.
The term ‘evidence’ is used in this document in the sense of demonstrating or
documenting the proof of a business transaction, rather than its narrower legal context.

8 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
environments, multiple systems may need to be covered in the analysis in order to
obtain a complete picture of the business process or activity. Particularly in the
government environment, systems may also be shared by multiple organisations.
Step 2 – for each function, activity and transaction or business process managed by
the system, consider what evidence is required to be retained by the
organisation
Requirements may be derived from a number of sources. Consider such issues as:
• Are there legislative obligations to record certain evidence? Some legislation
may implicitly or explicitly state the need to create certain records in certain
forms.
• Are there regulatory instruments that must be adhered to and require
evidence to demonstrate compliance, for example, mandatory standards,
codes of practice and so on?
• Are there organisational rules that require evidence be recorded, for example,
policies, codes of conduct, reporting and so on?
• What evidence is required of decisions made to support the business process
itself or to inform future decision-making?
• Are any of the business functions or activities of the organisation considered
high risk or subject to a high level of litigation that demands a greater level of
documented evidence?
• Who are the various stakeholders and what are the different expectations
they may have about what evidence is required to be retained?
• What are the community’s expectations for evidence of the work process?
This process may involve a wide range of consultation and validation with senior
management. The International Standard on Work process analysis for records,
ISO/TR 26122-2008, and the Australian DIRKS Manual are useful resources for
these purposes.
2.3.3 Identify the content and its associated management information that
record this evidence
Not all information contained in a business system will necessarily be required to be
recorded as evidence.
This analysis may have already been done, either for records management purposes
such as disposition or classification, or in the development of the system itself through
business process review.
DIRKS stands for Designing and Implementing Recordkeeping Systems. Steps A–C
cover this analysis process. For more information, see National Archives of Australia,
DIRKS Manual: A Strategic Approach to Managing Business Information available at
http://www.naa.gov.au/records-management/publications/DIRKS-manual.aspx or State
Records NSW, The DIRKS Manual: Strategies for Documenting Government Business
available at http://www.records.nsw.gov.au/recordkeeping/dirks-manual_4226.asp.

International Council on Archives Records in Business Systems
Step 3 – for each requirement for evidence, identify the content or data that make up
the evidence
In systems that manage distinct digital objects, such as word-processed documents,
data is already drawn together into a logical construct. This means that it can be
relatively easy to identify specific documents or reports that contain the content that
could act as evidence of a particular business activity or transaction.
For others, it will require analysis of the data structures, data models and class
models that underlie the system to identify the specific data elements that together
constitute the content and provide the necessary evidence (see Figures 2 and 3
below for an illustration of this).
It is important to note that the content or data that make up the evidence may not just
be within the system. It may also be in other systems, documentation about the
system, procedures, paper inputs and so on. Particularly in highly integrated
environments, parts of the required evidence may be held across multiple systems
and some systems or components may be shared with other organisations.
There may be a number of different content elements that could serve to make up
the evidence. Deciding which content is best suited to form the required evidence will
be based on an assessment of the business need and risk. Records need to be
adequate, that is, there should be sufficient evidence of the conduct of business
activity or transaction to be able to account for that conduct. Therefore a major
initiative will be extensively documented, while a routine low-risk action may be
documented with an identifiable minimum amount of information.
Figure 2 provides a representation of the contents of a database controlled by a
14 15
business system. In this example the record is made up of a grouping of related
data elements from a number of different fields. Each record will consist of the
identified data elements in the database and the associated metadata required to link
the elements and provide the necessary structure and context to support the record.

14 Figure 2 provides a view of a normalised database. Relational database concepts,
standard data modelling and normalisation techniques should be enforced to provide the
necessary structure and context to support the traceability of the record.
15 ‘Record’ is used here in the records management sense rather than its database
meaning.
10 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
Figure 2: Identification of information components/data elements comprising a digital
record in a database
Business system
Database
Table Table Table
Field Field Field Field Field
Field
Digital record
Data Data Data Data Data Data
Data Data Data Data Data Data
Data Data Data Data Data Data
Digital record
Data Data Data Data Data Data
Note that it is possible for a single record to include multiple elements from a single database field or table, and that it
is also possible for a single data element to form part of more than one record.

International Council on Archives Records in Business Systems
Figure 3 provides a simplistic example of the tables that comprise a portion of a
relational database for a human resource management system. Each table
represents a portion of the database that contains closely linked information. Tables
A, B and C provide data relating to personnel, salaries and cost centres,
respectively. Tables D and E provide linkages between the data elements in the
other tables. Table D links staff with their relevant pay levels, while Table E links staff
with their cost centres.
Each table consists of a number of columns that represent fields containing data
elements. The rows within each table establish linkages between data elements
within the different fields. In database literature, these rows within tables are
sometimes referred to as ‘records’, although these linked data elements are not
always records in the records management sense of the term.
In line with the business process analysis, there are a number of potential records in
Figure 3. These records are represented as a number of inter-related data elements
that may be connected across one or more tables and comprise data elements from
one or more fields.
12 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
Figure 3: Further example of the identification of information components/data
elements comprising a digital record in a database

Table A: Personnel
Staff no. Surname First name Address City
0078652 Larsen Sevren 78/1 Hoddle St, Carlton Melbourne
0078653 Lee Jamie 55 Ramsey St, Vermont Melbourne
0078654 Smith Bob 7 Pollie Crt, Barton Canberra
0078655 Schmidt Helmutt 1/123 North Rd, Balmain Sydney
0078656 Darcy Kyra 67 Green St, Mt Lawley Perth

Table B: Salaries Table C: Cost centres
Pay code Level Year Pay rate Staff no. Pay code
A41 APS4 Year 1 $45,000 0078652 A53
A42 APS4 Year 2 $46,000 0078653 A42
A43 APS4 Year 3 $47,000 0078654 A42
A44 APS4 Year 4 $48,000 0078655 A41
A51 APS5 Year 1 $54,000 0078656 A51
A52 APS5 Year 2 $55,000
A53 APS5 Year 3 $56,000
Table D: Staff to pay levels Table E: Staff to cost
centres
Centre code Cost centre Director Staff no. Centre code
M001 Melbourne Office Shay Jones 0078652 M001
S001 Sydney Office Fred Nguyen 0078653 M001
P001 Perth Office Alberta Johnson 0078654 C001
C001 Canberra Office John Wasp 0078655 S001
0078656 P001
Key
Yellow Data elements comprising the personnel record of Kyra Darcy

Tourquoise Data elements comprising the record of Bob Smith’s address details

Pink Data elements comprising the record of Melbourne Office staff

International Council on Archives Records in Business Systems
Three distinct types of records have been identified in the system:
• The yellow rows identify data elements that form a single personnel record.
This record spans data elements in all five tables and contains information on
the staff member, name, address, salary level and cost centre.
• The tourquoise row identifies data elements that provide a record of an
individual’s name, address and staff number. This single row of information
could be construed as a record, but in this case the record indicated by the
yellow rows is more comprehensive and would be preferable.
• The pink rows identify data elements that form a record of all staff members
belonging to a particular cost centre. These rows may represent an
alternative method of interrogating the data contained in the tables.
Note that the information contained in Table B does not constitute a record in this
scenario, only part of the staff salary record. This is because the data contained in
Table B is supplemental and only gains value as a component of a record when it is
placed in context of a staff member in Table A. The Table B information itself is likely
to have come from an external record such as a workplace agreement.
It should be noted that there may, in some instances, be overlap between records
identified in a database. The data elements that form part of one record in a
relational database may also form part of other records generated by the same
database. For example, the staff record of ‘Jamie Lee’ and the record of Melbourne
office staff will both draw on the same data elements from Table A.
Where overlap occurs between the data elements that form digital records, the
business system must be capable of ensuring that it will not destroy the shared data
elements until both identified digital records have reached their minimum retention
period.
Step 4 – identify the additional information required to manage the content over time
as evidence
This will be the records metadata that is an integral part of the record. Records
metadata can be used to control the length of time a record is maintained, establish
its access rights and restrictions, and facilitate searching for and retrieval of the
record.
The creation, capture and management of metadata for records are essential to
allow records to be identified, understood and retrieved, and to protect the evidence
of their authenticity, reliability and integrity. Metadata should be captured in line with
an identified metadata standard for records, as stipulated by jurisdictional and/or
organisational requirements.
Metadata does not need to be retained together with the content, as long as they are
linked or associated in some way. Metadata may be contained in systems external to
the business system in question, or may encompass documentation or tools such as
XML schemas and data, and class models that allow records to be understood and
remain meaningful over time.
14 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
Particularly in database environments, it can be difficult to distinguish between the
record’s content and its metadata. For example, metadata that provides evidence
that a particular person accessed a record on a particular date and/or time is itself a
record. Often metadata in a business system pertains to the system as a whole. That
is, it applies in an overarching way to all records in the system, not to individual
records. It can reside in system rules or system documentation and not be applied to
individual records.
2.3.4 Identify linkages and dependencies
A key characteristic of records is that they cannot be understood in isolation. In order
to provide context for the record, additional information about the work process or the
business system may be required to ensure the records are understandable, to
prove the reliability of the evidence, or if records need to be moved from one system
to another in the future. Required system information may include:
• location;
• system issues/faults;
• size;
• business rules implemented;
• file formats;
• security;
• privacy management;
• data structures;
• data and class models;
• workflow routing rules; and
• audit trails.
Required information about the work process may include relevant policies and
procedural documents to show that decisions are made and processes undertaken in
accordance with authorised standards.
In addition, as noted in Section 2.3.1: Analyse the work process, many processes will
extend beyond a single business system. Necessary linkages to other systems, or
related information in paper form, must also be considered before strategies are
developed to manage the records in the business system.
A key dependency is how long the records need to be kept. Records must be
retained for a period of time
...

SLOVENSKI STANDARD
01-julij-2013
,QIRUPDWLNDLQGRNXPHQWDFLMD1DþHODLQIXQNFLRQDOQH]DKWHYH]D]DSLVHYRNROMLK
HOHNWURQVNHSLVDUQHGHO6PHUQLFHLQIXQNFLRQDOQH]DKWHYH]D]DSLVHY
SRVORYQLKVLVWHPLK
Information and documentation -- Principles and functional requirements for records in
electronic office environments -- Part 3: Guidelines and functional requirements for
records in business systems
Information et documentation -- Principes et exigences fonctionnelles pour les
enregistrements dans les environnements électroniques de bureau -- Partie 3: Lignes
directrices et exigences fonctionnelles pour les enregistrements dans les systèmes
d'entreprise
Ta slovenski standard je istoveten z: ISO 16175-3:2010
ICS:
01.140.20 Informacijske vede Information sciences
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

INTERNATIONAL ISO
STANDARD 16175-3
First edition
2010-12-01
Information and documentation —
Principles and functional requirements
for records in electronic office
environments —
Part 3:
Guidelines and functional requirements
for records in business systems
Information et documentation — Principes et exigences fonctionnelles
pour les enregistrements dans les environnements électroniques de
bureau —
Partie 3: Lignes directrices et exigences fonctionnelles pour les
enregistrements dans les systèmes d'entreprise

Reference number
©
ISO 2010
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2010 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
ISO 16175-3 was prepared by the International Council on Archives (as International Council on Archives and
the Australasian Digital Recordkeeping Initiative Principles and Functional Requirements for Records in
Electronic Office Environments — Module 1: Overview and Statement of Principles) and was adopted, under a
special “fast-track procedure”, by Technical Committee ISO/TC 46, Information and documentation,
Subcommittee SC 11, Archives/records management, in parallel with its approval by the ISO member bodies.
ISO 16175 consists of the following parts, under the general title Information and documentation — Principles
and functional requirements for records in electronic office environments:
⎯ Part 1: Overview and statement of principles
⎯ Part 2: Guidelines and functional requirements for records in electronic office environments
⎯ Part 3: Guidelines and functional requirements for records in business systems
Blank page
iv © ISO 2010 – All rights reserved

International Council on Archives

`
Principles and functional requirements for
records in digital office environments
Module 3
Guidelines and functional
requirements for records in
business systems
Published by the International Council on Archives. This module was developed by the National Archives of
Australia and Queensland State Archives in conjunction with a joint project team formed by members of the
International Council on Archives and the Australasian Digital Recordkeeping Initiative.
© International Council on Archives 2008
ISBN: 978-2-918004-02-8
Reproduction by translation or reprinting of the whole or of parts for non-commercial purposes is allowed on
condition that due acknowledgement is made.
This publication should be cited as: International Council on Archives, Principles and Functional
Requirements for Records in Digital Office Environments – Module 3: Guidelines and Functional
Requirements for Records in Business Systems, 2008, published at www.ica.org.
vi © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
CONTENTS
1 INTRODUCTION 1
1.1 Scope and purpose 1
1.2 Audience 2
1.3 Related standards 3
1.4 Terminology 3
1.5 Structure 4
2 GUIDELINES 5
2.1 Why is it important to have evidence of business processes and
activities? 5
2.2 The business systems landscape and records 6
2.3 Determining needs for evidence of events, transactions and decisions
in business systems 7
2.3.1 Analyse the work process 7
2.3.2 Identify requirements for evidence of the business 8
2.3.3 Identify the content and its associated management
information that record this evidence 9
2.3.4 Identify linkages and dependencies 15
2.3.5 Devise strategies to address core records processes based
on an options assessment 16
2.3.6 Risk and options assessment 20
2.3.7 Implementation 21
2.4 Using the functional requirements 23
2.4.1 Key outcomes 24
2.4.2 Developing a software design specification for a business
system with records management functionality 25
2.4.3 Reviewing, assessing and auditing existing business
systems 26
2.4.4 Undertaking the review process 27
2.5 Entity relationship models 29
2.5.1 Record categories and the records classification scheme 29
2.5.2 Aggregations of digital records 30
2.5.3 Digital records 31
2.5.4 Extracts 31
2.5.5 Components 31
3 FUNCTIONAL REQUIREMENTS 32
3.1 Creating records in context 34
3.1.1 Creating a fixed record 35
3.1.2 Record metadata 38
3.1.3 Managing of aggregations of digital records 39
3.1.4 Records classification 40
International Council on Archives Records in Business Systems
3.2 Managing and maintaining records 40
3.2.1 Metadata configuration 42
3.2.2 Record reassignment, reclassification, duplication and
extraction 43
3.2.3 Reporting on records 44
3.2.4 Online security processes 44
3.3 Supporting import, export and interoperability 47
3.3.1 Import 48
3.3.2 Export 48
3.4 Retaining and disposing of records as required 49
3.4.1 Compliance with disposition authorisation regimes 50
3.4.2 Disposition application 52
3.4.3 Review 54
3.4.4 Destruction 55
3.4.5 Disposition metadata 55
3.4.6 Reporting on disposition activity 56
4 APPENDICES 58
A Glossary 58
B Integrating records considerations into the systems development life
cycle 67
1 Project initiation 67
3 Requirements analysis 68
4 Design 68
5 Implementation 69
6 Maintenance 69
7 Review and evaluation 70
C Further reading 71
viii © ISO 2010 – All rights reserved

INTERNATIONAL STANDARD ISO 16175-3:2010(E)

International Council on Archives Records in Business Systems
1 INTRODUCTION
Organisations implement business systems to automate business activities and
transactions. As a result, the digital information generated by a business system
increasingly serves as the only evidence or record of the process, despite the system
not being designed for this purpose. Without evidence of these activities,
organisations are exposed to risk and may be unable to meet legislative,
accountability, business and community expectations.
Because of the dynamic and manipulable nature of business systems, the capture of
fixed records and the ongoing management of their authenticity, reliability, usability
and integrity can be challenging. Organisations are therefore faced with a significant
risk of mismanagement, inefficiency and unnecessary expenditure.
While these same organisations may have an electronic records management
system (ERMS), it may not capture all records of the organisation. This document is
designed to address the records management gap caused by the increasing use of
business systems.
It provides guidelines on identifying and addressing the needs for records, and a set
of generic requirements for records management functionality within business
systems software. It aims to:
• help organizations understand digital records management requirements;
• assist organisations to improve digital records management practices;
• reduce the duplication of effort and associated costs in identifying a minimum
level of functionality for records in business systems; and
• establish greater standardisation of records management requirements for
software vendors.
The document does not prescribe a specific implementation approach. The intent of
these specifications can be realised through interfacing or integrating the business
system with an electronic records management system or by building the
functionality into the business system.
1.1 Scope and purpose
This document will help organisations to ensure that evidence (records) of business
activities transacted through business systems are appropriately identified and
managed. Specifically, it will assist organisations to:
• understand processes and requirements for identifying and managing records
in business systems;
An electronic records management system is a type of business system specifically
designed to manage records. However, in the interests of clarify and brevity, for the
purpose of this document, ‘business system’ should be taken as excluding an electronic
records management system.
International Council on Archives Records in Business Systems
• develop requirements for functionality for records to be included in a design
specification when building, upgrading or purchasing business system
software;
• evaluate the records management capability of proposed customised or
commercial off-the-shelf business system software; and
• review the functionality for records or assess compliance of existing business
systems.
It does not provide a complete specification but rather outlines a number of key
records management requirements, with recommended levels of obligation, which
can be used as a starting point for further development. As outlined in the document,
organisations will still need to assess, amend and select their requirements based on
their business, technical and jurisdictional environments and constraints.
This Module only addresses records management requirements and does not
include general system management. Design requirements such as usability,
reporting, searching, system administration and performance are beyond the scope
of this document. It also assumes a level of knowledge about developing design
specifications, procurement and evaluation processes, therefore these related issues
are not covered in any detail.
Requirements for the long-term preservation of digital records are not explicitly
covered within this document. However, the inclusion of requirements for export
supports preservation by allowing the export of records to a system that is capable of
long-term preservation activities, or for the ongoing migration of records into new
systems.
While the guidance presented in this Module should be applicable to records
management in highly integrated software environments based on service-oriented
architectures, such scenarios are not explicitly addressed. Similar principles and
processes will apply in such environments, but additional analysis will be required to
determine what processes and data constitute, across multiple systems, the required
evidence or record of any particular transaction.
Use of the term ’system’ in this document refers to a computer or IT system. This is
in contrast to the records management understanding of the term that encompasses
the broader aspects of people, policies, procedures and practices. Organisations will
need to consider these wider aspects, and to ensure that fundamental records
management supporting tools such as disposition authorities, information security
classifications and a records culture are in place, in order to ensure records from
business systems can be appropriately managed.
1.2 Audience
The primary audience for this document is staff responsible for designing, reviewing
and/or implementing business systems in organisations, such as business analysts

A formal instrument that defines the retention periods and consequent actions authorised
for classes of records described in the authority.

2 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
and groups overseeing information and communications technologies procurement
or investment decisions.
The audience also includes records professionals who are involved in advising or
assisting in such processes and software vendors and developers who wish to
incorporate records functionality within their products.
Given the target audience for this document, the use of specific records
management terminology has been kept to a minimum. Where the use of such
terminology is necessary, definitions can be found in the Glossary at Appendix A.
Some key definitions are also provided in Section 1.4: Key definitions.
1.3 Related standards
Under its Electronic Records and Automation Priority Area, the International Council
on Archives has developed a suite of guidelines and functional requirements as part
of the Principles and Functional Requirements for Records in Digital Office
Environments project:
• Module 1: Overview and Statement of Principles;
• Module 2: Guidelines and Functional Requirements for Records in Digital
Office Environments; and
• Module 3: Guidelines and Functional Requirements for Records in Business
Systems.
This document is Module 3 of the broader project. It has been developed with the
support of the Australasian Digital Recordkeeping Initiative.
While this Module may be used as a stand-alone resource, for a broader
understanding of the context and principles that have informed its development,
readers should also refer to Module 1.
The functional requirements identified in Part 2 are based on the minimum
requirements for records functionality as defined in the International Standard for
Records Management, ISO 15489.
The reference metadata standard for these requirements is ISO 23081 – 1: 2006,
Information and documentation – Records management processes – Metadata for
records, Part 1 – Principles, and ISO 23081 – 2: 2009, Information and
documentation – Records management processes – Metadata for records, Part 2 –
Conceptual and implementation Issues.
1.4 Terminology
It is recognised that many of the terms used in this document have different
meanings for different disciplines. It is therefore important that this document is read
in conjunction with the Glossary at Appendix A. A number of the key concepts used
in this document are also detailed below:
• Records are information created, received and maintained as evidence and
information by an organisation or person, in pursuance of legal obligations or

International Council on Archives Records in Business Systems
in the transaction of business. They provide evidence of business
transactions and can exist in any format.
• Business systems, for the purposes of this document, 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). For the purposes of this document, business
systems exclude electronic records management systems.
• Electronic records management systems (ERMS) are specifically
designed to manage the maintenance and disposition of records. They
maintain the content, context, structure and links among records to enable
their accessibility and support their value as evidence. Electronic records
management systems are distinguished from business systems, for the
purpose of this document, because their primary function is the management
of records.
1.5 Structure
This document is divided into four main parts:
• Part 1: Introduction – describes the scope, purpose, audience and structure
of the overall document.
• Part 2: Guidelines – provides background information on the importance of
records management, describes key terms and concepts, and outlines a
process for determining an organisation’s need for records and identifying
records within business systems. It also outlines some of the issues and
processes to be considered when reviewing, designing, purchasing or
building business systems to incorporate functionality for records.
• Part 3: Functional requirements – provides an overview of the high-level
functional requirements for records that may be incorporated into a business
system, and outlines a recommended set of mandatory and optional records
management functional requirements for business systems (referred to as the
‘functional requirements’).
• Part 4: Appendices – provides a glossary of key terms and a list of
additional reading.
International Standard on Records management, ISO 15489.

4 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
2 GUIDELINES
2.1 Why is it important to have evidence of business processes and
activities?
A key way organisations account for their activities is through evidence of business
transactions in the form of records. Records are valuable business assets that
enable organisations to defend their actions, improve decision-making, prove
ownership of physical and intellectual assets, and support all business processes.
Records are ‘information created, received, and maintained as evidence and
information, by an organisation or person, in pursuance of legal obligations or in the
transaction of business.’ They must be retained for a period of time that is in line
with an authorised retention schedule or ‘disposition authority’.
Organisations with business systems that have insufficient functionality for managing
records risk loss of this evidence, resulting in inefficiency, an inability to meet
accountability and legislative requirements, and a lack of corporate memory.
A record is not just a collection of data, but is the consequence or product of an
event. A distinguishing feature of records is that their content must exist in a fixed
form, that is, be a fixed representation of the business transaction. This can be
particularly challenging in a business system that, by nature, contains data that is
frequently updated and dynamic.
Records comprise not only content but also information about the context and
structure of the record. This information can be captured through metadata.
Metadata fixes the record in its business context and documents the record’s
management and use over time. Records metadata therefore serves to identify,
authenticate and contextualise the record, not only at the point of creation, but
continues to document its management and use over time. It allows records to be
located, rendered and understood in a meaningful way. The International Standard
on Information and documentation—Records management processes—Metadata for
records, Part 2, ISO 23081, provides a generic statement of metadata elements.
Organisations may also have jurisdictional-specific elements sets to which they must
adhere.
An appropriately managed record will:
• aid transparent, informed and quality decision-making and planning;
• provide an information resource that can be used to demonstrate and
account for organisational activities; and

International Standard on Records Management, ISO 15489.
Philip C Bantin, Strategies for Managing Electronic Records: Lessons Learned from the
Indiana University Electronic Records Project, available at
http://www.indiana.edu/~libarch/ER/ecure2000.pdf, 2003.
International Standard on Information and documentation—Records management
processes—Metadata for records, ISO 23081-1:2006.

International Council on Archives Records in Business Systems
• enable consistency, continuity and efficiency in administration and
management, among other benefits.
The International Standard on Records management, ISO 15489, provides best-
practice guidance on how records should be managed to ensure they are authentic,
reliable, complete, unaltered and usable.
2.2 The business systems landscape and records
Business systems are normally mapped against some form of business process.
Given that records are the product of transactions and transactions, collectively, form
business processes (for example, the transactions involved in processing an
application for a licence), it follows that the integration of records functionality in
business systems should be undertaken from the perspective of the business
process.
Business processes having the greatest potential for reflecting good records
management are those that are highly structured with well-defined transactions
where the identification of where in the business process records should be
generated and even what they should look like (for example, forms) is relatively
clear. Similarly it follows that records management has great potential for being
integrated successfully in the business systems supporting such business processes
because, by necessity, their design has to be mapped to the transactions supporting
the business processes. Furthermore, the development of business systems
supporting defined business processes normally proceeds through a series of
structured steps based on the use of generally accepted systems development tools
and techniques that address each phase of the systems development life cycle, from
planning and design to implementation and review. In addition, in well-managed
business systems development projects, accountability for the integrity of the design,
development, and maintenance of the systems (including the integrity of the data
generated by the systems) is clearly assigned across all of those communities in the
organisation that have a responsibility for the systems (that is, from business users
of the systems to the specialists responsible for developing the systems). All of these
factors heighten the potential for records considerations to be integrated in the
design of business systems supporting structured and well-defined business
processes.
Records management integration is challenged significantly in an environment where
business processes are poorly defined, where tools and techniques for
systematically designing and developing systems are weak, and where
accountability for the technologies supporting the environment (and especially the
information generated in the environment) has not been assigned clearly. In such an
environment individuals (often ‘office workers’ at all levels of the organisation) have a
high level of autonomy in deciding what information they create and share, how they
share it, where they put it, how they organise, describe and retain it, and how they
dispose of it. Such an environment is often dominated by email messages and their
attachments where there are few business rules to guide their creation, transmission
and management. The integration of records management in such an environment is
extremely difficult because the foundation of defined business processes (or
workflow in the parlance of the modern office), structured approaches to systems

6 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
development and assigned accountability are not in place (for more information, see
Appendix B).
2.3 Determining needs for evidence of events, transactions and
decisions in business systems
Not all information contained in a business system will necessarily be required to be
recorded as evidence. Prior to reviewing, designing, building or purchasing business
systems software, it is necessary to determine an organisation’s needs for records in
order to develop and implement appropriate strategies. This process is outlined in
Figure 1 and discussed in the following sections.
Figure 1: Steps to determine requirements for records

Step 1: Analyse the work process

Identification of Identification of

requirements
the information
for evidence of
that forms the
the business evidence
being
conducted in
the business
system
Step 2: Identify
linkages and
dependencies
Step 3: Devise
strategies, based on
options assessment
Step 4: Implement
2.3.1 Analyse the work process
Business systems typically store large volumes of data that are frequently updated.
Because of this, it can be difficult to know what information in the system needs to be
managed as a record to provide evidence of the business process or transaction.

International Council on Archives Records in Business Systems
Business systems may consist of:
• a collection of data elements (or structured data) that are linked and
controlled by the system, for example, entries in a database;
• distinct digital objects controlled by the system that have a clearly defined
data format (or unstructured/semi-structured information), for example,
documents, emails or spreadsheets; or
• a combination of the above.
The process of identifying records must commence by stepping back from the IT
system itself, and undertaking an analysis of the work processes, including related
regulatory and business requirements, to determine what evidence is required to be
kept.
As records are directly linked to business processes, identifying the records is
assisted by standard business process analysis techniques and tools, such as
activity diagrams, process decompositions and flowcharts.
It is important to work closely with the organisation’s records management and
archives professionals during this process, as much of this work may have been
undertaken when developing the organisation’s records management program
(including its disposition authority).
The process of identifying the records entails two main tasks. These are:
1 identification of requirements for evidence of the business being conducted in
the business system; and
2 identification of the information that records this evidence, that is, the ‘record’.
2.3.2 Identify requirements for evidence of the business
Step 1 – determine the broad business functions and specific activities and
transactions carried out, in full or in part, by the business system
This analysis may include consideration of business process documentation and
system inputs, outputs, and related policies and procedures. In highly integrated

7 This document primarily focuses on the management of records arising from structured
rather than unstructured data.

Refer to National Archives of Australia, DIRKS Manual: A Strategic Approach to
Managing Business Information, available at http://www.naa.gov.au/records-
management/publications/DIRKS-manual.aspx for further information.
For further information on modelling business process, see the Business Process
Modelling Notation website at http://www.bpmn.org/.
While tailored to a particular jurisdiction, see Queensland State Archives, Guideline for
the Development of Retention and Disposal Schedules available at
http://www.archives.qld.gov.au/downloads/rdschedule.pdf for guidance on developing a
disposition authority.
The term ‘evidence’ is used in this document in the sense of demonstrating or
documenting the proof of a business transaction, rather than its narrower legal context.

8 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
environments, multiple systems may need to be covered in the analysis in order to
obtain a complete picture of the business process or activity. Particularly in the
government environment, systems may also be shared by multiple organisations.
Step 2 – for each function, activity and transaction or business process managed by
the system, consider what evidence is required to be retained by the
organisation
Requirements may be derived from a number of sources. Consider such issues as:
• Are there legislative obligations to record certain evidence? Some legislation
may implicitly or explicitly state the need to create certain records in certain
forms.
• Are there regulatory instruments that must be adhered to and require
evidence to demonstrate compliance, for example, mandatory standards,
codes of practice and so on?
• Are there organisational rules that require evidence be recorded, for example,
policies, codes of conduct, reporting and so on?
• What evidence is required of decisions made to support the business process
itself or to inform future decision-making?
• Are any of the business functions or activities of the organisation considered
high risk or subject to a high level of litigation that demands a greater level of
documented evidence?
• Who are the various stakeholders and what are the different expectations
they may have about what evidence is required to be retained?
• What are the community’s expectations for evidence of the work process?
This process may involve a wide range of consultation and validation with senior
management. The International Standard on Work process analysis for records,
ISO/TR 26122-2008, and the Australian DIRKS Manual are useful resources for
these purposes.
2.3.3 Identify the content and its associated management information that
record this evidence
Not all information contained in a business system will necessarily be required to be
recorded as evidence.
This analysis may have already been done, either for records management purposes
such as disposition or classification, or in the development of the system itself through
business process review.
DIRKS stands for Designing and Implementing Recordkeeping Systems. Steps A–C
cover this analysis process. For more information, see National Archives of Australia,
DIRKS Manual: A Strategic Approach to Managing Business Information available at
http://www.naa.gov.au/records-management/publications/DIRKS-manual.aspx or State
Records NSW, The DIRKS Manual: Strategies for Documenting Government Business
available at http://www.records.nsw.gov.au/recordkeeping/dirks-manual_4226.asp.

International Council on Archives Records in Business Systems
Step 3 – for each requirement for evidence, identify the content or data that make up
the evidence
In systems that manage distinct digital objects, such as word-processed documents,
data is already drawn together into a logical construct. This means that it can be
relatively easy to identify specific documents or reports that contain the content that
could act as evidence of a particular business activity or transaction.
For others, it will require analysis of the data structures, data models and class
models that underlie the system to identify the specific data elements that together
constitute the content and provide the necessary evidence (see Figures 2 and 3
below for an illustration of this).
It is important to note that the content or data that make up the evidence may not just
be within the system. It may also be in other systems, documentation about the
system, procedures, paper inputs and so on. Particularly in highly integrated
environments, parts of the required evidence may be held across multiple systems
and some systems or components may be shared with other organisations.
There may be a number of different content elements that could serve to make up
the evidence. Deciding which content is best suited to form the required evidence will
be based on an assessment of the business need and risk. Records need to be
adequate, that is, there should be sufficient evidence of the conduct of business
activity or transaction to be able to account for that conduct. Therefore a major
initiative will be extensively documented, while a routine low-risk action may be
documented with an identifiable minimum amount of information.
Figure 2 provides a representation of the contents of a database controlled by a
14 15
business system. In this example the record is made up of a grouping of related
data elements from a number of different fields. Each record will consist of the
identified data elements in the database and the associated metadata required to link
the elements and provide the necessary structure and context to support the record.

14 Figure 2 provides a view of a normalised database. Relational database concepts,
standard data modelling and normalisation techniques should be enforced to provide the
necessary structure and context to support the traceability of the record.
15 ‘Record’ is used here in the records management sense rather than its database
meaning.
10 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
Figure 2: Identification of information components/data elements comprising a digital
record in a database
Business system
Database
Table Table Table
Field Field Field Field Field
Field
Digital record
Data Data Data Data Data Data
Data Data Data Data Data Data
Data Data Data Data Data Data
Digital record
Data Data Data Data Data Data
Note that it is possible for a single record to include multiple elements from a single database field or table, and that it
is also possible for a single data element to form part of more than one record.

International Council on Archives Records in Business Systems
Figure 3 provides a simplistic example of the tables that comprise a portion of a
relational database for a human resource management system. Each table
represents a portion of the database that contains closely linked information. Tables
A, B and C provide data relating to personnel, salaries and cost centres,
respectively. Tables D and E provide linkages between the data elements in the
other tables. Table D links staff with their relevant pay levels, while Table E links staff
with their cost centres.
Each table consists of a number of columns that represent fields containing data
elements. The rows within each table establish linkages between data elements
within the different fields. In database literature, these rows within tables are
sometimes referred to as ‘records’, although these linked data elements are not
always records in the records management sense of the term.
In line with the business process analysis, there are a number of potential records in
Figure 3. These records are represented as a number of inter-related data elements
that may be connected across one or more tables and comprise data elements from
one or more fields.
12 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
Figure 3: Further example of the identification of information components/data
elements comprising a digital record in a database

Table A: Personnel
Staff no. Surname First name Address City
0078652 Larsen Sevren 78/1 Hoddle St, Carlton Melbourne
0078653 Lee Jamie 55 Ramsey St, Vermont Melbourne
0078654 Smith Bob 7 Pollie Crt, Barton Canberra
0078655 Schmidt Helmutt 1/123 North Rd, Balmain Sydney
0078656 Darcy Kyra 67 Green St, Mt Lawley Perth

Table B: Salaries Table C: Cost centres
Pay code Level Year Pay rate Staff no. Pay code
A41 APS4 Year 1 $45,000 0078652 A53
A42 APS4 Year 2 $46,000 0078653 A42
A43 APS4 Year 3 $47,000 0078654 A42
A44 APS4 Year 4 $48,000 0078655 A41
A51 APS5 Year 1 $54,000 0078656 A51
A52 APS5 Year 2 $55,000
A53 APS5 Year 3 $56,000
Table D: Staff to pay levels Table E: Staff to cost
centres
Centre code Cost centre Director Staff no. Centre code
M001 Melbourne Office Shay Jones 0078652 M001
S001 Sydney Office Fred Nguyen 0078653 M001
P001 Perth Office Alberta Johnson 0078654 C001
C001 Canberra Office John Wasp 0078655 S001
0078656 P001
Key
Yellow Data elements comprising the personnel record of Kyra Darcy

Tourquoise Data elements comprising the record of Bob Smith’s address details

Pink Data elements comprising the record of Melbourne Office staff

International Council on Archives Records in Business Systems
Three distinct types of records have been identified in the system:
• The yellow rows identify data elements that form a single personnel record.
This record spans data elements in all five tables and contains information on
the staff member, name, address, salary level and cost centre.
• The tourquoise row identifies data elements that provide a record of an
individual’s name, address and staff number. This single row of information
could be construed as a record, but in this case the record indicated by the
yellow rows is more comprehensive and would be preferable.
• The pink rows identify data elements that form a record of all staff members
belonging to a particular cost centre. These rows may represent an
alternative method of interrogating the data contained in the tables.
Note that the information contained in Table B does not constitute a record in this
scenario, only part of the staff salary record. This is because the data contained in
Table B is supplemental and only gains value as a component of a record when it is
placed in context of a staff member in Table A. The Table B information itself is likely
to have come from an external record such as a workplace agreement.
It should be noted that there may, in some instances, be overlap between records
identified in a database. The data elements that form part of one record in a
relational database may also form part of other records generated by the same
database. For example, the staff record of ‘Jamie Lee’ and the record of Melbourne
office staff will both draw on the same data elements from Table A.
Where overlap occurs between the data elements that form digital records, the
business system must be capable of ensuring that it will not destroy the shared data
elements until both identified digital records have reached their minimum retention
period.
Step 4 – identify the additional information required to manage the content over time
as evidence
This will be the records metadata that is an integral part of the record. Records
metadata can be used to control the length of time a record is maintained, establish
its access rights and restrictions, and facilitate searching for and retrieval of the
record.
The creation, capture and management of metadata for records are essential to
allow records to be identified, understood and retrieved, and to protect the evidence
of their authenticity, reliability and integrity. Metadata should be captured in line with
an identified metadata standard for records, as stipulated by jurisdictional and/or
organisational requirements.
Metadata does not need to be retained together with the content, as long as they are
linked or associated in some way. Metadata may be contained in systems external to
the business system in question, or may encompass documentation or tools such as
XML schemas and data, and class models that allow records to be understood and
remain meaningful over time.
14 © ISO 2010 – All rights reserved

International Council on Archives Records in Business Systems
Particularly in database environments, it can be difficult to distinguish between the
record’s content and its metadata. For example, metadata that provides evidence
that a particular
...