basic template for the development of iso and iso/iec...

CD ISO/IEC 15944-12:2014(E)

INTERNATIONAL STANDARD

ISO/IEC15944-12

Committee Draft (CD)2014-08-31

Information technology — Business Operational View —Part 12:

Privacy protection requirements on information life cycle management (ILCM) and EDI of personal information

Technologies de l'information — Vue opérationnelle d'affaires —Partie 12: Exigences en matière de protection de la vie privée relatives à la gestion du cycle de vie de l’information (ILCM) et de l'EDI des renseignements personnels

© ISO/IEC 2014 – All rights reserved I

1

2

CD ISO/IEC 15944-12:2014(E)

Contents Page

0 Introduction................................................................................................................................ ix0.1 Purpose and overview............................................................................................................... ix0.2 Use of ISO/IEC 14662 “Open-edi Reference Model” and Business Operational View (BOV)

perspective.................................................................................................................................. x0.2.1 ISO/IEC 14662 "Open-edi Reference Model"............................................................................x0.2.2 ISO/IEC 15944-1 “Business Agreement Semantic Descriptive Techniques” (“Business

Operational View (BOV”))..........................................................................................................xi0.2.3 Link to ISO/IEC 15944-5 and ISO/IEC 15944-8.......................................................................xiii0.3 Use of “Person”, “organization”, “individual” and “party” in the context of business

transaction and commitment exchange.................................................................................xiii0.4 Importance and role of terms and definitions.......................................................................xiv0.5 Standard based on rules and guidelines................................................................................xv0.6 Use of “identifier” (in a business transaction) and roles of an individual..........................xvi0.7 Use of "jurisdictional domain" in the context of privacy protection and related ILCM

requirements........................................................................................................................... xvii0.8 Use of “privacy protection” in the context of business transaction and commitment

exchange................................................................................................................................. xvii0.9 Use of set of recorded information (SRI) and set op personal information versus record,

document, message, etc.......................................................................................................xviii0.10 Organization and description of this document....................................................................xix1 Scope......................................................................................................................................... 201.1 Statement of scope................................................................................................................... 201.2 Exclusions................................................................................................................................. 211.2.1 Functional Services View (FSV)...............................................................................................211.2.2 Internal behaviour of organizations (and public administration)..........................................211.2.3 “organization Person”..............................................................................................................211.2.4 Overlap of and/or conflict among jurisdictional domains as sources of privacy protection

requirements............................................................................................................................. 221.2.5 Publicly available personal information..................................................................................221.3 Aspects currently not addressed............................................................................................241.4 IT-systems environment neutrality..........................................................................................282 Normative references...............................................................................................................292.1 ISO/IEC, ISO and ITU................................................................................................................. 292.2 Referenced specifications........................................................................................................313 Terms and definitions...............................................................................................................314 Symbols and abbreviations.....................................................................................................645 Fundamental privacy protection principles............................................................................685.1 Introduction............................................................................................................................... 685.2 Primary sources of privacy protection principles..................................................................685.3 Key eleven (11) privacy protection principles........................................................................695.4 Privacy protection principles in the context of ILCM requirements.....................................695.4.1 Privacy protection principle 1: Preventing harm....................................................................695.4.2 Privacy protection principle 2: Accountability.......................................................................705.4.3 Privacy protection principle 3: Identifying purposes.............................................................705.4.4 Privacy protection principle 4: Informed consent..................................................................715.4.5 Privacy Protection Principle 5: Limiting Collection...............................................................715.4.6 Privacy Protection Principle 6: Limiting Use, Disclosure and Retention.............................725.4.7 Privacy Protection Principle 7: Accuracy...............................................................................745.4.8 Privacy Protection Principle 8: Safeguards............................................................................755.4.9 Privacy Protection Principle 9: Openness..............................................................................765.4.10 Principle Protection Principle 10: Individual Access.............................................................765.4.11 Privacy Protection Principle 11: Challenging Compliance....................................................765.5 Requirement for tagging (or labelling) data elements in support of privacy protection

requirements............................................................................................................................. 77

II © ISO/IEC 2014 – All rights reserved

3

1

23456789101112131415161718192021

2223242526272829303132

333435

36

37

383940414243444546474849505152535455

CD ISO/IEC 15944-12:2014(E)

6 Integrated set of information life cycle management (ILCM) principles in support of information law and privacy protection requirements...........................................................78

6.1 Introduction – Primary purpose of Clause 6...........................................................................786.2 Information life cycle management (ILCM) principles in support of privacy protection

requirements............................................................................................................................. 796.2.1 Compliance with privacy protection (and associated information law) requirements.......796.2.2 Direct Relevance....................................................................................................................... 806.2.3 Timely, accurate, relevant and “under control”.....................................................................806.2.4 Integrity and quality.................................................................................................................. 806.2.5 Safeguards for non-authorized disclosure requirements.....................................................806.2.6 Back-up, retention and archiving............................................................................................806.2.7 Disposition and expungement.................................................................................................816.2.8 Organizational archiving..........................................................................................................816.2.9 Historical, statistical and/or research value...........................................................................817 Rules governing the specification of ILCM aspects of personal information......................847.1 Introduction............................................................................................................................... 847.2 Rules governing establishing ILCM responsibilities for personal information...................857.3 Rules governing establishing specifications for retention of personal information –

applicable “SRI retention triggers”.........................................................................................877.4 Rules governing identification and specification of state changes of personal information917.4.1 Introduction............................................................................................................................... 917.4.2 Specification of state changes allowed to personal information..........................................927.4.3 Specification of store change type..........................................................................................957.4.4 Rules governing specification of source of state changes...................................................977.5 Rules governing disposition of personal information...........................................................988 Rules governing EDI of personal information between primary ILCM Person, i.e., the

seller, and its “agent”, “third party” and/or “regulator”......................................................1038.1 Introduction............................................................................................................................. 1038.2 ILCM rules pertaining to use of an “agent”..........................................................................1038.3 ILCM rules pertaining to use of a “third party”....................................................................1048.4 ILCM rules pertaining to involvement of a “regulator”........................................................1059 Data conversion, data migration, and data synchronization..............................................1079.1 Introduction............................................................................................................................. 1079.2 Rules governing data conversion and data migration of personal information................1079.3 Rules governing requirements for data synchronization of personal information...........10810 Conformance statement.........................................................................................................11010.1 Introduction............................................................................................................................. 11010.2 Conformance to the ISO/IEC 14662 Open-edi Reference Model and the multipart

ISO/IEC 15944 eBusiness standard.......................................................................................11010.3 Conformance to ISO/IEC 15944-12........................................................................................11010.4 Conformance by agents and third parties to ISO/IEC 15944-12..........................................110Annex A (normative) Consolidated list of terms and definitions with cultural adaptability: ISO

English and ISO French language equivalency....................................................................112A.1 Introduction............................................................................................................................. 112A.2 ISO English and ISO French..................................................................................................112A.3 Cultural adaptability and quality control...............................................................................112A.4 Organization of Annex A – Consolidated list in matrix form...............................................113A.5 List of added Part 12 terms and definitions with cultural adaptability: ISO English and ISO

French...................................................................................................................................... 114Annex B (normative) Consolidated set of rules in existing Parts of ISO/IEC 15944 of particular

relevance to privacy protection requirements as external constraints on business transactions which apply to personal information in an ILCM requirements context......120

B.1 Introduction............................................................................................................................. 120B.2 Organization of Annex B: Consolidated list in matrix form................................................120B.3 Consolidated list of rules in ISO/IEC 15944-1 pertaining to external constraints relevant to

supporting privacy protection requirements........................................................................121

© ISO/IEC 2014 – All rights reserved III

5

5657585960616263646566676869

7071727374757677787980

818283848586

87888990

919293949596

979899100101102103104

105106107108109110111

6

CD ISO/IEC 15944-12:2014(E)

B.4 Consolidated list of rules in ISO/IEC 15944-2 pertaining to external constraints of relevance to supporting privacy protection requirements..................................................124




Annex C (normative) Linking ILCM to process phases of a business transaction.......................145C.1 Introduction............................................................................................................................. 145C.2 Rules governing linkages of ILCM process to process component of the Business

Transaction Model (BTM).......................................................................................................145C.3 Figurative overview of linking the five phases of the process component of the Business

Transaction Model (BTM) to ILCM requirements..................................................................146Annex D (normative) Generic approach to I*LCM decisions in a privacy protection requirements

context – ILCM decision template.........................................................................................148D.1 Introduction............................................................................................................................. 148D.2 Generic approach to ILCM decisions in a privacy protection requirements context........148D.2.1 Link to applicable records and retention and disposal of personal information and

“transitory records”................................................................................................................148D.2.2 Link to “post actualization” requirements............................................................................150Annex E (Informative) Generic approach to identification of properties and behaviours of

personal information as SRI transitory records and their disposition/expungement.......152E.1 Introduction............................................................................................................................. 152E.2 Definition of the concept of “SRI transitory record”............................................................153E.3 Information on examples of “SRI transitory records”.........................................................153Bibliography......................................................................................................................................... 155Abstracts................................................................................................................................................ 157

Figures..........................................................................................................................................PageFigure 1 — Open-edi environment – Open-edi Reference Model........................................................xFigure 2 — Integrated view - Business operational requirements: External constraints focus.....xiiFigure 3 — Primary sources for privacy protection principles..........................................................68

Figure C.1 Overview- linking the five phases of the process component of the Business Transaction Model (BTM) to ILCM requirements..........................................................147

Figure D.1 Decision Tree Diagram for identification and disposition of a SPI from an ILCM requirements perspective (including it being declared a transitory record”............149

Tables ........................................................................................................PageTable 1 — ISO/IEC 15944-12:01 Codes representing specification of records retention

responsibility for personal information...........................................................................86Table 2 — ISO/IEC 15944-12:02 Codes representing SRI retention triggers for retention of

personal information.........................................................................................................88Table 3 — ISO/IEC 15944-12:03 Codes representing the specification of types of record

retention period.................................................................................................................90Table 4 — ISO/IEC 15944-12:04 Codes for specifying whether state changes allowed for the

content values of SRIs containing personal information...............................................94Table 5 — ISO/IEC 15944-12:05 Codes representing store change type for SPIs (and SRIs).......96Table 6 — ISO/IEC 15944-12:06 Codes representing source of state change type ID code for

SRIs..................................................................................................................................... 97

IV © ISO/IEC 2014 – All rights reserved

7

112113114115116117118119

120121122123124125

126127128129130131132

133134135136137

138

139140

141142143144145146147148149150151152

153154155156157158159160161162163164

CD ISO/IEC 15944-12:2014(E)

Table 7 — ISO/IEC 15944-12:07 Codes representing disposition types as actions of personal information (as SPIs).......................................................................................................101

Table A.1 — Columns in Table A.2....................................................................................................113Table A.2 — List of added Part 12 terms and definitions with cultural adaptability of: ISO English

and ISO French language equivalency.......................................................................114

© ISO/IEC 2014 – All rights reserved V

9

165166167168169170171172

173

10

CD ISO/IEC 15944-12:2014(E)

Project Co-Editors’ Notes:

NOTE: All Project Co-Editors’ Notes below and throughout this document are temporary and apply to this CD document only. They will be removed in the preparation of the next version.

1. The Project Co-Editors Notes are based on those found in SC32/WG1 N0752 document amended as per events leading to the cancellation of the SC32/WG1, June 2014 Beijing meetings. {See SC32/WG1 N0752 and item #5 and #6 below.

2. This document replaces SC32/WG1 N725 1st WD for Part 12 as well as N0752 (see item #5 below).

3. This document implements the results of the Santa Fe, November, 2013 interim meeting of SC32/WG1, including documents SC32 WG1 N0726 and N07331, the Santa Fe resolutions re: Part 12.

4. The Santa Fe WG1 meeting basically resolved possible issues with respect to the overall approach and especially several technical aspects. The development of this CD document identified no new technical issues.

5. Based on the results of the Santa Fe meeting, the progressing of development was foreseen as:

5.1 Development of a draft CD for review, discussion and advice/decision at the scheduled Beijing 9-13 June, 2014 SC32/WG1 meeting. {see a document was prepared by the Project Co-Editors and posted as SC32/WG1 N0742, dated 2014-05-30}

5.2 The results of the Beijing meeting would be incorporated into the preparation of the CD ballot document in time for the CD Part 12 ballot to close at least two weeks prior to the start of the November, 2014 SC32/WG1 interim meeting. Following the Comment Resolution Meeting (CRM) in November, 2014 (and positive results), the next step was the preparation of the DIS ballot document for Part 12 and its posting in time for the DIS ballot to close two weeks prior to the spring 2015 SC32/WG1 Plenary meeting; and,

5.3 Since in Santa Fe, all the key technical issues were resolved, the key objective of the Project Co-Editors was the completion of necessary normative and informative text in the Clauses and Annexes in the preparation of this CD ballot document.

6 Progression of Part 12 development resulting from cancellation of SC32/WG1 Beijing meeting, June 9-13, 2014

6.1 Due to unforeseen events, key members of the SC32/WG1 were not able to attend the planned SC32/WG1 Beijing 9-13 June, 2014schedule meeting. As a result this SC32/WG1 meeting was cancelled by the Convener (See document SC32/WG1 N0752) who stated “All the items listed in the draft agenda will be discussed by following emails and the next WG1 meeting”.

6.2 Based on emails among the Convener, the Project Co-Editors and members of SC32/WG1 and comments received on the draft CD for ISO/IEC 15944-12, this CD ballot document has been prepared. It also incorporates the SC32/WG1 N0743 document “Case study – Mandatory expungement”.

6.3 Further, since at the previous Santa Fe meeting of SC32/WG1, all the key technical issues were addressed and resolved, the SC32/WG1 Convener with the agreement of the Project Co-Editors decided that a two (2) month CD ballot comment period is sufficient.

7 As was noted in the Project Co-Editors Notes for the draft CD document (N0742), the one new item is Annex Y (now Annex D) tentatively titled “Template for implementation of ILCM in support of privacy protection requirements”. Thus, as the coming next meeting of SC32/WG1 12-13 November, 2014 Toronto, meeting this new Annex D will be examined carefully. Ballot comments on this Annex are most welcome.

VI © ISO/IEC 2014 – All rights reserved

11

174

175

176177

178179180

181

182183

184185186

187

188189190

191192193194195196

197198199

200201

202203204205

206207208

209210211

212213214215216

CD ISO/IEC 15944-12:2014(E)

8 Further, comments received on the draft CD document requested added information on the concept of “transitory record” along with examples. To this end text for a new Annex E (informative) has been added.

9 It is important that P-members review the coded domains presented as tables in this document and particular the entries (or rows) in each coded domain. Many of the coded domains in the Part 12 are based on those of a more generic nature as found in Part 5 and/or Part 8. IN this Part 12, they are further developed in an ILCM context and at a more granular level. P-members are therefore requested to review them in detail and recommend any changes or additions as may be required.

10 Finally, constraints on available time and resources of the Project Co-Editors for Part 12 did not yet allow for a necessary detailed review of possible applicable standards of ISO TC46/SC11 Archives/Records Management and in particular the following:

ISO 13008-12 Information and document - Digital records conversion and migration practice;

the multipart ISO 15489 – Information and document management

Part 1 (2001) – General Concepts and principles (being revised and renamed)

Part 2 (2001) Guidelines (being revised)

11 These and other relevant ISO TC46/SC11 standards are in the process of being revised. The Project Co-Editors will be making a contribution on this matter for the upcoming Toronto November, 2014 interim meeting of JTC1/SC32/WG1.

© ISO/IEC 2014 – All rights reserved VII

13

217218

219220221222223

224225226

227

228

229

230

231232233

234

14

CD ISO/IEC 15944-12:2014(E)

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

ISO/IEC 15944-12 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 32, Data management and interchange.

ISO/IEC 15944 consists of the following parts, under the general title Information technology — Business Operational View:

Part 1: Operational aspects of Open-edi for implementation

Part 2: Registration of scenarios and their components as business objects**

Part 4: Business transaction scenarios — Accounting and economic ontology**

Part 5: Identification and referencing of requirements of jurisdictional domains as sources of external constraints**

Part 6: Technical introduction to e-Business modelling [Technical Report]**

Part 7: eBusiness vocabulary**

Part 8: Identification of privacy protection requirements as external constraints on business transactions**

Part 9: Business transaction traceability framework for commitment exchange*

Part 10: IT-enabled coded domains as semantic components in business transactions

Part 11: Descriptive Techniques for Foundational Modelling in Open-edi*

Part 20: Linking business operational view to functional service view*

* Indicates that standard is under preparation. ** Indicates the standard is undergoing review under the “minor revision” process.

VIII © ISO/IEC 2014 – All rights reserved

15

235

236237238239240241242

243

244245246

247248

249250

251252

253

254

255

256257

258

259

260

261

262

263

264

265266

CD ISO/IEC 15944-12:2014(E)

0 Introduction


1. The text for Clause 0 and its sub-clauses is based on that found in Part 8. It has been amended and abridged where appropriate, as well as being placed in a Part 12 context.

2. It could be that some further additions or revisions, or deletions or additions will be made to Clause 0 and its sub-clauses. If so, these should be identified through CD ballot comments.

0.1 Purpose and overview

Modelling business transactions using scenarios and scenario components included specifying the applicable constraints on the data content using explicitly stated rules. The ISO/IEC 14662 Open-edi Reference Model identified two basic classes of constraints, "internal constraints" and "external constraints". External constraints apply to most business transactions.

Jurisdictional domains are the primary source of external constraints on business transactions. Privacy protection requirements in turn are a common requirement of most jurisdictional domains, although they may also result from explicit scenario demands from or on the parties involved in a business transaction. (Requirements for secrecy or confidentiality are not addressed in this part of ISO/IEC 15944, unless they are implicitly needed to apply privacy protection requirements to data).

This Part of ISO/IEC 15944 describes the added business semantic descriptive techniques needed to support information life cycle management (ILCM) aspects as part of privacy protection requirements when modelling business transactions using the external constraints of jurisdictional domains. ILCM aspects are central to the ability to ensure that privacy protection requirements are passed on and supported among all the parties to a business transaction using EDI.

In addition to the existing strategic directions of "portability" and "interoperability", the added strategic direction of ISO/IEC JTC1 of "cultural adaptability" is also supported in this part of ISO/IEC 15944. The external constraints of jurisdictional domains as a primary factor in choice and use of language and application of public policy are also addressed.

This standard applies to any organization which receives, creates, process, maintains, communicates, etc. personal information and in particular to those who receive, create, capture, maintain, use, store or dispose of records electronically. This standard applies to private and public sector activities of Persons irrespective of whether such activities are undertaken on a for-profit or not-for-profit basis.

This standard is intended for use by those organizations to which privacy protection requirements apply and who therefore need to ensure that the recorded information (electronic records and transactions) in their IT Systems is trustworthy, reliable and recognized as authentic. Typical users of this standard include

a) managers of private and public sector organizations;

b) IT Systems and records/information management system professionals;

c) Privacy protection officers (PPOs) and other personnel in organizations, including those responsible for risk management; and

d) legal professionals and others within an organization responsible for information law compliance by the organization.

© ISO/IEC 2014 – All rights reserved IX

17

267

268

269270

271272

273

274275276277

278279280281282

283284285286287

288289290291

292293294295

296297298

299

300

301302

303304

305

18

CD ISO/IEC 15944-12:2014(E)

0.2 Use of ISO/IEC 14662 “Open-edi Reference Model” and Business Operational View (BOV) perspective1

0.2.1 ISO/IEC 14662 "Open-edi Reference Model"2

The ISO/IEC 14662 Open-edi Reference Model3 states the conceptual architecture necessary for carrying out electronic business transactions among autonomous parties. That architecture identifies and describes the need to have two separate and related views of the business transaction.

The first is the Business Operational View (BOV). The second is the Functional Service View (FSV). Figure 1 from ISO/IEC 14662:2010 illustrates the Open-edi environment. {For definitions of the terms used in Figure 1, please see Clause 3 below}

Figure 1 — Open-edi environment – Open-edi Reference Model

ISO/IEC 14662:2010, Clause 5 states:

"The intention is that the sending, by an Open-edi Party, of information from a scenario, conforming to Open-edi standards, shall allow the acceptance and processing of that information in the context of that scenario by one or more Open-edi Parties by reference to the scenario and without the need for agreement.

1 While “public administration” is one of the three distinct sub-types of Person, most of the rules in this Part applicable to “organization” also apply to “public administration”. In addition, an unincorporated seller is also deemed to function as an “organization”. Consequently, the use of “organization” throughout this part of ISO/IEC 15944 also covers “public administration”. Where it is necessary to bring forward specific rules, constraints, properties, etc., which apply specifically to “public administration”, this is stated explicitly.

2 The ISO/IEC 14462 Open-edi Reference Model serves as the basis of the 2000 Memorandum of Understanding (MOU) among ISO, IEC, ITU and the UN/ECE concerning standardization in the field of electronic business. {See http://www.itu.int//ITU-T/e-business/files/mou.pdf }

3 ISO/IEC 14662:2010 (3rd ed. E/F) "Information technology — Open-edi Reference Model/Technologies de l'information — Modèle de référence EDI-ouvert". {It is an ISO “freely available standard}

X © ISO/IEC 2014 – All rights reserved

19

306307

308

309310311

312313314

315

316

317

318319320321

2021222324

252627

2829

http://www.itu.int//ITU-T/e-business/files/mou.pdf

CD ISO/IEC 15944-12:2014(E)

However, the legal requirements and/or liabilities resulting from the engagement of an organization in any Open-edi transaction may be conditioned by the competent legal environment(s) of the formation of a legal interchange agreement between the participating organizations. Open-edi Parties need to observe rule-based behaviour and possess the ability to make commitments in Open-edi, (e.g., business, operational, technical, legal, and/or audit perspectives)".

ISO/IEC 15944-1:2011 in Clause 7 "Guidelines for scoping Open-edi Scenarios" states in Clause 7.1:

"The approach taken is that of identifying the most primitive common components of a business transaction and then moving from the general to the more detailed, the simplest aspects to the more complex, from no external constraints on a business transaction to those which incorporate external constraints, from no special requirements on functional services to specific requirements, and so on".

This Part of ISO/IEC 15944 focuses on addressing commonly definable aspects of external context4 constraints that relate to information life cycle management (ILCM) in a privacy and data protection when the source is a jurisdictional domain. A useful characteristic of external constraints is that, at the sectoral level, national and international levels, etc., focal points and recognized authorities often already exist. The rules and common business practices in many sectoral areas are already known. Use of this Part of ISO/IEC 15944 (and related standards) addresses the transformation of these external constraints (business rules) into specified, registered, and re-useable scenarios and scenario components.

0.2.2 ISO/IEC 15944-1 “Business Agreement Semantic Descriptive Techniques” (“Business Operational View (BOV”))

ISO/IEC 15944-1 states the requirements of the BOV aspects of Open-edi in support of electronic business transactions. They shall be taken into account in the development of business semantic descriptive techniques for modelling e-business transactions and components thereof as re-useable business objects. They include:

commercial frameworks and associated requirements;

legal frameworks and associated requirements;

public policy requirements particularly those of a generic nature such as consumer protection, privacy, accommodation of handicapped/disabled;

requirements arising from the need to support cultural adaptability. This includes meeting localization and multilingual requirements, (e.g., as may be required by a particular jurisdictional domain or desired to provide a good, service and/or right in a particular market. Here one needs the ability to distinguish, the specification of scenarios, scenario components, and their semantics, in the context of making commitments, between:

a) the use of unique, unambiguous and linguistically neutral identifiers (often as composite identifiers) at the information technology (IT) interface level among the IT systems of participation parties on the one hand; and, on the other,

b) their multiple human interface equivalent (HIE) expressions in a presentation form appropriate to the Persons involved in the making of the resulting commitments.

Figure 2 shows an integrated view of these business operational requirements. It is based on Figure 3 from ISO/IEC 15944-1. Since the focus of Part 12 of ISO/IEC 15944 is that of external constraints for which jurisdictional domains are the primary source these primary sources have been shaded in Figure 2 below).

4 “Privacy protection” is the common set of world-wide requirement. In the European Union “data protection” is the equivalent concept mainly due to historical reasons.

© ISO/IEC 2014 – All rights reserved XI

31

322323324325326

327

328329330331

332333334335336337338

339340

341342343344

345

346

347348

349350351352353

354355356

357358

359360361

3233

34

CD ISO/IEC 15944-12:2014(E)

XII © ISO/IEC 2014 – All rights reserved

Commercial Framework & Requirements

Legal Framework & Requirements

Public Policy Req’mts (Privacy protection, Consumer)

Information Technology Requirements & Standards

Sectoral (& cross-sectoral) Req’mts

Telecom-munications Req’mts & Standards

Business Transactions

(Open-edi based)

Characteristics of Open-ediRule-BasedCommitment ExchangeUnambiguous IdentificationBusiness Transaction Model (BTM)Key Components

Person

Process

Data

Business Transaction Model: Classes of ConstraintsSpecification, Identification & Classification of Open-edi scenarios (and components)FSV Business Demands on Open-edi Support InfrastructureOpen-edi Scenario Templates(For use in various applications areas such as: e-commerce, e-administration, e-business, e-logistics, e-government, e-learning, e-medicine etc.)

Sources of Requirements on the Business Operational View (BOV) aspects of Open-edi which need to be integrated and/or taken into account

Cultural Adaptability Localization & Multilingualism

(IT vs Human Interface)

Functional Services View (FSV)

ISO & Other Standards Environments

35

362

363

364

365

366

367

CD ISO/IEC 15944-12:2014(E)

Figure 2 — Integrated view - Business operational requirements: External constraints focus

© ISO/IEC 2014 – All rights reserved XIII

37

368

369

370

38

CD ISO/IEC 15944-12:2014(E)

In electronic business transactions, whether undertaken on a for profit or not-for-profit basis, the key element is commitment exchange among Persons made through their Decision Making Applications (DMAs) of their Information Technology Systems (IT Systems)5 acting on behalf of "Persons". "Persons" are the only entities able to make commitments6.

The Business Operational View (BOV) was therefore defined as:

“perspective of business transactions limited to those aspects regarding the making of business decisions and commitments among Persons which are needed for the description of a business transaction".

[ISO/IEC 14662:2010, 3.3]

There are three categories of Person as a role player in Open-edi, namely: (1) the Person as "individual", (2) the Person as "organization", and (3) the Person as "public administration". There are also three basic (or primitive) roles of Persons in business transactions, namely: "buyer", "seller", and "regulator". When modelling business transactions, jurisdictional domains prescribe their external constraints in the role of "regulator" and execute them as "public administration".

0.2.3 Link to ISO/IEC 15944-5 and ISO/IEC 15944-8

Part 5 of ISO/IEC 15944 focuses on external constraints the primary source of which is jurisdictional domains, at various levels. This ISO standard also identified a common class of external constraints known as “public policy”, which apply where and when the “buyer” in a business transaction is an “individual”. It identified three key sub-types, along with applicable rules; of public policy constraints, namely: “consumer protection”, “privacy protection” and “individual accessibility”7. (There are others). In addition, Part 5 of ISO/IEC 15944 specifies how and where (common) external constraints of jurisdictional domains impact the “Person”, “process”, and “data “components of the business transaction model (BTM), as introduced in Part 1 of ISO/IEC 15944.

Part 8 of ISO/IEC 15944, which is based on Part 5, focuses on providing a more detailed identification and specification of the common privacy protection requirements as they apply to any business transaction where the buyer is an individual.

This Part 12 of ISO/IEC 15944 is (a) based on both Part 5 and Part 8, (b) integrates applicable concepts and definitions, principles, rules, etc., found in both Parts 5 and Part 8; and, (c) focuses on information life cycle management (ILCM) aspects at a more granular level, i.e., that required to be able to support implementation of the same.

0.3 Use of “Person”, “organization”, “individual” and “party” in the context of business transaction and commitment exchange

Throughout this part of ISO/IEC 15944:

the use of Person with a capital "P" represents Person as a defined term, i.e., as the entity within an Open-edi Party that carries the legal responsibility for making commitment(s);

"individual", "organization", and "public administration" are defined terms representing the three common sub-types of "Person"; and,

5 See further Clause 5.2 "Functional Services View" in ISO/IEC 14662:2010 "Open-edi Reference Model" (3rd edition).

6 The text in this section is based on existing text in Section "0.3" in ISO/IEC 15944-1:2011 and ISO/IEC 14662:2010 (3rd edition).

7 See further Clause 6.3 “Jurisdictional domains and public policy requirements” in ISO/IEC 15944-5.”….. Part 5: Identification and referencing of requirements of jurisdictional domains and sources of external constraints”

XIV © ISO/IEC 2014 – All rights reserved

39

371372373374

375

376377378

379

380381382383384

385

386387388389390391392393

394395396

397398399400

401402

403

404405

406407

40

4142

4344

CD ISO/IEC 15944-12:2014(E)

the words "person(s)" and/or "party (ies)" are used in their generic contexts independent of roles of "Person" as defined in the ISO/IEC 14662 and ISO/IEC 15944-1 standards. A "party" to a business transaction has the properties and behaviours of a "Person”.

In electronic business transactions, whether undertaken on a for profit or not-for-profit basis, the key element of any type of business transaction is commitment exchange among Persons made through their Decision Making Applications (DMAs) of the Information Technology Systems (IT Systems) 8 acting on behalf of "Persons". "Persons" are the only entities able to make commitments9.

There are three categories, i.e. sub-types, of Persons as players in Open-edi, namely (1) the Person as "individual", (2) the Person as "organization", and (3) the Person as "public administration". There are also three basic (or primitive) roles of Persons in business transactions, namely "buyer", "seller", and "regulator".

In modelling business transactions, jurisdictional domains prescribe their external constraints in the role of "regulator" and execute them as "public administration". {See Clause 5.4 in ISO/IEC 15944-1}

These three sub-types of Persons are also the possible Source Authorities for coded domains. On the whole, Source Authorities for coded domains are either "organizations" or "public administrations".

In this part of ISO/IEC 15944:

the use of Person with a capital "P" represents Person as a defined term, i.e. as the entity within an Open-edi Party that carries the legal responsibility for making commitment(s);

"individual", "organization", and "public administration" are defined terms representing the three common sub-types of "Person"; and,

the words "person(s)" and/or "party(ies)" are used in their generic contexts independent of roles of "Person" as defined in ISO/IEC 14662:2004 and ISO/IEC 15944-1. A "party" to a business transaction has the properties and behaviours of a "Person".

0.4 Importance and role of terms and definitions10

ISO/IEC Directives Part 2 provide for “Terms and definitions” as a “Technical normative element,” necessary for the understanding of certain terms used in the document, where the words have special, extended or technical meaning.

The ISO/IEC 15944 multipart standard sets out the processes for achieving a common understanding of the Business Operational View (BOV) from commercial, legal, ICT, public policy and cross-sectoral perspectives. It is therefore important to check and confirm that a “common understanding” in any one of these domains is also unambiguously understood as identical in the others.

This sub-clause is included in each part of ISO/IEC 15944 to emphasize that harmonized concepts and definitions (and assigned terms) in its Parts are essential to the continuity of the overall standard. Definitions and their assigned terms should be established as early as possible in the development process. Comments on any definition/term pair should address the question of changes needed to avoid possible misinterpretation. Definitions may need to be amended/improved as part of the harmonization of definitions and their assigned terms among the various parts of ISO/IEC 15944.

8 For the applicable normative elements here, see further in ISO/IEC 14662:2010, Clause 5.2 “Functional Services View”.

9 The text in this section is based on existing text in 0.3 in ISO/IEC 15944-1:2011 and ISO/IEC 14662:2010.

10 All the terms and definitions of the current editions of the ISO/IEC 14662 Open-edi Reference Model and the multipart ISO/IEC 15944 eBusiness standard have been consolidated in ISO/IEC 15944-7:2009. A primary reason for having “Terms and definitions” in a standard is because one cannot assume that there exists a common understanding, worldwide, for a specific concept. And even if one assumes that such an understanding exists, then having such a common definition in Clause 3 serves to formally and explicitly affirm (re-affirm) such a common understanding, i.e., ensure that all parties concerned share this common understanding as stated through the text of the definitions in Clause 3.

© ISO/IEC 2014 – All rights reserved XV

46

408409410

411412413414

415416417

418419

420421

422

423424

425426

427428429

430

431432433

434435436437

438439440441442443

47

48

49505152535455

56

CD ISO/IEC 15944-12:2014(E)

In order to minimize ambiguity in the definitions and their associated terms, each definition and its associated term has been made available in at least one language other than English in the part in which it is introduced. In this context, it is noted that ISO/IEC 15944-7 eBusiness vocabulary already also contains human interface equivalents (HIEs) in ISO Chinese, ISO French, and ISO Russian. The designation ISO before a natural language refers to the use of that natural language in ISO standards, and has no other meaning.

Normative Annex A “Consolidated list of terms and definitions with cultural adaptability: ISO English and ISO French language equivalency” is derived from Clause 3 of each part of ISO/IEC 15944 Annex A here contains only those concepts/definitions and associated assigned terms introduced for the first time in this Part 12.

0.5 Standard based on rules and guidelines11

This part of ISO/IEC 15944 is intended to be used within and outside of the ISO and IEC by diverse sets of users having different perspectives and needs {See above Figure 2 in Clause 0.2}.

In an ISO, IEC, ISO/IEC JTC1 context, a standard is considered to be a:

"documented agreement containing technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose."12

[ISO/IEC 15944-1:2011, 3.64]

This Business Operational View (BOV) standard focuses on "other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose".

Open-edi is based on rules which are predefined and mutually agreed to. They are precise criteria and agreed upon requirements of business transactions representing common business operational practices and functional requirements.

Clause 5 “Characteristics of Open-edi” in ISO/IEC 15944-1:2011 defines the “Business Operational View (BOV)” type of Open-edi standards as “rule-based” standards13. Of particular relevance here is the first key characteristic of Open-edi as stated in Clause 5.1 “Actions based upon following clear, predefined rules”. It is useful to quote some key normative text of ISO/IEC 15944-1:2011 so that users of ISO/IEC 15944-5 have a clear understanding of the nature and purpose of this BOV standard.

“Open-edi requires the use of clear and pre-defined rules, principles and guidelines. These rules formally specify the role(s) of the parties involved in Open-edi and the available expected behaviour(s) of the parties as seen by other parties engaging in Open-edi. Open-edi rules are applied to:

the content of information flows; and,

11 This introductory clause is primarily based on that found in ISO/IEC 15944-1:2011, Clause 6.1.2 titled “Standard based on rules and guidelines”.

12 See entry D252, Annex D, ISO/IEC 15944-7. One can interpret "agreement" in a variety of ways. The ISO/IEC Guide 2:2004 (1.7) uses the term "consensus" which need not imply unanimity but rather “absence of sustained opposition to substantial issues…”

13 The key characteristics of Open-edi are (as stated in Clause 5, ISO/IEC 15944-1:2011, pp.12-14) are: actions based on following predefined rules; commitment of the parties involved; communications among parties are automated; parties control and maintain their states; parties act autonomously; and, multiple transactions can be supported.

The six sub-clauses of Clause 5 of ISO/IEC 15944-1:2011 describe each of these key characteristics in more detail.

XVI © ISO/IEC 2014 – All rights reserved

57

444445446447448

449450451

452

453454

455

456457458

459

460461462

463464465

466467468469470

471472473

474

5859

606162

636465666768697071

CD ISO/IEC 15944-12:2014(E)

the order and behaviour of information flows themselves.

The combination of both of these provides a complete definition of the relationships among the parties since it requires them to achieve a common semantic understanding of the information exchanged. They must also have consistent generic procedural views on their interaction. Therefore, rule sets have to be agreed to in advance and captured in Open-edi scenarios. This is a major component of the agreement required among parties.”

These rules also serve as a common set of understanding bridging the varied perspectives of the commercial framework, the legal framework, the information technology framework, standardisers, consumers, etc.14

For ease of reference, common rules have been sequentially enumerated, and are presented in bold font. Where guidelines associated with a rule are provided, they are numbered sequentially after that rule and are shown in bold and italic font15. Choice of words in the rules, the guidelines and the terms and definitions are governed by maximizing the ability to map, on the one hand, to all the sources of requirements of the Business Operational View (BOV) of any e-business transaction, (e.g., commercial, legal, public policy, cultural adaptability, sectoral, etc.), frameworks of the day-to-day world of business, and, on the other hand, those pertaining to the Functional Services View (FSV) in support of BOV requirements, (e.g., that of those providing information technology and communication services in support of commitment exchange of any kind and among all parties involved in a business transaction).

0.6 Use of “identifier” (in a business transaction) and roles of an individual16

Clause 6.1.4 of ISO/IEC 15944-1:2011 focuses on the requirement for the unambiguous identification of entities in business transactions. "Unambiguous" is a key issue in business transactions because states of ambiguity and uncertainty are an anathema from commercial, legal, consumer and information technology perspectives. Issues of unambiguousness apply to all aspects of a business transaction and even more so to those which are EDI-based. Open-edi transactions anticipate that all entities are fully and clearly identified prior to the transaction.

The ISO/IEC 15944 multipart standard serves as a methodology and tool for the specification and unambiguous identification of Open-edi scenarios, scenario attributes and scenario components as re-useable elements, i.e., as re-useable business objects, in support of common business transactions. These and related objectives of interoperability and re-usability of Open-edi scenarios and scenario components for business transactions require their unambiguous identification.

ISO/IEC 15944-1 defines "unambiguous" as follows:

unambiguous

level of certainty and explicitness required in the completeness of the semantics of the recorded information interchanged that is appropriate to the goal of a business transaction

[ISO/IEC 15944-1:2011 (3.66)]

and "identifier (in business transaction)" as follows:

identifier (in business transaction)

14 The working principle here is that of "coordinated autonomy", i.e., all parties are autonomous. Therefore, the extent to which they cooperate, agree on common needs, business rules constraints, practices, etc., and reach agreement on the same in form of precise rules, terms and definitions, etc., is a key influence on the creation of necessary standards as well as common scenarios, scenario attributes and scenario components.

15 For example, “Guideline 5G2” equals the second Guideline under Rule 5.

16 This is a summary of ISO/IEC 15944-1:2011, Clause 6.1.4 "Business transactions: Unambiguous identification of entities". See also Annex C in ISO/IEC 15944-1 titled Unambiguous Identification of Entities in a Business Transaction which provides the informative and explanatory text for the rules and definitions in Clause 6.1.4.

© ISO/IEC 2014 – All rights reserved XVII

73

475

476477478479480

481482

483484485486487488489490491

492

493494495496497498

499500501502503

504

505

506507

508

509

510

74757677

78

798081

82

CD ISO/IEC 15944-12:2014(E)

unambiguous, unique and a linguistically neutral value, resulting from the application of a rule-based identification process

NOTE Identifiers must be unique within the identification scheme of the issuing authority.

[ISO/IEC 15944-1:2011 (3.27)]

Thus, readers of this part of ISO/IEC 15944 should understand that the "identifier" in this part of ISO/IEC 15944 is used as a defined term as "identifier (in a business transaction)".17

0.7 Use of "jurisdictional domain" in the context of privacy protection and related ILCM requirements

The term "jurisdiction" has many possible definitions. Some definitions of “jurisdiction” have accepted international legal status while others do not. It is also common practice to equate "jurisdiction" with "country", although the two are by no means synonymous. It is also common practice to refer to states, provinces, länder, cantons, territories, municipalities, etc., as "jurisdictions", and in contract law it is customary to specify a particular court of law as having jurisdiction or a defined national body, or an international body as having jurisdiction (even if that is not legally enforceable), and so on. Finally, there are differing "legal" definitions of "jurisdiction". Readers of this part of ISO/IEC 15944 should understand that in this part of ISO/IEC 15944:

the use of the term "jurisdictional domain" represents its use as a defined term; and,

the use of the terms “jurisdiction(s)” and/or “country (ies)” represents their use in their generic contexts and do not imply that this Part of ISO/IEC 15944 has any legal effect per se.

At the same time, a set of external constraints of a jurisdictional domain lends itself to being modelled through scenarios and semantic components. For example, Annex "I" in ISO/IEC 15944-1:2011, titled, "Scenario Description Using the Open-Edi Scenario Template, Telecommunications Operations Map Example" is a scenario of an external constraint of a jurisdictional domain, i.e., the USA, that provides a business process framework for the enterprise process required for a telecommunications service provider. Here, the fact that external constraints of jurisdictional domains are a primary factor in choice of language and application of public policy are also addressed in this part of ISO/IEC 15944.

0.8 Use of “privacy protection” in the context of business transaction and commitment exchange

Jurisdictional domains such as UN member states (and/or their administrative sub-divisions), have enacted various “privacy” laws, “data protection” laws, “protection of personal information” laws, etc., (as well as pursuant regulations). Some of these sources of legal requirements focus on the protection of personal information in IT systems only, (e.g., “data protection”), while others focus on the protection of personal information irrespective of the medium18 used for the recording of personal information and/or its communication to other Persons.

In the case of personal information, this is currently defined by most jurisdictional domains to be a specific sub-set of recorded information relating to the Person as an “individual” – where the qualities of such type of Person are that they must be an identifiable, living individual. So this may only apply to some proportion of the specific role players in a business transaction (including their personae) and not others.

This part of ISO/IEC 15944 incorporates the common aspects of such laws and regulations as pertaining to privacy protection, applicable at the time of publication only. The concept of “privacy protection” also integrates these various sets of legal and regulatory requirements and does so from a public policy requirements perspective. {See below at Clause 6.3 and Clause 7}

17 Identifiers in business transactions can be simple or composite identifiers. This is dependent on (1) the rules governing "identifiers" as a rule-based process; (2) the "registration schema" used (as well as any permitted combinations of the same).

18 “Medium” is a defined concept. {See ISO/IEC 15944-1:2011, Clause 6.4. “Rules governing the data component”, and its Clause 6.4.1 “Recorded information”}.

XVIII © ISO/IEC 2014 – All rights reserved

83

511512

513

514

515516

517518

519520521522523524525

526

527528

529530531532533534535

536537

538539540541542543

544545546547

548549550551

848586

8788

CD ISO/IEC 15944-12:2014(E)

It has to be borne in mind that the delivery of “privacy protection” requires action both at the business operational level (BOV) and functional services view (FSV) (or technology levels). Where human beings interact with recorded information once it has passed through an Open-edi transaction, they may have the potential to compromise technical controls (FSV) that may have been applied. It is essential that business models take account of the need to establish overarching business processes that address issues that have not been, and/or cannot be resolved by the technical FSV controls applied so as to provide the overall privacy demands of regulation that must be applied to personal data, their use, proscribed dissemination and so on. In this regard, the interplay of the BOV and FSV views of all organizations must be taken into account.

0.9 Use of set of recorded information (SRI) and set op personal information versus record, document, message, etc.


1. P-member comments are requested to advise whether throughout the document one should (a) use set of recorded information (SRI) as the default and set of personal information (SPI) only where specifically required; or (b) use set of personal information (SPI) as the default and set of recorded information only when dealing with generic matters.

2. This can be decided November, 2014 at the CD ballot resolution meeting in Toronto.

The concepts of “record”, “document”, ‘data”, “message”, etc., are defined and used in both ISO standards and in differing levels of jurisdictional domains. However, multiple differing definitions exist for each of these terms in ISO, and in standards applicable legislation and related regulations. To all this polysemy issue, the unifying concept and definition of “set of recorded information” was already introduced and defined in ISO/IEC 15944-5. It is defined as follows:

set of recorded information (SRI)

recorded information of an organization or public administration, which is under the control of the same and which is treated as a unit in its information life cycle

NOTE 1 A SRI can be a physical or digital document, a record, a file, etc., that can be read, perceived or heard by a person or computer system or similar device.

NOTE 2 A SRI is a unit of recorded information that is unambiguously defined in the context of the business goals of the organization, i.e., a semantic component.

NOTE 3 A SRI can be self-standing (atomic), or a SRI can consist of a bundling of two or more SRIs into another “new” SRI. Both types can exist simultaneously within the information management systems of an organization.

[ISO/IEC 15944-5:2008, 3.137]

In Open-edi, SRIs are modelled as information bundles (IBs) and semantic components (SCs) when they are interchanged among participating parties in a business transaction. Within the IT systems of an organization, and especially within its Decision Making Applications (DMAs), the recorded information pertaining to a business transaction is usually maintained as one or more (linked) SRIs.

In order to maximize linkages between Open-edi (external behaviour) aspects and data management (internal behaviour) aspects of an organization (as well as associated ISO record management and EDIFACT standards), SRI is used as a common higher level concept, which incorporates essential attributes of the concepts of “record”, “document”, “message”, etc. as defined in various ways in existing ISO standards.

Where and when a SRI is of the nature of personal information or contains personal information privacy protection requirements apply. Within the context of privacy protection requirements and with the focus of ILCM the concept and definition of “set of personal information (SPI)” is as follows:

set of personal information (SPI)

© ISO/IEC 2014 – All rights reserved XIX

90

552553554555556557558559

560561

562

563564565566

567

568569570571572

573

574575

576577

578579

580581

582

583584585586

587588589590

591592593

594

91

CD ISO/IEC 15944-12:2014(E)

set of recorded information (SRI) which is of the nature of or contains personal information

This Part 12 focuses on ILCM of personal information in support of privacy protection requirements and as such “set of personal information (SPI)” is used throughout this document while “set of recorded information (SRI) when referring to the more generic ILCM aspects.

0.10 Organization and description of this document


1. The text provided below needs to be completed. This will be done following the resolution of CD ballot comments and before the issuance of the DIS ballot document.

This part of ISO/IEC 15944, i.e. Part 12, identifies basic common requirements of information life cycle management (LCM) requirements in a privacy protection context, as external constraints of jurisdictional domains, on the modelling of a business transaction through scenarios and scenario components.

[PEs to do]

.

Finally, annexes are provided for elaboration of points raised in the main body.

Annex A is a consolidated list of the definitions and their associated terms used in this part of ISO/IEC 15944 in ISO English and ISO French. As stated in the main body of this part of ISO/IEC 15944, the issue of semantics and their importance of identifying the correct interpretation across official aspects is critical.

Annex B identifies rules stated in the other Parts of ISO/IEC 15944 that are applicable to this part of ISO/IEC 15944. Annex C is common to ISO/IEC 15944-2, ISO/IEC 15944-4, ISO/IEC 15944-5 and ISO/IEC 15944-8. It summarizes the Business Transaction Model (BTM).

[PEs to do/complete ]

XX © ISO/IEC 2014 – All rights reserved

92

595

596597598

599

600

601602

603604605

606

607

608

609610611

612613614

615

616

CD ISO/IEC 15944-12:2014(E)

Information technology — Business Operational View —

Part 12:Privacy protection requirements on information life cycle management (ILCM) and EDI of personal information

1 Scope

1.1 Statement of scope

Like other parts of ISO/IEC 15944 this Part 12 is based on the ISO/IEC 14662 “Information technology - Open-edi Reference Model” as well as existing Parts of ISO/IEC 15944 “Information technology – Business Operational View” which serve as its key Normative References and overall boundaries for the Scope of Part 12. Further, Part 5 and Part 8, in particular, serve as the basis for this Part 12 as they both focus on external constraints.

In this context, this Part 12 of ISO/IEC 15944:

provides method(s) for identifying, in Open-edi modelling technologies and development of scenarios, the additional requirements in Business Operational View (BOV) specifications for identifying the additional external constraints to be applied to recorded information in business transactions relating to personal information of an individual, as required by legal and regulatory requirements of applicable jurisdictional domains having governance over the personal information exchanged among parties to a business transaction doing so from an “Information life cycle management (ILCM) requirements perspective;

integrates existing normative elements in support of privacy and data protection requirements as are already identified in the current editions of ISO/IEC 14662 and ISO/IEC 15944-1, ISO/IEC 15944-2, ISO/IEC 15944-4, ISO/IEC 15944-5, ISO/IEC 15944-8, ISO/IEC 15944-9, and ISO/IEC 15944-10 which apply to any kind of business information concerning identifiable living individuals as buyers19 in a business transaction or whose personal information is used in transaction or any type of commitment exchange;

provides overarching operational ‘best practice’ statements for associated (and not necessarily automated) processes, procedures, practices and governance requirements that must act in support of implementing and enforcing technical mechanisms needed to support privacy/data protection requirements necessary for the implementation in Open-edi transaction environments;

identifies and provides a sample scenario and implementation (use case) for one or more ILCM use cases of privacy/data protection in business transactions; and,

provides guidelines on the need for procedural mechanisms in the event that mandatory disclosure rules of transactional information must be implemented.

19 As stated in Clauses 6.2.4 – 6.2.8, and Figure 18 of ISO/IEC 15944-1:2011, a natural person who provides a good, service and/or right is deemed to be an organization. Most jurisdictional domains also view an unincorporated activity providing a good, service and/or right to be an organization. {See further ISO/IEC 6523}

© ISO 2014 – All rights reserved 21

94

617

618619620

621

622

623624625626627

628

629630631632633634

635636637638639640

641642643644

645646

647648

959697

CD ISO/IEC 15944-12:2014(E)

1.2 Exclusions20

1.2.1 Functional Services View (FSV)

This Part 12 focuses on the BOV aspects of a business transaction, and does not concern itself with the technical mechanisms needed to achieve the business requirements (the FSV aspects, including the specification of requirements of a Functional Services View (FSV) nature which include security techniques and services, communication protocols, etc.). The FSV includes any existing standard (or standards development of an FSV nature), which have been ratified by existing ISO, IEC, UN/ECE and/or ITU standards. However, this Part 12, like the other Parts of ISO/IEC 15944 is structured to identify and facilitate the need for and use of required functional services.

1.2.2 Internal behaviour of organizations (and public administration)

Excluded from the scope of this part of ISO/IEC 15944 is the application of ILCM aspects of privacy protection requirements within an organization itself. The Open-edi Reference Model, considers these to be internal behaviours of an organization and thus not germane to business transactions (which focus on external behaviours pertaining to electronic data interchange among the autonomous parties to a business transaction). As such, excluded from the scope of this part of ISO/IEC 15944 are any:

1) internal use and management of recorded information pertaining to an identifiable organization Person an organization (or public administration) within an organization; and,

2) implementation of internal information management controls, internal procedural controls or operational controls within an organization or public administration necessary for it to comply with applicable privacy requirements that may be required in observance of their lawful or contractual rights, duties and obligations as a legal entity in the jurisdictional domain(s) of which they are part.

This should not be taken to mean that an organization could not adapt this Part 12 in order to model internal behaviour if it so wished, with respect to their ILCM policies and their implementations of personal information within their organization (or public administration).

1.2.3 “organization Person”

Project Co-Editors” Note:

1. This exclusion is carried forward from Part 8. The permanent retention, i.e., archiving, of personal information of “important persons” in an organization (private or public) is recognized as important from an historical (and research) needs perspective.

2. However, from an ILCM perspective, it is often difficult at times to distinguish between (a) personal information of an natural person in his/her role as an “organization Person”; and (b) in his/her role as an “individual”. It is a common practices in (large) organization and especially public administrations to reach an agreement to archive” all the personal information of an natural person who plays a leading role in the organization (e.g., as Chairman, President, CEO, Prime Minister, Minister, etc.) into one collective archive containing both categories (a) and (b) roles of that natural person into a single archival repository with its own distinct set of rules governing access to and use of such personal information.

3. This issue is very relevant with respect to Clause 7.4 Rules governing disposition of personal information” and its associated Coded Domain. Consideration needs to be given to addressing this issue, which is very practical in nature. Perhaps as a first step, this issue could/should be addressed via the development of a “Technical Report” .as a NWI of the multipart ISO/IEC 15944 standard.

4. P-members are requested to advice ISO/IEC JTC1/SC32/WG1 on this matter (e.g., via their CD ballot comments on this document).

20 The exclusions stated here are harmonized with ISO/IEC 15944-8 on which they are based.

22 © ISO 2014 – All rights reserved

100

649

650

651652653654655656657

658

659660661662663

664665

666667668669

670671672

673

674

675676677

678679680681682683684685

686687688689

690691

101

CD ISO/IEC 15944-12:2014(E)

From a public policy privacy protection requirements perspective, an “organization Person” is a “natural person” who acts on behalf of and makes commitments on behalf of the organization (or public administration) of which that natural person is an “organization part”. But, as an “organization Person”, they do not attract inherent rights to privacy from in EDI perspective. Privacy protection requirements which do apply to an organization Person are placed in an employee-employer context with associated contractual elements. In addition, some jurisdictional domains have privacy protection laws and regulations which apply specifically to employees of their public administrations.

As such, from a business transaction perspective, it is an internal behaviour of an organization, as to who makes commitments on behalf of an organization or public administration. How and why “organization Persons”, i.e., as duly designated as authorized natural person, make decisions and commitments is not germane to the scope and purpose of this Part 12 . {See further ISO/IEC 15944-1:2011, Clause 6.2 “Person and external constraints: Individual, organization, and public administration” as well as its Figure 17 “Illustration of commitment exchange versus information exchange for organization, organization part(s) and organization Person(s)”}

1.2.4 Overlap of and/or conflict among jurisdictional domains as sources of privacy protection requirements

A business transaction requires an exchange of commitments among autonomous parties. Commitment is the making or accepting of a right, an obligation, liability or responsibility by a Person. In the context of a business transaction, the making of commitments pertains to the transfer of a good, service and/or right among the Persons involved.

Consequently, it is not an uncommon occurrence, depending on the goal and nature of the business transaction, that the Persons (and parties associated) are in different jurisdictional domains, and that multiple sets of external constraints apply, and overlap will occur. It is also not an uncommon occurrence that there is overlap among such sets of external constraints and/or conflict among them. This is also the case with respect to laws and regulations of a privacy protection nature. Resolving issues of this nature is outside the scope of this part of ISO/IEC 15944.

However, modelling business transaction as scenarios and scenario components as re-useable business objects may well serve as a useful methodology for identifying specific overlaps and conflicts (thereby serving as a tool for their harmonization, if only within the context of a specific transaction).

The application of business semantic descriptive techniques to laws, regulations, etc., of jurisdictional domains and their modelling of such sets of external constraints as scenarios and scenario components is an essential step to their application in a systematic manner to (electronic) business transactions (and especially e-government, e-commerce, e-education, etc.).

Open-edi business agreement descriptive techniques methodologies can serve as a tool in the harmonization and simplification of external constraints arising from jurisdictional domains.

NOTE This Part 12 is based on the following assumptions:

1) the privacy protection requirements of the individual, as a buyer in a business transaction, are those of the jurisdictional domain in which the individual made the commitments associated with the instantiated business transaction;

2) where the seller is in a jurisdictional domain other than that of the individual, as the buyer, this edition of ISO/IEC 15944 incorporates and supports the “OECD Guidelines on the Protection of Privacy and Transborder Data Flows of Personal Data”; the EU

3) where the buyer is an “individual” also incorporates individual accessibility requirements;

4) where the buyer is an individual this also invokes consumer protection and individual accessibility requirements.

1.2.5 Publicly available personal information

Project Co-Editors Notes:


103

692693694695696697698

699700701702703704705

706707

708709710711

712713714715716717

718719720

721722723724

725726

727

728729730

731732733

734

735

736

737

CD ISO/IEC 15944-12:2014(E)

1. This Clause requires more consideration. The text in this Clause is taken form Part 5. It needs to be re-thought in light of the EU Court decision on “mandatory expungement”. {See document SC32/WG1 N0743} In the context of Part 12 (and Part 5), what happened is that separate SRIs of personal information which were of a PAPI nature in specific local context and accessible in those contexts only were aggregated or linked via a search engine Google and now make easily accessible world-wide.

2. The Project Co-Editors welcome CD ballot comments from P-members on this matter (as well as any expert contributions).

3. This is because of the distinct possibility to ensure that PAPI related aspects are covered through existing rules, i.e., those pertaining to the fact that personal information collected and used for a specific goal may not be (re-)used for another purpose without the express consent of the individual.

Excluded from the scope of this Part of ISO/IEC 15944 is “publicly available personal information” (PAPI) and its use. In a business transaction context, the seller often does not collect personal information of this nature from the individual (particularly in the “planning phase” of the business transaction process).

For example, the seller in advertising product to the market may:

1) use personal information that is publicly available personal information, such as that found in telephone directories;

2) make use of any personal information declared to be of a public information nature by a regulation based on an law or regulation of the applicable jurisdictional domain; and, or,

3) include that which the individual itself chose to make public, (e.g., via one or more Internet based applications such as “Facebook”, “Twitter”, etc).

In a privacy protection context, publicly available personal information is defined as follows:

publicly avalable personal information (PAPI)

personal information about an individual that the individual knowingly makes or permits to be made available to the public, or is legally obtained and accessed from: (a) government records that are available to the public; or, (b) information required by law to be made available to the public

EXAMPLE 1 Examples of personal information which an individual knowingly makes or permits to be made available include public telephone directories, advertisements in newspapers, published materials, postings of a similar nature on the internet, etc.

EXAMPLE 2 Examples of government records that are publicly available include registers of individuals who are entitled to vote, buy or sell a property, or any other personal information that a jurisdictional domain requires to be publicly available, etc.

[ISO/IEC 15944-8:2012, 3,109]

Further, determining whether or not personal information is of a “PAPI” nature is also excluded from the scope of this Part of ISO/IEC 1594421.

21 For example, in July 2014, the Irish Data Protection Commissioner order closure of civil records for genealogy nature because they contained sensitive personal data available to all including birth certificates, which include date of birth, mother’s maiden name, etc., information which is frequently used as part of security questions for e-business transactions. The Irish government complied closing part of its genealogy website on 18 July, 2014. Hern, Alex. (21 July, 2014) Personal data removed from Irish Genealogy site over security fears. T he Guardian. http://www.theguardian.com/technology/2014/jul/21/ireland-shuts-government-genealogy-personal-data-concerns (Accessed 27 July, 2104).


105

738739740741742

743744

745746747

748749750

751

752753

754755

756757

758

759

760761762

763764765

766767768

769

770771

106107108109110111112

http://www.theguardian.com/technology/2014/jul/21/ireland-shuts-government-genealogy-personal-data-concerns

CD ISO/IEC 15944-12:2014(E)

1.3 Aspects currently not addressed


1. This is a very important Clause. It serves two purposes:

(a) To identify to users of this standard of those privacy protection aspects of an ILCM nature which are recognized as being included in the scope of this Part 12; and,

(b) To serve as the basis for future work to be undertaken as needed and resources are available.

2. JTC1/SC32 P-members are encouraged to make comments on Clause 1.3 especially if there are added “Aspects currently not addressed”.

3. NOTE: The issues identified below are not presented in any order of important. Their order basically identifies the order in which they are identified.

This Part of ISO/IEC 15944 focuses on the essential and basic aspects of ILCM aspects of privacy protection requirements. The purpose of this Clause is to identify aspects not currently addressed. These will be addressed in either:

a) an Amendment to this part of ISO/IEC 15944,

b) new editions of this part of ISO/IEC 15944,

c) through a new part of ISO/IEC 15944 (as either an international standard (IS) or a technical report (TR);

d) in a new edition of an existing part of ISO/IEC 15944 (as may be applicable),

e) through a new edition of an existing standard of ISO/IEC JTC1, or another existing ISO/IEC JTC1/SC, or ISO, IEC or ITU; and/or,

f) new standard(s) by any of the above noted ISO standards development committees.

ISO/IEC 15944-12 also does yet address the following requirements:

1) differences in equality in the use of official languages by an individual, in being informed and exercising privacy protection rights within a jurisdictional domain22;

2) interworking between ILCM aspects of privacy protection and consumer protection requirements as two sets of external constraints applicable to an individual as a buyer in a business transaction and their related SPIs;

3) more detailed information management and audit requirements pertaining to ensuring ILCM aspects of privacy protection of personal information that should be enacted by and among organizations and public administrations as parties to a business transaction;

4) more detailed rules and associated text pertaining to the BOV perspective with respect to ILCM aspects of transborder data flows of personal information;

22 This part of ISO/IEC 15944 focuses on the essential basic, i.e. primitive, aspect of jurisdictional domains as sources of external constraints. As such this edition of ISO/IEC 15944-8 does not address differences in status that may exist among official languages within a jurisdictional domain. It is not uncommon that where a jurisdictional domain has three or more official languages that not all of these have equal status. For example, for use of some official language(s) in a jurisdictional domain, there could be criteria such as “where and when numbers warrant”, “there is a significant demand for communication with and services from a public administration in that language”, etc. This impacts both the language in which personal information is recorded by an organization or public administration as well as the language of communications of the individual with the organization in a business transaction.


114

772

773

774

775776

777

778779

780781

782783784

785

786

787788

789

790791

792

793

794795

796797798

799800801

802803

115116117118119120121122

CD ISO/IEC 15944-12:2014(E)

5) inter-operation between jurisdictional domains where they do not possess defined equivalents to their privacy protection requirements (interoperability) or where privacy protection requirements simply are different;

6) general constraints and associated rules on the sharing of personal information as transborder data flows among different jurisdictional domains including related aspects of extraterritoriality;

7) the methodology(ies) to explicitly identify which individual the personal information belongs to;

8) instances in which ILCM aspects of privacy protection requirements continue to apply to the personal information of an individual after his/her death;

In addition, from a business transaction perspective, there may be some continuity in ILCM aspects of privacy protection requirements, (e.g., those pertaining to temporal aspects of post-actualization aspects of an instantiated business transaction, (e.g., health care matters, warranties on products, service contracts, rights (including IP), etc.). Instantiated business transactions may require personal information to be retained and continue to be protected following the death of the individual.

NOTE 1 This may also include a settlement of wills, probate, investments, etc., pertaining to that individual once proved deceased.

NOTE 2 Tax information filed has 4-6 years record retention requirements in most jurisdictional domains. In some jurisdictional domains, tax matters are confidential and in others they are public. The status of personal information may change as a result of litigation and public hearings.

NOTE 3 Instantiated business transactions may require personal information to be retained and continue to be protected following the death of an individual, (e.g., many credit card agreements exist after the death of the credit card holder).

NOTE 4 One may need to have an added Clause on privacy protection of personal information on individuals consequent upon the death of the individual.

9) this Part of ISO/IEC 15944 does not address the question of negotiated consent with respect to ILCM aspects, but rather considers the simplest case, that a scenario may be registered which includes a specific form of consent within it;

10) the use of biological characteristics and attributes of an individual which require the physical presence of an individual and are physically “taken” from an individual in a particular context and for a specified role action of an individual;

These include the use of biometrics, biological (such as hair, blood, DNA samples), dentistry records, etc.

11) the application of the rights of individuals who are disabled as stated in the “UN Convention on the Rights of Persons with Disabilities” (2006)23;

Of particular importance here is that this UN Convention takes as its basis the need to support individuals with disabilities to be a fully functioning member of society means that information necessary for these individuals to be able to make commitments including the undertaking of business transactions shall be made available in a form and format so that the semantics are fully communicated, the individual is able to have informed consent, etc.

12) this Part of ISO/IEC 15944 does not address the role of an “ombudsperson”, “Privacy Commissioner”, a “Data Protection Commissioner”, etc., who serves as an independent adjudicator of complaints and

23 Most, if not all, of the jurisdictional domains of the P-members of ISO/IEC JTC1 are signatories to this UN Convention and are enacting the requirements of this UN Convention into their domestic legislation. A useful standard from both an Open-edi and individual accessibility requirements perspective is ISO/IEC 20016-1:2014 “ITLET – Language accessibility and human interface equivalencies (HIEs) in e-learning applications – Part 1: Framework and reference model for semantic interoperability”.


124

804805806

807808

809

810811

812813814815816

817818

819820821

822823824

825826

827828829

830831832

833834

835836

837838839840841

842843

125126127128129

CD ISO/IEC 15944-12:2014(E)

ensures compliance with ILCM related privacy protection requirements (including of internally of the organization or public administration themselves);

Many jurisdictional domains provide for the role of an ombudsperson which may be a role similar in application to public administration.

13) detailed rules pertaining to the use of agents and/or third parties by a seller in a business transaction

This includes their qualification and assurance of compliance with applicable privacy protection requirements for the personal information pertaining to a business transaction.

14) an agent acting on behalf of an individual

An individual may request an agent to act on its behalf and this may or may not include the individual to require the agent not to reveal the individual identity or any personal information about the individual, i.e., as an anonymous “client” of the agent.

15) detailed rules governing the requirement to tag (or label) at the data elements (or field) level which form part of personal information of an individual generally as is required for as the business transactions(s) and its associated BTI(s) as needed to support applicable ILCM requirements;

16) ICT and other service providers

It is presumed that any ICT (or other) services provider which is under contract to provide ICT services to an organization or public administration (which has personal information under its control) shall not access or use such personal information processed as part of its services offering to that organization, unless it has a formal contractual arrangement to do so, in compliance with applicable privacy protection requirements.

17) data mining 24 and data brokers

It is also presumed that an organization shall ensure that any data mining activities undertaken by itself (or via an agent or third party on its behalf) shall be in compliance with applicable privacy protection requirements, and not involve any secondary use or any other use of personal information for which the individual(s) concerned have not provided explicitly informed consent. In addition, the whole area pertaining to “data brokers’ requires more detailed examination25.

18) “cookies”

A “cookie” is packet of data sent by an Internet server to a browser, which is returned by the browser each time it subsequently accesses the same server, used to identify the user or track their access to the server. Also known as an HTTP cookie, web cookie or browser cookie, this small piece of data is stored on the user's browser.

On the whole, a “cookie” is of the nature of a set of personal information(SPI) and at a primitive level is one of either two types, namely (a) that of the nature of (a) a transitory record” (See further below Annex E blow re “transitory Records”); or (b) of the nature of a “permanent record”. In this context from an ILCM perspective and in a privacy protection requirements context, there is a distinction between (a) a “session cookie”; and (b) a “persistent cookie”. A “session cookie” is of the nature of a

24 One recent variant of “data mining” is that of “Big Data” where vast quantities of data are aggregated to be analyzed or “mined” to achieve specific objectives such as targeted marketing to identified specific individuals. Privacy protection requirements still apply. See further the SC32/WG1 N0745 document titled “Timely, accurate and relevant data only: Privacy protection requirements on Big Data” prepared for the JTC1/SC32 Open Forum on Big Data”, 12 June, 2014, Beijing by Mr. Wenfeng Sun and Dr. Jake V.Th. Knoppers.

25 Examples of major data brokers include Acxiom, CoreLogic, Datalogix, ID Analytics, and Intelius. The focus of data brokers is consumer data (basically both the actual and derived data on individuals). On 27 May, 2014, the US Federal Trade Commission (FTC) released a study of data brokers titled “Big Data: A Call for Transparency and Accountability”. One conclusion of this study is the FTC called for the US Congress to enact legislation that would enable consumers to learn of the existence and activities of data brokers, provide consumers information on what data is being held about them, allow for an opt out option, etc.


131

844845

846847

848

849850

851

852853854

855856857

858

859860861862863

864

865866867868869

870

871872873874

875876877878879

132133134135136

137138139140141142

CD ISO/IEC 15944-12:2014(E)

transitory record as it exists only in temporary memory while the user navigates the website. When the expiry date or validity interval is not set at cookie creation time, a session cookie is created. Web browsers normally delete session cookies when the user closes the browser. A “persistent cookie remains after the user session is closed. It has a Manage which can be reset ever time the website is used, which is why they are also called “tracking cookies”. Because cookies do cause security concerns, some users set their browser to always block cookies.

A major concern about persistent or tracking cookies is that of them supporting applicable privacy protection requirements and ensuring .individual anonymity of the individual user, especially where these include cookies collected and maintained by the seller, its agent(s) and third party(ies) 26

19) formal Conformance Statements

Clause 13 below deals with conformance requirements at the most primitive level only. More detailed conformance statements with associated rules and procedures are required in implementation. It is also necessary to ensure that any such conformance statement, i.e., declaration by an organization or public administration is “verifiable”.

20) Open-edi metadata elements need to support and mange ILCM for SPIs in support of privacy protection requirements

This 1st edition of Part 12 identifies, but not yet explicitly define and specify the Open-edi metadata elements needed to support ILCM requirements for SPIs in a business transaction needed to support privacy protection requirements (as well as associated Open-edi metadata element requirements. For example, this Part 12 (as well as other Parts of ISO/IEC 15944 include requirements of the nature which require the provision of associated metadata element information for scenarios, scenario components (including IDs for roles, IBs, SCs,, etc), SRIs, SPIs, etc. Here is is noted that Open-edi standards, including this Part 12 make extensive use of coded domains. It is

21) linkages and similarities between privacy protection and consumer protection requirements

Many of the external constraints pertaining to personal information of a privacy protection nature in a business transaction are similar to consumer protection requirements.

22) Personal information (as SPIs) resulting from business transactions being retained and used for statistical, historical or research purposes, i.e., instead of being disposed (expunged) at end of its retention period.

In the 1st edition of Part 12 this issue is addressed only in a very generic and primitive matter (see Clause 7.n below). On the whole, the issue is associated with the interaction of privacy protection requirements with other information law. Further the issue of ensuring individual anonymity for SPIs being used or retained for historical or research purposes is not yet addressed.


1) This issue is not unique to Part 12 but applies to most of the Parts of ISO/IEC 15944.

2) It is recommended that rather than addressing this issue, which is urgent from a Part 12 perspective, that JTC1/SC32/WG1 consider at its Toronto, Canada, November, 2014 interim meeting to the launching a short “study period”, i.e., with a draft document to be completed prior to the 2015 JTC1/SC32/WG1 Plenary meeting, with as objective the development of a document which identifies in matrix form from a data interchange, i.e., Open-edi as well as identified external constraints perspective (including external constraints which impact internal constraints), any and all sets of content values of the nature of “data elements”, “metadata elements”, etc. currently already identified

26 Text here is based on that of the Oxford Dictionary and the Wikipedia entry for “HTTP cookie”. The US FTC in its report and recommendation to the US Congress (see ftnt. 25 above) also expressed concern about cookies and in particularly the practice of “onboarding” which is the practices of data brokers add offline data to a cookie. The primary purpose here is to enable advertisers to target an individual consumer practically anywhere on the Internet.


144

880881882883884885

886887888

889

890891892893

894895

896897898899900901902

903

904905

906907908

909910911912

913

914

915916917918919920921

145146147148

CD ISO/IEC 15944-12:2014(E)

in existing ISO/IEC 14882 and the multipart the multipart ISO/IEC 15944oset of existing and under development series of standards.

23) Changes in jurisdictional domain(s) of parties to a business transaction (including renaming of the same physical/geographical location)


1. It may well be that during the lifetime of a business transaction that the physical location of the jurisdictional domain of the buyer, seller, regulator undergoes a change, i.e., even though the physical/geographical location of the primary parties to a business transaction, i.e., the seller or buyer, has not changed but that of the regulator has.

2. Such changes in jurisdictional domain can be (a) anticipated/planned for or “be sudden” and unforeseen; (b) involve the buyer and/or seller (being location geographically/physically in the same jurisdictional domain; (c) involve a change in jurisdictional domain, etc.

3. As a result that was previously a common jurisdictional domain (and associated set of common external constraints) has been changed, i.e., either the buyer or the seller could suddenly find themselves in different jurisdiction domains along with possible differing external constraints. A key example is where (a) the nature of the good, service and/or right which is the goal of a business transaction has a post-actualization phase (of several years); and, (b) the buyer is an individual and privacy protection requirements apply.

4. A related aspect is where a jurisdictional domain joins a set of other jurisdictional domains, (e.g., the European Union, a new free trade “agreement”) which impacts either/or (a) applicable external constraints; (b) privacy protection requirements.

5. In an ISO/IEC 14662 Open-edi and ISO /IEC 15944 context, issues of this nature can be addressed in a systematic nature (particularly through the use of a coded domain) either via amendments to existing Parts or a new Part of ISO/IEC 15944.

6. Participating JTC1/SC32 P-0members are requested to advise the Part 12 Project Co-Editors via their4 CD ballot comments whether they would prefer the above aspects to be added as (a) an aspect not yet addressed; or (b) an exclusion.

In either case, whatever the decision taken re (a) or (b), this will impact Parts 5 and 8 of ISO/IEC 15944.

It is anticipated that some or all of these requirements will be addressed in future editions of ISO/IEC 15944-8 or in companion standards or technical reports (including possible new parts of ISO/IEC 15944).

1.4 IT-systems environment neutrality

This part of ISO/IEC 15944 does not assume nor endorse any specific system environment, database management system, database design paradigm, system development methodology, data definition language, command language, system interface, user interface, syntax, computing platform, or any technology required for implementation, i.e., it is information technology neutral. At the same time, this part of ISO/IEC 15944 maximizes an IT-enabled approach to its implementation and maximizes semantic interoperability.


150

922923

924925

926

927928929930

931932933

934935936937938939

940941942

943944945

946947948

949950

951

952953

954

955956957958959

CD ISO/IEC 15944-12:2014(E)

2 Normative references


1. The initial text below is that taken from Clause 2 in Part 8 (as well as Clause 2 in Part 5).

2. The entries below will be reviewed and amended based on use of these normative references in Part 12. Others will be added as required, (e.g., impact of Part 9 traceability requirements) and related standards. This work will be undertaken following the resolution of CD ballot comments.

3. Delete those entries which do not apply (probably at pre-DIS stage) and add Normative references as needed (any time).

4. In addition, several Parts of ISO/IEC 15944 are under review or (minor) revision which may be completed in 2014 or 2015 for their next edition. As such the dates in the Normative references will be updated accordingly. (This will also impact updates to relevant entries in Clause 3)

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

2.1 ISO/IEC, ISO and ITU27

ISO 639-2:1998 (E/F), Codes for the representation of names of languages — Part 2: Alpha-3 code/Codes pour la représentation des noms de langue — Partie 2: Code alpha-3

ISO 1087-1:2000 (E/F), Terminology work — Vocabulary — Part 1: Theory and application/Travaux terminologiques — Vocabulaire — Partie 1: Théorie et application

ISO/IEC 2382 (all parts) (E/F), Information technology — Vocabulary/Technologies de l'information — Vocabulaire

ISO 3166-1:2013 (E/F), Codes for the representation of names of countries and their subdivisions — Part 1: Country codes/Codes pour la représentation des noms de pays et de leur subdivisions — Partie 1: Codes pays

ISO 3166-2:2013 (E/F), Codes for the representation of names of countries and their subdivisions — Part 2: Country subdivision code/Codes pour la représentation des noms de pays et de leurs subdivisions — Partie 2: Code pour les subdivisions de pays

ISO 5127:2001(E), Information and documentation — Vocabulary

ISO/IEC 5218:2004(E/F), Information technology — Codes for the representation of human sexes/ Technologies de l’information — Codes de représentation des sexes humains

ISO/IEC 6523-1:1998(E/F), Information technology — Structure for the identification of organizations and organization parts — Part 1: Identification of organization identification schemes/Technologies de l'information — Structures pour l'identification des organisations et des parties d'organisations — Partie 1: Identification des systèmes d'identification d'organisations

ISO/IEC 6523-2:1998(E/F), Information technology — Structure for the identification of organizations and organization parts — Part 2: Registration of organization identification schemes/Technologies de l'information — Structures pour l'identification des organisations et des parties d'organisations — Partie 2: Enregistrement des systèmes d'identification d'organisations

27 For standards referenced for which both English and French versions are available both the English and French language titles are provided. This is independent of whether the English and French language versions of the standard are published as a single document or as separate documents. For those standards which are available in English only, only the English language title is provided.


152

960

961

962

963964965

966967

968969970

971972973

974

975976

977978

979980

981982983

984985986

987

988989

990991992993

994995996997

153154155156

CD ISO/IEC 15944-12:2014(E)

ISO/IEC 7501-1:2008(E), Identification cards — Machine readable travel documents — Part 1: Machine readable passport

ISO/IEC 7501-2:1997(E), Identification cards — Machine readable travel documents — Part 2: Machine readable visa

ISO/IEC 7501-3:2005(E), Identification cards — Machine readable travel documents — Part 3: Machine readable official travel documents

ISO/IEC 7812-1:2006(E), Identification cards — Identification of issuers — Part 1: Numbering system

ISO/IEC 7812-2:2007(E), Identification cards — Identification of issuers — Part 2: Application and registration procedures

ISO 8601:2004(E), Data elements and interchange formats — Information interchange — Representation of dates and times

ISO/IEC 14662:2010(E/F), Information technology — Open-edi reference model/Technologies de l'information — Modèle de référence EDI-ouvert

ISO/IEC 15944-1:2011(E), Information technology — Business Operational View — Part 1: Operational aspects of Open-edi for implementation

ISO/IEC 15944-2:2014(E), Information technology — Business Operational View — Part 2: Registration of scenarios and their components as business objects

ISO/IEC 15944-4:2014(E), Information technology — Business Operational View — Part 4: Business transactions and scenarios — Accounting and economic ontology

ISO/IEC 15944-5:2014(E), Information technology — Business Operational View — Part 5: Identification and referencing of requirements of jurisdictional domains as sources external constraints

ISO/IEC 15944-7:2009(E), Information technology — Business Operational View — Part 7: eBusiness vocabulary

ISO/IEC 15944-8:2012 Information technology — Business Operational View — Part 8: Identification of privacy protection requirements as external constraints on business transactions

ISO/IEC CD3 15944-9 Information technology — Business Operational View — Part 9: Traceability framework

ISO/IEC 15944-10 Information technology — Business Operational View — Part 10: Coded domains

ISO 19108:2002(E), Geographic information — Temporal schema

ISO/IEC 19501:2005(E), Information technology— Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.228

ISO 22857:2004(E), Health informatics — Guidelines on data protection to facilitate trans-border flows of personal health information

2.2 Referenced specifications29

APEC Privacy Framework. (2005)

28 Throughout this part of ISO/IEC 15944, ISO/IEC 19501:2005 is simply referenced as “UML”.

29 All references in this sub-clause were correct at the time of approval of this part of ISO/IEC 15944. The provisions of the referenced specifications, as identified in this sub-clause, are valid within the context of this part of ISO/IEC 15944. The reference to a specification within this part of ISO/IEC 15944 does not give it any further status within ISO/IEC; in particular, it does not give the referenced specification the status of an International Standard.


158

998999

10001001

10021003

1004

10051006

10071008

10091010

10111012

10131014

10151016

10171018

10191020

10211022

1023

1024

1025

10261027

10281029

1030

1031

159

160161162163

CD ISO/IEC 15944-12:2014(E)

Charter of the United Nations (as signed 1945 and Amended 1965, 1968, and 1973+), United Nations (UN).

Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data (1995) Directive

OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data (1980)

UN Convention on the Rights of Disabled Persons (2006+)

Vienna Convention of the Law of Treaties (1969), United Nations (UN)

3 Terms and definitions


1. The initial set of terms and definitions presented is based on those in Clause 3 of Part 8. Not all may be relevant to Part 12 and therefore will be deleted at the pre-DIS stage.

2. Other terms and definitions are those based on document SC32/WG1 N0715 titled “Added key ILCM concepts, definitions and rules for the development of ISO/IEC 15944-12”. These were agreed to be added following the Santa Fe SC32/WG1 meeting.

3. In addition a definition for the concept of “information life cycle management (“ILCM”) has been developed. The following is the text that was also accepted at the Santa Fe meeting:

information life cycle management (ILCM)

series of actions and rules governing the management and its electronic data interchange (EDI) of set(s) of recorded information (SRIs) under the control of a Person from its creation to final disposition in compliance with applicable information law requirements.

NOTE: The inclusion of “information law” brings into this definition all the various information management activities.

4. We may need the concept/definition for “under the control of”

This is to cover those situations where the physical or electronic records of an organization (as a seller) are located at a site other than which it owns, or rents. Typical examples here include:

1. an organization subcontracting or outsourcing the storage of its physical or electronic SRIs to an “agent” who provides “off-site” storage facilities for dormant records.

2. An organization sub-contracting or outsourcing part or all of its data processing, telecommunications, etc. activities to an “agent” (e.g. as a VAN or cloud service ITC services provider)

In these and other cases the seller organization still maintains control of the SRIs themselves through is management rules, of the recorded information pertaining to a business transaction, including any personal information pertaining to a (prospective) buyer as an individual.. It is not clear at this time whether “under the control of” needs to be defined or whether this requirements s of this nature should be addressed through a series of rules to that effect, i.e., that the seller shall maintain and ensure control of any state changes and/or ILCM aspects for any personal information, created, collected or received, interchanged, etc with respect to a (prospective) buyer who is an individual.

5. In addition, several Parts of ISO/IEC 15944 are under review or (minor) revision which may be completed in 2014 or 2015 for their next edition. As such the information on their reference in Clause 3 will be updated as required.


165

1032

103310341035

1036

1037

1038

1039

1040

10411042

104310441045

10461047

1048

104910501051

10521053

1054

10551056

10571058

10591060

1061106210631064106510661067

106810691070

CD ISO/IEC 15944-12:2014(E)

6. There are entries in Clause 3 which likely are not or will not be used when the development of the CD ballot document for Part 12 is completed. These will be deleted. A final check here will take place at the DIS stage.

For the purposes of this document, the following terms and definitions apply.

3.1addressset of data elements that specifies a location to which a recorded information item(s), a business object(s), a material object(s) and/or a person(s) can be sent or from which it can be received

NOTE 1 An address can be specified as either a physical address and/or electronic address.

NOTE 2 In the identification, referencing and retrieving of registered business objects, it is necessary to state whether the pertinent recorded information is available in both physical and virtual forms.

NOTE 3 In the context of Open-edi, a “recorded information item” is modelled and registered as an Open-edi scenario (OeS), Information Bundle (IB) or Semantic Component (SC).

[ISO/IEC 15944-2:2014, 3.1]

3.2agentPerson acting for another Person in a clearly specified capacity in the context of a business transaction

NOTE Excluded here are agents as "automatons" (or robots, bobots, etc.). In ISO/IEC 14662:2009, "automatons" are recognized and provided for but as part of the Functional Service View (FSV) where they are defined as an "Information Processing Domain (IPD)".

[ISO/IEC 15944-1:2011, 3.1]

3.3anonymizationprocess whereby the association between a set of recorded information (SRI) and an identifiable individual is removed where such an association may have existed

NOTE Adapted from ISO 25237.

[ISO/IEC 15944-8:2012, 3.3]

3.4attributecharacteristic of an object or entity

[ISO/IEC 11179-3:2003, 3.1.3]

3.5audit trailchronological record of IT system activities that is sufficient to enable the reconstruction, reviewing and examination of the sequence of environments and activities surrounding or leading to an operation, a procedure, or an event pertaining to sets of recorded information (SRIs) in a business transaction through all its processes, i.e., from planning to the end of post-actualization

3.6authenticationprovision of assurance of the claimed identity of an entity

[ISO/IEC 10181-2:1996, 3.3]


167

107110721073

1074

1075107610771078

1079

10801081

10821083

1084

108510861087

108810891090

1091

1092109310941095

1096

1097

109810991100

1101

1102110311041105110611071108

110911101111

1112

CD ISO/IEC 15944-12:2014(E)

3.7authenticityproperty that ensures that the identity of a subject or resource is the one claimed. Authenticity applies to entities such as users, processes, systems and information

NOTE Authenticity applies to entities such as users, processes, systems and information.

[ISO/IEC TR 13335-1:1996, 3.3]

3.8back-up copycopy that is any of the following: a) additional resource or duplicate copy of data on different a storage medium stored off-line for emergency purposes; b) disk, tape or other machine-readable copy of a data or program file; c) data or program file recorded and stored off-line for emergency or archival purposes; d) record that preserves the evidence and information it contains if the original is not available

3.9businessseries of processes, each having a clearly understood purpose, involving more than one Person, realized through the exchange of recorded information and directed towards some mutually agreed upon goal, extending over a period of time

[ISO/IEC 14662:2010, 3.2]

3.10business eventoccurrence in time that partners to a business transaction wish to monitor or control

NOTE 1 Business events are the workflow tasks that business partners need to accomplish to complete a business transaction among themselves. As business events occur, they cause a business transaction to move through its various phases of planning, identification, negotiation, actualization, and post-actualization.

NOTE 2 Occurrences in time can either be: (a) internal as mutually agreed to among the parties to a business transaction; and/or, (b) reference some common publicly available and recognized date/time referencing schema, (e.g., one based on using the ISO 8601 and/or ISO 19135 standards).

[ISO/IEC 15944-4:2014, 3.5]

3.11business objectunambiguously identified, specified, referenceable, registered and re-useable Open-edi scenario, or scenario component of a business transaction

NOTE As an “object”, a “business object” exists only in the context of a business transaction.

[ISO/IEC 15944-2:2014, 3.6]

3.12Business Operational View (BOV)perspective of business transactions limited to those aspects regarding the making of business decisions and commitments among Persons, which are needed for the description of a business transaction

[ISO/IEC 14662:2010, 3.3]

3.13business transactionpredefined set of activities and/or processes of Persons which is initiated by a Person to accomplish an explicitly shared business goal and terminated upon recognition of one of the agreed conclusions by all the involved Persons although some of the recognition may be implicit


169

1113111411151116

1117

1118

1119112011211122112311241125

11261127112811291130

1131

113211331134

113511361137

113811391140

1141

1142114311441145

1146

1147

1148114911501151

1152

11531154115511561157

CD ISO/IEC 15944-12:2014(E)

[ISO/IEC 14662:2010, 3.4]

3.14business transaction identifier (BTI)identifier assigned by a seller or a regulator to an instantiated business transaction among the Persons involved

NOTE 1 The identifier assigned by the seller or regulator shall have the properties and behaviours of an “identifier (in a business transaction)”.

NOTE 2 As an identifier (in a business transaction), a BTI serves as the unique common identifier for all Persons involved for the identification, referencing, retrieval of recorded information, etc., pertaining to the commitments made and the resulting actualization (and post-actualization) of the business transaction agreed to.

NOTE 3 A business transaction identifier can be assigned at any time during the planning, identification or negotiation phases but shall be assigned at least prior to the start or during the actualization phase.

NOTE 4 As and where required by the applicable jurisdictional domain(s), the recorded information associated with the business transaction identifier (BTI) may well require the seller to include other identifiers, (e.g., from a value-added good or service tax, etc., perspective) as assigned by the applicable jurisdictional domain(s).

[ISO/IEC 15944-5: 2014, 3.12]

3.15buyerPerson who aims to get possession of a good, service and/or right through providing an acceptable equivalent value, usually in money, to the Person providing such a good, service and/or right

[ISO/IEC 15944-1:2011, 3.8]

3.16characteristicabstraction of a property of an object or of a set of objects

NOTE Characteristics are used for describing concepts.

[ISO 1087-1:2000, 3.2.4]

3.17character setfinite set of different characters that is complete for a given purpose

EXAMPLE The international reference version of the character set of ISO 10646.

[ISO/IEC 2382-4:1999, 04.01.02]

3.18classification systemsystematic identification and arrangement of business activities and/or scenario components into categories according to logically structured conventions, methods and procedural rules as specified in a classification schema

NOTE 1 The classification code or number often serves as a semantic identifier (SI) for which one or more human interface equivalents (HIEs) exist.

NOTE 2 The rules of a classification schema governing the operation of a classification system at times lead to the use of ID codes which have an intelligence built into them, (e.g., in the structure of the ID, the manner in which it can be parsed, etc.). Here the use of block-numeric numbering schemas is an often used convention.

NOTE 3 Adapted from ISO 15489-1:2001, 3.5.


171

1158

1159116011611162

11631164

116511661167

11681169

117011711172

1173

1174117511761177

1178

117911801181

1182

1183

118411851186

1187

1188

11891190119111921193

11941195

119611971198

1199

CD ISO/IEC 15944-12:2014(E)

[ISO/IEC 15944-5:2014, 3.17]

3.19codeset of data representation in different forms according to a pre-established set of rules

NOTE In this standard the "pre-established set of rules" is determined and enacted by a Source Authority and must be explicitly stated.

[ISO 639-2:2013, 3.1]

3.20code (in coded domain)identifier, i.e., an ID code, assigned to an entity as member of a coded domain according to the pre-established set of rules governing that coded domain

[ISO/IEC 15944-5:2008, 3.19]

3.21coded domaindomain for which (1) the boundaries are defined and explicitly stated as a rulebase of a coded domain Source Authority; and (2) each entity which qualifies as a member of that domain is identified through the assignment of a unique ID code in accordance with the applicable Registration Schema of that Source Authority

NOTE 1 The rules governing the assignment of an ID code to members of a coded domain reside with its Source Authority and form part of the Coded Domain Registration Schema of the Source Authority.

NOTE 2 Source Authorities which are jurisdictional domains are the primary source of coded domains.

NOTE 3 A coded domain is a data set for which the contents of the data element values are predetermined and defined according to the rulebase of its Source Authority and as such have predefined semantics.

NOTE 4 Associated with a code in a coded domain can be: (a) one and/or more equivalent codes; (b) one and/or more equivalent representations especially those in the form of Human Interface Equivalent (HIE) (linguistic) expressions.

NOTE 5 In a coded domain the rules for assignment and structuring of the ID codes must be specified.

NOTE 6 Where an entity as member of a coded domain is allowed to have, i.e., assigned, more than one ID code, i.e., as equivalent ID codes (possibly including names), one of these must be specified as the pivot ID code.

NOTE 7 A coded domain in turn can consist of two or more coded domains, i.e., through the application of the inheritance principle of object classes.

NOTE 8 A coded domain may contain ID code which pertains to predefined conditions other than qualification of membership of entities in the coded domain. Further, the rules governing a coded domain may or may not provide for user extensions.

EXAMPLE (1) The use of ID Code "0" (or "00", etc.) for “Others, (2) the use of ID Code "9" (or "99", etc.) for “Not Applicable”; (3) the use of “8” (or “98”) for “Not Known”; and/or, if required, (4) the pre-reservation of a series of ID codes for use of “user extensions”.

NOTE 9 In object methodology, entities which are members of a coded domain are referred to as instances of a class.

EXAMPLE In UML modelling notation, an ID code is viewed as an instance of an object class.

[ISO/IEC 15944-2:2014, 3.13]


173

1200

120112021203

12041205

1206

1207120812091210

1211

121212131214121512161217

12181219

1220

12211222

12231224

1225

12261227

12281229

123012311232

123312341235

1236

1237

1238

CD ISO/IEC 15944-12:2014(E)

3.22coded Domain Registration Schema (cdRS)formal definition of both (1) the data fields contained in the identification and specification of an entity forming part of the members a coded domain including the allowable contents of those fields; and, (2) the rules for the assignment of identifiers

[ISO/IEC 15944-5:2014, 3.21]

3.23coded domain Source Authority (cdSA)Person, usually an organization, as a Source Authority which sets the rules governing a coded domain

NOTE 1 Source Authority is a role of a Person and for widely used coded domains the coded domain Source Authority is often a jurisdictional domain.

NOTE 2 Specific sectors, (e.g., banking, transport, geomatics, agriculture, etc.), may have particular coded domain Source Authority (ies) whose coded domains are used in many other sectors.

NOTE 3 A coded domain Source Authority usually also functions as a Registration Authority but can use an agent, i.e., another Person, to execute the registration function on its behalf.

[ISO/IEC 15944-2:2014, 3.14]

3.24collaboration spacebusiness activity space where an economic exchange of valued resources is viewed independently and not from the perspective of any business partner

NOTE In collaboration space, an individual partner’s view of economic phenomena is de-emphasized. Thus, the common use business and accounting terms like purchase, sale, cash receipt, cash disbursement, raw materials, and finished goods is not allowed because they view resource flows from a participant’s perspective.

[ISO/IEC 15944-4:2014, 3.12]

3.25commitmentmaking or accepting of a right, obligation, liability or responsibility by a Person that is capable of enforcement in the jurisdictional domain in which the commitment is made

[ISO/IEC 14662:2010, 3.5]

3.26composite identifieridentifier (in a business transaction) functioning as a single unique identifier consisting of one or more other identifiers, and/or one or more other data elements, whose interworkings are rule-based

NOTE 1 Identifiers (in business transactions) are for the most part composite identifiers.

NOTE 2 The rules governing the structure and working of a composite identifier should be specified.

NOTE 3 Most widely used composite identifiers consist of the combinations of: (a) the ID of the overall identification/numbering schema, (e.g., ISO/IEC 6532, ISO/IEC 7812, ISO/IEC 7506, UPC/EAN, ITU-T E.164, etc.), which is often assumed; (b) the ID of the issuing organization (often based on a block numeric numbering schema); and, (c) the ID of the entities forming part of members of the coded domain of each issuing organization.

[ISO/IEC 15944-2:2014, 3.16]


175

12391240124112421243

1244

124512461247

12481249

12501251

12521253

1254

1255125612571258

125912601261

1262

1263126412651266

1267

1268126912701271

1272

1273

1274127512761277

1278

CD ISO/IEC 15944-12:2014(E)

3.27computational integrityexpression of a standard in a form that ensures precise description of behaviour and semantics in a manner that allows for automated processing to occur, and the managed evolution of such standards in a way that enables dynamic introduction by the next generation of information systems

NOTE Open-edi standards have been designed to be able to support computational integrity requirements especially from a registration and re-use of business objects perspectives.

[ISO/IEC 15944-2:2014, 3.18]

3.28constraintrule, explicitly stated, that prescribes, limits, governs or specifies any aspect of a business transaction

NOTE 1 Constraints are specified as rules forming part of components of Open-edi scenarios, i.e., as scenario attributes, roles, and/or information bundles.

NOTE 2 For constraints to be registered for implementation in Open-edi, they must have unique and unambiguous identifiers.

NOTE 3 A constraint may be agreed to among parties, (condition of contract) and is therefore considered an "internal constraint". Or a constraint may be imposed on parties, (e.g., laws, regulations, etc.), and is therefore considered an "external constraint".

[ISO/IEC 15944-1:2011, 3.11]

3.29consumerbuyer who is an individual to whom consumer protection requirements are applied as a set of external constraints on a business transaction

NOTE 1 Consumer protection is a set of explicitly defined rights and obligations applicable as external constraints on a business transaction.

NOTE 2 The assumption is that a consumer protection applies only where a buyer in a business transaction is an individual. If this is not the case in a particular jurisdiction, such external constraints should be specified as part of scenario components as applicable.

NOTE 3 It is recognized that external constraints on a buyer of the nature of consumer protection may be peculiar to a specified jurisdiction.

[ISO/IEC 15944-1:2011, 3.12]

3.30consumer protectionset of external constraints of a jurisdictional domain as rights of a consumer and thus as obligations (and possible liabilities) of a vendor in a business transaction which apply to the good, service and/or right forming the object of the business transaction (including associated information management and interchange requirements including applicable (sets of) recorded information

NOTE 1 Jurisdictional domains may restrict the application of their consumer protection requirements as applicable only to individuals engaged in a business transaction of a commercial activity undertaken for personal, family or household purposes, i.e., they do not apply to natural persons in their role as "organization" or "organization Person".

NOTE 2 Jurisdictional domains may have particular consumer protection requirements which apply specifically to individuals who are considered to be a "child" or a “minor”, (e.g., those individuals who have not reached their thirteenth (13) birthday).

NOTE 3 Some jurisdictional domains may have consumer protection requirements which are particular to the nature of the good, service and/or right being part of the goal of a business transaction.


177

12791280128112821283

12841285

1286

128712881289

12901291

12921293

129412951296

1297

1298129913001301

13021303

130413051306

13071308

1309

131013111312131313141315

131613171318

131913201321

13221323

CD ISO/IEC 15944-12:2014(E)

[ISO/IEC 15944-5:2014, 3.33]

3.31controlled vocabulary (CV)vocabulary whose entries, i.e., definition/term pairs, are controlled by a Source Authority based on a rulebase and process for addition/deletion of entries

NOTE 1 In a controlled vocabulary, there is a one-to-one relationship of definition and term.

EXAMPLE The contents "Clause 3 Definitions" in ISO/IEC standards are examples of controlled vocabularies with the entities being identified and referenced through their ID codes, i.e., via their clause numbers.

NOTE 2 In a multilingual controlled vocabulary, the definition/term pairs in the languages used are deemed to be equivalent, i.e., with respect to their semantics.

NOTE 3 The rulebase governing a controlled vocabulary may include a predefined concept system.

[ISO/IEC 15944-5:2014, 3.34]

3.32data (in a business transaction)representations of recorded information that are being prepared or have been prepared in a form suitable for use in a computer system

[ISO/IEC 15944-1:2011, 3.14]

3.33data conversionprocess(es) of changing data, i.e., set(s) of recorded information (SRI(s)) from one format or representation to another which maintains the authenticity, integrity, reliability and usability of the SRI(s) as well as relevant ILCM requirements, and especially those of an external constraints nature including privacy protection requirements where the data involves personal information

NOTE: A characteristics of data conversion is a change in the technology used for managing and/or representing the contents of the SRI.”

EXAMPLE: Examples include data conversion resulting from a change in text processing software (e.g. MsWord to HTML), from one database software to another, from a non-data based software to a database based software approach or vice-versa, etc

NOTE Adapted from CAN/CGSB-72.34-2005, 3.16

3.34data elementunit of data for which the definition, identification, representation and permissible values are specified by means of a set of attributes

[ISO/IEC 11179-1:2004, 3.3.8]

3.35data element (in organization of data)unit of data that is considered in context to be indivisible

EXAMPLE The data element "age of a person" with values consisting of all combinations of 3 decimal digits.

NOTE Differs from the entry 17.06.02 in ISO/IEC 2382-17.

[ISO/IEC 2382-04:1998, 04.07.01]


179

1324

1325132613271328

1329

13301331

13321333

1334

1335

1336133713381339

1340

134113421343134413451346

13471348

134913501351

13521353

1354135513561357

1358

135913601361

1362

1363

1364

CD ISO/IEC 15944-12:2014(E)

3.36data migrationmoving sets of recorded information from one IT System or device to another, as required by changes in an IT System configuration or as requested by the user, while assuring that the data will remain addressable and that data integrity will be maintained in the new environment

3.37datasetidentifiable collection of data

NOTE A dataset may be a smaller grouping of data which, though limited by some constraint such as spatial extent or feature type, is located physically within a larger dataset. Theoretically, a dataset may be as small as a single feature or feature attribute contained within a larger dataset. A hardcopy map or chart may be considered a dataset.

[ISO 19115:2003, 4.2]

3.38dataset seriescollection of datasets sharing the same product specification

[ISO 19115:2003, 4.3]

3.39data synchronization (in business transaction)process of continuous harmonization of a set(s) of recorded information among all the parties to a business transaction to ensure that the current state of the content value(s) of such a set(s) of recorded information is the same in the IT systems of all the participating parties

NOTE Adapted from GS1 Global Traceability Standard (GDSN) Glossary.

3.40Decision Making Application (DMA)model of that part of an Open-edi system that makes decisions corresponding to the role(s) that the Open-edi Party plays as well as the originating, receiving and managing data values contained in the instantiated Information Bundles which is not required to be visible to the other Open-edi Parties (OeP)

[ISO/IEC 14662:2010, 3.7]

3.41de facto languagenatural language used in a jurisdictional domain which has the properties and behaviours of an official language in that jurisdictional domain without having formally been declared as such by that jurisdictional domain

NOTE 1 A de facto language of a jurisdictional domain is often established through long term use and custom.

NOTE 2 Unless explicitly stated otherwise and for the purposes of modelling a business transaction through scenario(s), scenario attributes and/or scenario components, a de facto language of a jurisdictional domain is assumed to have the same properties and behaviours of an official language.

[ISO/IEC 15944-5:2014, 3.42]

3.42definitionrepresentation of a concept by a descriptive statement which serves to differentiate it from related concepts

[ISO/IEC 1087-1:2000, 3.3.1]


181

13651366136713681369

137013711372

137313741375

1376

137713781379

1380

13811382138313841385

1386

13871388138913901391

1392

13931394139513961397

1398

139914001401

1402

140314041405

1406

CD ISO/IEC 15944-12:2014(E)

3.43designationrepresentation of a concept by a sign which denotes it

NOTE 1 In terminology work three types of designations are distinguished: symbols, appellations and terms.

NOTE 2 Adapted from ISO 1087-1:2000, 3.4.1.

[ISO/IEC 15944-2:20014, 3.79]

3.44distinguishing identifierdata that unambiguously distinguishes an entity in the authentication process

[ISO/IEC 10181-2:1996, 3.11]

3.45eBusinessbusiness transaction, involving the making of commitments, in a defined collaboration space, among Persons using their IT Systems, according to Open-edi standards

NOTE 1 eBusiness can be conducted on both a for-profit and not-for-profit basis.

NOTE 2 A key distinguishing aspect of eBusiness is that it involves the making of commitment(s) of any kind among the Persons in support of a mutually agreed upon goal, involving their IT Systems, and doing so through the use of EDI (using a variety of communication networks including the Internet).

NOTE 3 eBusiness includes various application areas such as e-commerce, e-administration, e-logistics, e-government, e-medicine, e-learning, etc.

NOTE 4 The equivalent French language term for “eBusiness” is always presented in its plural form.

[ISO/IEC 15944-7:2009, 3.06]

3.46electronic addressaddress used in a recognized electronic addressing scheme, (e.g., telephone, telex, IP, etc.), to which recorded information item(s) and/or business object(s) can be sent to or received from a Contact

[ISO/IEC 15944-2:2014, 3.32]

3.47Electronic Data Interchange (EDI)automated exchange of any predefined and structured data for business purposes among information systems of two or more Persons

NOTE This definition includes all categories of electronic business transactions.

[ISO/IEC 14662:2010, 3.8]

3.48electronic signaturesignature that consists of one or more letters, characters, numbers or other symbols in digital form incorporated in, attached to or associated with a particular digital/electronic set of recorded information (SRI)

NOTE Adapted from PIPEDA, Part 2, section 31(1); CAN/CGSB-72.34-2005, 3.28.


183

140714081409

1410

1411

1412

141314141415

1416

1417141814191420

1421

142214231424

14251426

1427

1428

1429143014311432

1433

1434143514361437

1438

1439

1440144114421443144414451446

CD ISO/IEC 15944-12:2014(E)

3.49entityany concrete or abstract thing that exists, did exist, or might exist, including associations among these things

EXAMPLE A person, object, event, idea, process, etc.

NOTE An entity exists whether data about it are available or not.

[ISO/IEC 2382-17:1999, 17.02.05]

3.50entity authenticationcorroboration that the entity is the one claimed

[ISO/IEC 9798-1:1997, 3.3.11]

3.51exchange code setset of ID codes identified in a coded domain as being suitable for information exchange as shareable data

EXAMPLE The 3-numeric, 2-alpha and 3-alpha code sets in ISO 3166-1.

[ISO/IEC 15944-5:2014, 3.49]

3.52external constraintconstraint which takes precedence over internal constraints in a business transaction, i.e., is external to those agreed upon by the parties to a business transaction

NOTE 1 Normally external constraints are created by law, regulation, orders, treaties, conventions or similar instruments.

NOTE 2 Other sources of external constraints are those of a sectoral nature, those which pertain to a particular jurisdiction or a mutually agreed to common business conventions, (e.g., INCOTERMS, exchanges, etc.).

NOTE 3 External constraints can apply to the nature of the good, service and/or right provided in a business transaction.

NOTE 4 External constraints can demand that a party to a business transaction meet specific requirements of a particular role.

EXAMPLE 1 Only a qualified medical doctor may issue a prescription for a controlled drug.

EXAMPLE 2 Only an accredited share dealer may place transactions on the New York Stock Exchange.

EXAMPLE 3 Hazardous wastes may only be conveyed by a licensed enterprise.

NOTE 5 Where the Information Bundles (IBs), including their Semantic Components (SCs) of a business transaction are also to form the whole of a business transaction, (e.g., for legal or audit purposes), all constraints must be recorded.

EXAMPLE There may be a legal or audit requirement to maintain the complete set of recorded information pertaining to a business transaction, i.e., as the information bundles exchanged, as a "record".

NOTE 6 A minimum external constraint applicable to a business transaction often requires one to differentiate whether the Person, i.e., that is a party to a business transaction, is an "individual", "organization", or "public administration". For example, privacy rights apply only to a Person as an "individual".

[ISO/IEC 15944-1:2011, 3.23]


185

144714481449

1450

1451

1452

145314541455

1456

145714581459

1460

1461

1462146314641465

14661467

14681469

14701471

14721473

1474

1475

1476

14771478

14791480

148114821483

1484

CD ISO/IEC 15944-12:2014(E)

3.53Formal Description Technique (FDT)specification method based on a description language using rigorous and unambiguous rules both with respect to developing expressions in the language (formal syntax) and interpreting the meaning of these expressions (formal semantics)

[ISO/IEC 14662:2010, 3.9]

3.54 Functional Service View (FSV)perspective of business transactions limited to those information technology interoperability aspects of IT Systems needed to support the execution of Open-edi transactions

[ISO/IEC 14662:2010, 3.10]

3.55Human Interface Equivalent (HIE)representation of the unambiguous and IT-enabled semantics of an IT interface equivalent (in a business transaction), often the ID code of a coded domain (or a composite identifier), in a formalized manner suitable for communication to and understanding by humans

NOTE 1 Human interface equivalents can be linguistic or non-linguistic in nature but their semantics remain the same although their representations may vary.

NOTE 2 In most cases there will be multiple human interface equivalent representations as required to meet localization requirements, i.e., those of a linguistic nature, jurisdictional nature, and/or sectoral nature.

NOTE 3 Human interface equivalents include representations in various forms or formats, (e.g., in addition to written text those of an audio, symbol (and icon) nature, glyphs, image, etc.).

[ISO/IEC 15944-2:2014, 3.35]

3.56IB Identifierunique, linguistically neutral, unambiguous referenceable identifier for an Information Bundle

[ISO/IEC 15944-2:2014, 3.36]

3.57ID codeidentifier assigned by the coded domain Source Authority (cdSA) to a member of a coded domain ID

NOTE 1 ID codes must be unique within the Registration Schema of that coded domain.

NOTE 2 Associated with an ID code in a coded domain can be: (a) one or more equivalent codes; (b) one or more equivalent representations, especially those in the form of human equivalent (linguistic) expressions.

NOTE 3 Where an entity as a member of a coded domain is allowed to have more than one ID code, i.e., as equivalent codes (possibly including names), one of these must be specified as the pivot ID code.

NOTE 4 A coded domain may contain ID codes pertaining to entities which are not members as peer entities, i.e., have the same properties and behaviours, such as ID codes which pertain to predefined conditions other than member entities. If this is the case, the rules governing such exceptions must be predefined and explicitly stated.

EXAMPLE (1) The use of an ID code "0" (or "00", etc.), for “Other”; (2) the use of an ID code "9" (or "99") for “Not Applicable”; (3) the use of “8” (or “98”) for “Not Known”; if required, (4) the pre-reservation of a series or set of ID codes for use for "user extensions".

NOTE 5 In UML modeling notation, an ID codes is viewed as an instance of an object class.

[ISO/IEC 15944-2:2014, 3.37]


187

14851486148714881489

1490

1491149214931494

1495

14961497149814991500

15011502

15031504

15051506

1507

150815091510

1511

151215131514

1515

15161517

15181519

152015211522

152315241525

1526

1527

CD ISO/IEC 15944-12:2014(E)

3.58identificationrule-based process, explicitly stated, involving the use of one or more attributes, i.e., data elements, whose value (or combination of values) are used to identify uniquely the occurrence or existence of a specified entity

[ISO/IEC 15944-1:2011, 3.26]

3.59identifier (in business transaction)unambiguous, unique and a linguistically neutral value, resulting from the application of a rule-based identification process

NOTE 1 Identifiers must be unique within the identification scheme of the issuing authority.

NOTE 2 An identifier is a linguistically independent sequence of characters capable of uniquely and permanently identifying that with which it is associated. (See ISO 19135:2005 (4.1.5)

[ISO/IEC 15944-1:2011, 3.27]

3.60individualPerson who is a human being, i.e., a natural person, who acts as a distinct indivisible entity or is considered as such

[ISO/IEC 15944-1:2011, 3.28]

3.61individual accessibilityset of external constraints of a jurisdictional domain as rights of an individual with disabilities to be able to use IT Systems at the human, i.e., user, interface and the concomitant obligation of a seller to provide such adaptive technologies

NOTE Although “accessibility” typically addresses users who have a disability, the concept is not limited to disability issues.

EXAMPLE Disabilities in the form of functional and cognitive limitations include: (a) people who are blind;(b) people with low vision; (c) people with colour blindness; (d) people who are hard of hearing or deaf, i.e., are hearing impaired; (e) people with physical disabilities; and, (f) people with language or cognitive disabilities.

[ISO/IEC 15944-5:2014, 3.60]

3.62individual anonymitystate of not knowing the identity or not having any recording of personal information on or about an individual as a buyer by the seller or regulator, (or any other party) to a business transaction

3.63individual authenticationprovision of the assurance of a recognized individual identity (rii) sufficient for the purpose of the business transaction

3.64individual identity (ii)Person identity of an individual, i.e., an individual identity, consisting of the combination of the persona information and identifier used by an individual in a business transaction, i.e., the making of any kind of commitment

[ISO/IEC 15944-8:2012, 3.69]


189

1528152915301531

1532

1533153415351536

1537

15381539

1540

1541154215431544

1545

15461547154815491550

15511552

155315541555

1556

1557155815591560

1561156215631564

15651566156715681569

1570

CD ISO/IEC 15944-12:2014(E)

3.65individual persona Registration Schema (ipRS)persona Registration Schema (pRS) where the persona is, or includes, that of an individual being registered

NOTE 1 Where a persona Registration Schema includes persona of sub-types of Persons, i.e., individuals, organizations, and/or, public administrations, those which pertain to individuals shall be identified as such because public policy as external constraints apply including those of a privacy protection requirements nature.

NOTE 2 In an individual persona Registration Schema, one shall state whether or not a truncated name, i.e. registered persona, of the individual, is allowed or mandatory, and if so, the ipRS shall explicitly state the rules governing the formation of the same.

[ISO/IEC 15944-8:2012, 3.60]

3.66Information Bundle (IB)formal description of the semantics of the recorded information to be exchanged by Open-edi Parties playing roles in an Open-edi scenario

[ISO/IEC 14662:2010, 3.11]

3.67information lawany law, regulation, policy, or code (or any part thereof) that requires the creation, receipt, collection, description or listing, production, retrieval, submission, retention, storage, preservation or destruction of recorded information, and/or that places conditions on the access and use, confidentiality, privacy, integrity, accountabilities, continuity and availability of the processing, reproduction, distribution, transmission, sale, sharing or other handling of recorded information

[ISO/IEC 15944-8:2012, 3.62]

3.68Information Processing Domain (IPD)Information Technology System which includes at least either a Decision Making Application (DMA) and/or one of the components of an Open-edi Support Infrastructure, and acts/executes on behalf of an Open-edi Party (either directly or under a delegated authority)

[ISO/IEC 14662:2010, 3.12]

3.69Information Technology System (IT System)set of one or more computers, associated software, peripherals, terminals, human operations, physical processes, information transfer means, that form an autonomous whole, capable of performing information processing and/or information transfer

[ISO/IEC 14662:2010, 3.13]

3.70internal constraintconstraint which forms part of the commitment(s) mutually agreed to among the parties to a business transaction

NOTE Internal constraints are self-imposed. They provide a simplified view for modelling and re-use of scenario components of a business transaction for which there are no external constraints or restrictions to the nature of the conduct of a business transaction other than those mutually agreed to by the buyer and seller.

[ISO/IEC 15944-1:2011, 3.33]


191

1571157215731574

157515761577

157815791580

1581

1582158315841585

1586

1587158815891590159115921593

1594

15951596159715981599

1600

16011602160316041605

1606

1607160816091610

161116121613

1614

CD ISO/IEC 15944-12:2014(E)

3.71IT-enablementtransformation of a current standard used in business transactions, (e.g., coded domains), from a manual to computational perspective so as to be able to support commitment exchange and computational integrity

[ISO/IEC 15944-5:2014, 3.65]

3.72IT-interface equivalentcomputer processable identification of the unambiguous semantics of a scenario, scenario attribute and/or scenario component(s) pertaining to a commitment exchange in a business transaction which supports computational integrity

NOTE 1 IT interface equivalents have the properties of identifiers (in business transaction) and are used to support semantic interoperability in commitment exchange.

NOTE 2 The value of an IT interface equivalent at times is a composite identifier.

NOTE 3 An IT interface equivalent as a composite identifier can consist of the identifier of a coded domain plus an ID code of that coded domain.

NOTE 4 An IT interface equivalent is at times used as a semantic identifier.

NOTE 5 An IT interface equivalent may have associated with it one or more human interface equivalents (HIEs).

NOTE 6 The value of an IT Interface is independent of its encoding in programming languages or APIs.

[ISO/IEC 15944-2:2014, 3.45]

3.73jurisdictional domainjurisdiction, recognized in law as a distinct legal and/or regulatory framework, which is a source of external constraints on Persons, their behaviour and the making of commitments among Persons including any aspect of a business transaction

NOTE 1 The pivotal jurisdictional domain is a United Nations (UN) recognized member state. From a legal and sovereignty perspective they are considered "peer" entities. Each UN member state, (a.k.a. country) may have sub-administrative divisions as recognized jurisdictional domains, (e.g., provinces, territories, cantons, länder, etc.), as decided by that UN member state.

NOTE 2 Jurisdictional domains can combine to form new jurisdictional domains, (e.g., through bilateral, multilateral and/or international treaties).

EXAMPLE Included here, for example, are the European Union (EU), NAFTA, WTO, WCO, ICAO, WHO, Red Cross, the ISO, the IEC, the ITU, etc.

NOTE 3 Several levels and categories of jurisdictional domains may exist within a jurisdictional domain.

NOTE 4 A jurisdictional domain may impact aspects of the commitment(s) made as part of a business transaction including those pertaining to the making, selling, and transfer of goods, services and/or rights (and resulting liabilities) and associated information. This is independent of whether such interchange of commitments is conducted on a for-profit or not-for-profit basis and/or includes monetary values.

NOTE 5 Laws, regulations, directives, etc., issued by a jurisdictional domain are considered as parts of that jurisdictional domain and are the primary sources of external constraints on business transactions.

[ISO/IEC 15944-5:2014, 3.67]


193

16151616161716181619

1620

16211622162316241625

16261627

1628

16291630

1631

1632

1633

1634

16351636163716381639

1640164116421643

16441645

16461647

1648

1649165016511652

16531654

1655

CD ISO/IEC 15944-12:2014(E)

3.74jurisdictional domain identifierID code of a jurisdictional domain as recognized for use by peer jurisdictional domains within a system of mutual recognition

[ISO/IEC 15944-2:2014, 3.47]

3.75languagesystem of signs for communication, usually consisting of a vocabulary and rules

NOTE In this standard, language refers to natural languages or special languages, but not "programming languages" or "artificial languages".

[ISO 5127-1:2001, 1.1.2.01]

3.76language codecombination of characters used to represent a language or languages

NOTE 1 In this standard, the ISO 639-2/T (Terminology) three-alpha code set, shall be used.

NOTE 2 Adapted from ISO 639-2:1998, 3.2.

[ISO/IEC 15944-5:2014, 3.70]

3.77legally recognized language (LRL)natural language which has status (other than an official language or de facto language) in a jurisdictional domain as stated in an act, regulation, or other legal instrument, which grants a community of people (or its individuals) the right to use that natural language in the context stipulated by the legal instrument(s)

NOTE The LRL can be specified through either: (a) the identification of a language by the name used; or, (b) the identification of a people and thus their language(s).

EXAMPLE In addition to acts and regulations, legal instruments include self-government agreements, land claim settlements, court decisions, jurisprudence, etc.

[ISO/IEC 15944-5:2014, 3.71]

3.78legally recognized name (LRN)persona associated with a role of a Person recognized as having legal status and so recognized in a jurisdictional domain as accepted or assigned in compliance with the rules applicable of that jurisdictional domain, i.e. as governing the coded domain of which the LRN is a member

NOTE 1 A LRN may be of a general nature and thus be available for general use in commitment exchange or may arise from the application of a particular law, regulation, program or service of a jurisdictional domain and thus will have a specified use in commitment exchange.

NOTE 2 The process of the establishment of a LRN is usually accompanied by the assignment of a unique identifier.

NOTE 3 A LRN is usually a registry entry in a register established by the jurisdictional domain (usually by a specified public administration within that jurisdictional domain) for the purpose of applying the applicable rules and registering and recording LRNs (and possible accompanying unique identifiers accordingly).

NOTE 4 A Person may have more than one LRN (and associated LRN identifier).

[ISO/IEC 15944-5:2014, 3.72]


195

1656165716581659

1660

166116621663

16641665

1666

166716681669

1670

1671

1672

167316741675167616771678

16791680

16811682

1683

16841685168616871688

168916901691

1692

169316941695

1696

1697

CD ISO/IEC 15944-12:2014(E)

3.79listordered set of data elements

[ISO/IEC 2382-4:1999, 04.08.01]

3.80localizationpertaining to or concerned with anything that is not global and is bound through specified sets of constraints of: (a) a linguistic nature including natural and special languages and associated multilingual requirements; (b) jurisdictional nature, i.e., legal, regulatory, geopolitical, etc.; (c) a sectoral nature, i.e., industry sector, scientific, professional, etc.; (d) a human rights nature, i.e., privacy, disabled/handicapped persons, etc.; (e) consumer behaviour requirements; and/or, (f) safety or health requirements

NOTE Within and among "locales", interoperability and harmonization objectives also apply.

[ISO/IEC 15944-5:2014, 3.75]

3.81locationplace, either physical or electronic, that can be defined as an address

[ISO/IEC 15944-2:2014, 3.50]

3.82mediumphysical material which serves as a functional unit, in or on which information or data is normally recorded, in which information or data can be retained and carried, from which information or data can be retrieved, and which is non-volatile in nature

NOTE 1 This definition is independent of the material nature on which the information is recorded and/or technology used to record the information, (e.g., paper, photographic, (chemical), magnetic, optical, ICs (integrated circuits), as well as other categories no longer in common use such as vellum, parchment (and other animal skins), plastics, (e.g., bakelite or vinyl), textiles, (e.g., linen, canvas), metals, etc.).

NOTE 2 The inclusion of the "non-volatile in nature" attribute is to cover latency and records retention requirements.

NOTE 3 This definition of "medium" is independent of: (a) the form or format of recorded information; (b) the physical dimension and/or size; and, (c) any container or housing that is physically separate from material being housed and without which the medium can remain a functional unit.

NOTE 4 This definition of "medium" also captures and integrates the following key properties: (a) the property of medium as a material in or on which information or data can be recorded and retrieved; (b) the property of storage; (c) the property of physical carrier; (d) the property of physical manifestation, i.e., material; (e) the property of a functional unit; and, (f) the property of (some degree of) stability of the material in or on which the information or data is recorded.

[ISO/IEC 15944-1:2011, 3.34]

3.83modelabstraction of some aspect of reality

[ISO 19115:2003, 4.9]

3.84multilingualismability to support not only character sets specific to a (natural) language (or family of languages) and associated rules but also localization requirements, i.e., use of a language from jurisdictional domain, sectoral and/or consumer marketplace perspectives

[ISO/IEC 15944-5:2014, 3.82]


197

169816991700

1701

1702170317041705170617071708

1709

1710

171117121713

1714

17151716171717181719

1720172117221723

1724

172517261727

1728172917301731

1732

173317341735

1736

17371738173917401741

1742

CD ISO/IEC 15944-12:2014(E)

3.85mutually defined - recognized individual identity (md-rii)recognized individual identity (rii) which is mutually defined and agreed to for use between the seller and the individual, as buyer, in a business transaction

NOTE 1 The establishment of a mutually agreed to and recognized individual between a seller and individual, as buyer, does not extinguish the applicable privacy protection rights of that individual.

NOTE 2 A mutually defined recognized individual identity (md-rii) shall be established between the seller and the individual no later than the end of the negotiation phase.

NOTE 3 Use of a mutually defined recognized individual identity (md-rii) may not be permitted where external constraints apply.

[ISO/IEC 15944-8:2012, 3.80]

3.86namedesignation of an object by a linguistic expression

[ISO/IEC 11179-3:2003, 3.2.26]

3.87natural languagelanguage which is or was in active use in a community of people, and the rules of which are mainly deduced from the usage

[ISO 5217:2000, 1.1.2.02]

3.88objectanything perceivable or conceivable

NOTE Objects may be material (e.g. engine, a sheet of paper, a diamond), or immaterial (e.g. conversion ratio, a project play) or imagined, (e.g., a unicorn).

[ISO 1087-1:2000, 3.1.1]

3.89object classset of ideas, abstractions, or things in the real world that can be identified with explicit boundaries and meaning and whose properties and behaviour follow the same rules

[ISO/IEC 11179-1:2004, 3.3.22]

3.90official languageexternal constraint in the form of a natural language specified by a jurisdictional domain for official use by Persons forming part of and/or subject to that jurisdictional domain for use in communication(s) either: (a) within that jurisdictional domain; and/or, (b) among such Persons, where such communications are recorded information involving commitment(s)

NOTE 1 Unless official language requirements state otherwise, Persons are free to choose their mutually acceptable natural language and/or special language for communications as well as exchange of commitments.

NOTE 2 A jurisdictional domain decides whether or not it has an official language. If not, it will have a de facto language.

NOTE 3 An official language(s) can be mandated for formal communications as well as provision of goods and services to Persons subject to that jurisdictional domain and for use in the legal and other conflict resolution system(s) of that jurisdictional domain, etc.


199

1743174417451746

17471748

17491750

17511752

1753

175417551756

1757

1758175917601761

1762

176317641765

17661767

1768

1769177017711772

1773

177417751776177717781779

17801781

17821783

178417851786

CD ISO/IEC 15944-12:2014(E)

NOTE 4 Where applicable, use of an official language may be required in the exercise of rights and obligations of individuals in that jurisdictional domain.

NOTE 5 Where an official language of a jurisdictional domain has a controlled vocabulary of the nature of a terminology, it may well have the characteristics of a special language. In such cases, the terminology to be used must be specified.

NOTE 6 For an official language, the writing system(s) to be used shall be specified, where the spoken use of a natural language has more than one writing system.

EXAMPLE 1 The spoken language of use of an official language may at times have more than one writing system. For example, three writing systems exist for the Inuktitut language. Canada uses two of these writing systems, namely, a Latin-1 based (Roman), the other is syllabic-based. The third is used in Russia and is Cyrillic based.

EXAMPLE 2 Norway has two official writing systems, both Latin-1 based, namely, Bokmål (Dano-Norwegian) and Nynorsk (New Norwegian).

NOTE 7 A jurisdictional domain may have more than one official language but these may or may not have equal status.

EXAMPLE Canada has two official languages, Switzerland has three, while the Union of South Africa has eleven official languages.

NOTE 8 The BOV requirement of the use of a specified language will place that requirement on any FSV supporting service.

EXAMPLE A BOV requirement of Arabic, Chinese, Russian, Japanese, Korean, etc., as an official language requires the FSV support service to be able to handle the associated character sets.

[ISO/IEC 15944-5:2014, 3.87]

3.91Open-edielectronic data interchange among multiple autonomous Persons to accomplish an explicit shared business goal according to Open-edi standards

[ISO/IEC 14662:2010, 3.14]

3.92Open-edi Description Technique (OeDT)specification method such as a Formal Description Technique, another methodology having the characteristics of a Formal Description Technique, or a combination of such techniques as needed to formally specify BOV concepts, in a computer processable form

[ISO/IEC 14662:2010, 3.16]

3.93Open-edi dispositionprocess governing the implementation of formally approved records retention, destruction (or expungement) or transfer of recorded information under the control of a Person which are documented in a records scheduling and disposition authority (ies) or similar instrument of the organization

NOTE Adapted from ISO 15489-1, 3.9.

[ISO/IEC 15944-5:2014, 3.90]

3.94Open-edi Party (OeP)Person that participates in Open-edi

NOTE Often referred to generically in this and other eBusiness standards, (e.g., parts of ISO/IEC 15944 multipart “eBusiness standard) as "party" or "parties" for any entity modelled as a Person as playing a role in Open-edi scenarios.

[ISO/IEC 14662:2010, 3.17]


201

17871788

178917901791

17921793

179417951796

17971798

1799

18001801

18021803

18041805

1806

1807180818091810

1811

18121813181418151816

1817

18181819182018211822

1823

1824

182518261827

18281829

1830

CD ISO/IEC 15944-12:2014(E)

3.95Open-edi record retention and disposal schedule (Oe-RRDS)specification of a period of time that a set of recorded information (SRI) shall be retained by a Person in order to meet operational, legal, regulatory, fiscal or other requirements as specified in the external constraints (or internal constraints) applicable to a Person who is a party to a business transaction

[ISO/IEC 15944-5:2014, 3.92]

3.96Open-edi systeminformation technology system (IT System) which enables an Open-edi Party to participate in Open-edi transactions

[ISO/IEC 14662:2010, 3.22]

3.97organizationunique framework of authority within which a person or persons act, or are designated to act, towards some purpose

NOTE The kinds of organizations covered by this International Standard include the following examples:

EXAMPLE 1 An organization incorporated under law.

EXAMPLE 2 An unincorporated organization or activity providing goods and/or services including: (a) partnerships; (b) social or other non-profit organizations or similar bodies in which ownership or control is vested in a group of individuals; (c) sole proprietorships; and, (d) governmental bodies.

EXAMPLE 3 Groupings of the above types of organizations where there is a need to identify these in information interchange.

[ISO/IEC 6523-1: 1998, 3.1]

3.98organization partany department, service or other entity within an organization, which needs to be identified for information interchange

[ISO/IEC 6523-1:1998, 3.2]

3.99organization Personorganization part which has the properties of a Person and thus is able to make commitments on behalf of that organization

NOTE 1 An organization can have one or more organization Persons.

NOTE 2 An organization Person is deemed to represent and act on behalf of the organization and to do so in a specified capacity.

NOTE 3 An organization Person can be a "natural person" such as an employee or officer of the organization.

NOTE 4 An organization Person can be a legal person, i.e., another organization.

[ISO/IEC 15944-1:2011, 3.46]

3.100Personentity, i.e., a natural or legal person, recognized by law as having legal rights and duties, able to make commitment(s), assume and fulfil resulting obligation(s), and able of being held accountable for its action(s)


203

18311832183318341835

1836

1837183818391840

1841

1842184318441845

1846

1847

184818491850

18511852

1853

1854185518561857

1858

1859186018611862

1863

18641865

1866

1867

1868

1869187018711872

CD ISO/IEC 15944-12:2014(E)

NOTE 1 Synonyms for "legal person" include "artificial person", "body corporate", etc., depending on the terminology used in competent jurisdictions.

NOTE 2 Person is capitalized to indicate that it is being used as formally defined in the standards and to differentiate it from its day-to-day use.

NOTE 3 Minimum and common external constraints applicable to a business transaction often require one to differentiate among three common subtypes of Person, namely "individual", "organization", and "public administration".

[ISO/IEC 14662:2010, 3.24]

3.101Person authenticationprovision of the assurance of a recognized Person identity (rPi) (sufficient for the purpose of the business transaction) by corroboration

[ISO/IEC 15944-1:2011, 3.48]

3.102personaset of data elements and their values by which a Person wishes to be known and thus identified in a business transaction

[ISO/IEC 15944-1:2011, 3.51]

3.103persona Registration Schema (pRS)formal definition of the data fields contained in the specification of a persona of a Person and the allowable contents of those fields, including the rules for the assignment of identifiers

NOTE This may also be referred to as a persona profile of a Person.

[ISO/IEC 15944-1:2011, 3.52]

3.104personal informationany information on or about an identifiable individual that is recorded in any form, including electronically or on paper

NOTE Recorded information about a person's religion, age, financial transactions, medical history, address, or blood type.

[ISO/IEC 15944-5:2014, 3.103]

3.105Person identity (Pi)combination of persona information and identifier used by a Person in a business transaction

[ISO/IEC 15944-1:2011, 3.49]

3.106Person signaturesignature, i.e., a name representation, distinguishing mark or usual mark, which is created by and pertains to a Person

[ISO/IEC 15944-1:2011, 3.50]


205

18731874

18751876

18771878

1879

1880188118821883

1884

1885188618871888

1889

1890189118921893

1894

1895

1896189718981899

19001901

1902

190319041905

1906

1907190819091910

1911

CD ISO/IEC 15944-12:2014(E)

3.107personal information filing systemany structured set of personal information which is accessible according to specific criteria, whether centralized, decentralized or dispersed on a functional or geographical basis

[ISO/IEC 15944-8:2012,, 3.103]

3.108physical addressaddress that is used/recognized by a postal authority and/or courier service to deliver information item(s), material object(s), or business object(s) to a Contact at either an actual address or a pick-up point address, (e.g., P.O. Box, rural route, etc.)

[ISO/IEC 15944-2:2014, 3.80]

3.109pivot code setset of ID codes in a coded domain which is made publicly known and available, the most stable, representing the defined semantics (most often it is the same as the ID code)

NOTE 1 The use of the pivot code set as distinguished from the ID code supports the requirement of a Source Authority to maintain internally and on a confidential basis the ID code of its members.

NOTE 2 At times a coded domain has more than one valid code set, (e.g., ISO 639, ISO 3166, etc.).

EXAMPLE In ISO 3166-1 the 3-digit numeric code set is the pivot. The 2-alpha and 3-alpha code sets can change when the name of the entity referenced is changed by that entity.

[ISO/IEC 15944-5:20014, 3.104]

3.110pivot ID codemost stable ID code assigned to identify a member of a coded domain where more than one ID code may be assigned and/or associated with a member of that coded domain

EXAMPLE ISO 3166-1:2006 contains three code sets: (a) a three-digit numeric code; (b) a two-alpha code; and, (c) a three-alpha code. The three-digit numeric code set serves as the pivot ID code. It is the most stable, remains the same even though the two alpha and/or three alpha codes may and do change.

[ISO/IEC 15944-5:2014, 3.105]

3.111principlefundamental, primary assumption and quality which constitutes a source of action determining particular objectives or results

NOTE 1 A principle is usually enforced by rules that affect its boundaries.

NOTE 2 A principle is usually supported through one or more rules.

NOTE 3 A principle is usually part of a set of principles which together form a unified whole.

EXAMPLE Within a jurisdictional domain, examples of a set of principles include a charter, a constitution, etc.

[ISO/IEC 15944-2:2014, 3.81]

3.112privacy collaboration space (PCS)modelling or inclusion of an Open-edi scenario of a collaboration space involving an individual as the buyer in a potential or actualized business transaction where the buyer is an individual and therefore


207

1912191319141915

1916

19171918191919201921

1922

1923192419251926

19271928

1929

19301931

1932

1933193419351936

193719381939

1940

1941194219431944

1945

1946

1947

1948

1949

1950195119521953

CD ISO/IEC 15944-12:2014(E)

privacy protection requirements apply to personal information of that individual provided in that business transaction

[ISO/IEC 15944-8:2012, 3.107]

3.113privacy protectionset of external constraints of a jurisdictional domain pertaining to recorded information on or about an identifiable individual, i.e., personal information, with respect to the creation, collection, management, retention, access and use and/or distribution of such recorded information about that individual including its accuracy, timeliness, and relevancy

NOTE 1 Recorded information collected or created for a specific purpose on an identifiable individual, i.e., the explicitly shared goal of the business transaction involving an individual, shall not be used for another purpose without the explicit and informed consent of the individual to whom the recorded information pertains.

NOTE 2 Privacy requirements include the right of an individual to be able to view the recorded information about him/her and to request corrections to the same in order to ensure that such recorded information is accurate and up-to-date, or have it deleted.

NOTE 3 Where jurisdictional domains have legal requirements which override privacy protection requirements these must be specified, (e.g., national security, investigations by law enforcement agencies, etc.).

[ISO/IEC 15944-5:2014, 3.109]

3.114privacy protection officer (PPO)organization Person authorized by the organization to act on behalf of that organization and entrusted by the organization as the officer responsible for the overall governance and implementation of the privacy protection requirements for information life cycle management not only within that organization but also with respect to any electronic data interchange of personal information on the individual concerned with parties to the business transaction, including a regulator where required, as well as any agents, third parties involved in that business transaction

[ISO/IEC 15944-8:2012, 3.105]

3.115processseries of actions or events taking place in a defined manner leading to the accomplishment of an expected result

[ISO/IEC 15944-1:2011, 3.53]

3.116processing of personal informationany operation or set of operations which is performed upon personal data, whether or not by automatic means, such as collection, recording, organization, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction

[ISO/IEC 15944-8:2012, 3.111]

3.117propertypeculiarity common to all members of an object class

[ISO/IEC 11179-1:2004, 3.3.29]


209

19541955

1956

195719581959196019611962

196319641965

196619671968

19691970

1971

19721973197419751976197719781979

1980

1981198219831984

1985

198619871988198919901991

1992

199319941995

1996

CD ISO/IEC 15944-12:2014(E)

3.118pseudonymuse of a persona or other identifier by an individual which is different from that used by the individual with the intention that it be not linkable to that individual

NOTE Adapted from ISO TS 25237.

[ISO/IEC 15944-8:2012, 3.113]

3.119pseudonymizationparticular type of anonymization that removes the association with an individual and adds an association between a particular set of characteristics relating to the individual and one more pseudonym

NOTE Adapted from ISO TS 25237.

[ISO/IEC 15944-8:2012, 3.114]

3.120public administrationentity, i.e., a Person, which is an organization and has the added attribute of being authorized to act on behalf of a regulator

[ISO/IEC 15944-1:2011, 3.54]

3.121public policycategory of external constraints of a jurisdictional domain specified in the form of a right of an individual or a requirement of an organization and/or public administration with respect to an individual pertaining to any exchange of commitments among the parties concerned involving a good, service and/or right including information management and interchange requirements

NOTE 1 Public policy requirements may apply to any one, all or combinations of the fundamental activities comprising a business transaction, i.e., planning, identification, negotiation, actualization and post-actualization. (See further Clause 6.3 "Rules governing the process component" in ISO/IEC 15944-1:2011)

NOTE 2 It is up to each jurisdictional domain to determine whether or not the age of an individual qualifies a public policy requirement, (e.g., those which specifically apply to an individual under the age of thirteen as a "child"), those which require an individual to have attained the age of adulthood, (e.g., 18 years or 21 years of age) of an individual to be able to make commitments of a certain nature.

NOTE 3 Jurisdictional domains may have consumer protection or privacy requirements which apply specifically to individuals who are considered to be "children", "minors", etc. (e.g. those who have not reached their 18th or 21st birthday according to the rules of the applicable jurisdictional domain).

[ISO/IEC 15944-5:2014, 3.113]

3.122publicly available personal information (PAPI)personal information about an individual that the individual knowingly makes or permits to be made available to the public, or is legally obtained and accessed from: (1) government records that are available to the public; or, (2) information required by law to be made available to the public

EXAMPE 1 Personal information which an individual knowingly makes or permits to be made available include public telephone directories, advertisements in newspapers, published materials, postings of this nature on the internet, etc.

EXAMPLE 2 Government records that are publicly available include registers of individuals who are entitled to vote, buy or sell a property, or any other personal information that a jurisdictional domain requires to be publicly available, etc.

[ISO/IEC 15944-8:2012, 3.117]


211

1997199819992000

2001

2002

2003200420052006

2007

2008

2009201020112012

2013

201420152016201720182019

202020212022

2023202420252026

202720282029

2030

20312032203320342035

20362037

20382039

2040

CD ISO/IEC 15944-12:2014(E)

3.123recognized individual identity (rii)identity of an individual, i.e., individual identity, established to the extent necessary for the specific purpose of a business transaction

[ISO/IEC 15944-8:2012, 3.116]

3.124recognized individual name (RIN)persona of an individual having the properties of a legally recognized name (LRN)

NOTE 1 On the whole, a persona presented by an individual should have a basis in law (or recognized jurisdictional domain) in order to be considered as the basis for a recognized individual name (RIN).

NOTE 2 An individual may have more than one RIN and more than one RIN at the same time.

NOTE 3 The establishment of a RIN is usually accompanied by the assignment of a unique identifier, i.e. by the jurisdictional domain (or public administration) which recognizes the persona as a RIN.

[ISO/IEC 15944-5:2014, 3.114]

3.125recognized Person identity (rPi)identity of a Person, i.e., Person identity, established to the extent necessary for a specific purpose in a business transaction

[ISO/IEC 15944-1:2011, 3.55]

3.126recorded informationinformation that is recorded on or in a medium irrespective of form, recording medium or technology used, and in a manner allowing for storage and retrieval

NOTE 1 This is a generic definition and is independent of any ontology, (e.g., those of "facts" versus "data" versus "information" versus "intelligence" versus "knowledge", etc.).

NOTE 2 Through the use of the term "information," all attributes of this term are inherited in this definition.

NOTE 3 This definition covers: (a) any form of recorded information, means of recording, and any medium on which information can be recorded; and, (b) all types of recorded information including all data types, instructions or software, databases, etc.

[ISO/IEC 15944-1:2011, 3.56]

3.127registerset of files containing identifiers assigned to items with descriptions of the associated items

[ISO 19135:2005, 4.1.9]

3.128registrationrule-based process, explicitly stated, involving the use of one or more data elements, whose value (or combination of values) is used to identify uniquely the results of assigning an OeRI

[ISO/IEC 15944-2:2014, 3.95]

3.129Registration Authority (RA)Person responsible for the maintenance of one or more Registration Schemas (RS) including the assignment of a unique identifier for each recognized entity in a Registration Schema (RS)


213

2041204220432044

2045

204620472048

20492050

2051

20522053

2054

2055205620572058

2059

2060206120622063

20642065

2066

206720682069

2070

207120722073

2074

2075207620772078

2079

2080208120822083

CD ISO/IEC 15944-12:2014(E)

[ISO/IEC 15944-1:2011, 3.57]

3.130Registration Authority Identifier (RAI)identifier assigned to a Registration Authority (RA)

[ISO/IEC 11179-1:2004, 3.3.32]

3.131Registration Schema (RS)formal definition of a set of rules governing the data fields for the description of an entity and the allowable contents of those fields, including the rules for the assignment of identifiers

[ISO/IEC 15944-1:2011, 3.58]

3.132Registration Schema (based) –recognized individual identity (RS-rii)recognized individual identity (rii) for use in a business transaction, by the buyer as an individual, which is one based on the use by an individual as a member of a specified Registration Schema (RS) of a particular Registration Authority (RA)

[ISO/IEC 15944-8:2012, 3.127]

3.133registryinformation system on which a register is maintained

[ISO19135:2005, 4.1.13]

3.134regulatorPerson who has authority to prescribe external constraints which serve as principles, policies or rules governing or prescribing the behaviour of Persons involved in a business transaction as well as the provisioning of goods, services, and/or rights interchanged

[ISO/IEC 15944-1:2011, 3.59]

3.135regulatory business transaction (RBT)class of business transactions for which the explicitly shared goal has been established and specified by a jurisdictional domain, as a Person in the role of a regulator

NOTE 1 A regulatory business transaction (RBT) can itself be modelled as a stand-alone business transaction and associated scenario(s).

EXAMPLE The filing of a tax return, the making of a customs declaration, the request for and issuance of a license, the provision of a specified service of a public administration, a mandatory filing of any kind with a regulator, etc.

NOTE 2 A regulatory business transaction (modelled as a scenario) can form part of another business transaction.

NOTE 3 A RBT may apply to a seller only, a buyer only or both, as well as any combination of parties to a business transaction.

NOTE 4 A RBT may require or prohibit the use of an agent or third party.

NOTE 5 A regulatory business transaction (RBT) may be specific to the nature of the good, services and/or right forming part of a business transaction.

[ISO/IEC 15944-5:2014, 3.124]


215

2084

208520862087

2088

2089209020912092

2093

20942095209620972098

2099

210021012102

2103

21042105210621072108

2109

2110211121122113

21142115

21162117

2118

21192120

2121

21222123

2124

CD ISO/IEC 15944-12:2014(E)

3.136retention periodlength of time for which data on a data medium is to be preserved

[ISO/IEC 2382-12:1988, 12.04.11]

3.137rolespecification which models an external intended behaviour (as allowed within a scenario) of an Open-edi Party

[ISO/IEC 14662:2010, 3.25]

3.138rulestatement governing conduct, procedure, conditions and relations.

NOTE 1 Rules specify conditions that must be complied with. These may include relations among objects and their attributes.

NOTE 2 Rules are of a mandatory or conditional nature.

NOTE 3 In Open-edi, rules formally specify the commitment(s) and role(s) of the parties involved, and the expected behaviour(s) of the parties involved as seen by other parties involved in (electronic) business transactions. Such rules are applied to: (a) content of the information flows in the form of precise and computer-processable meaning, i.e. the semantics of data; and, (b) the order and behaviour of the information flows themselves.

NOTE 4 Rules must be clear and explicit enough to be understood by all parties to a business transaction. Rules also must be capable of being able to be specified using a using a Formal Description Technique(s) (FDTs).

EXAMPLE A current and widely used FDT is "Unified Modelling Language (UML)".

NOTE 5 Specification of rules in an Open-edi business transaction should be compliant with the requirements of ISO/IEC 15944-3 "Open-edi Description Techniques (OeDT)".

[ISO/IEC 15944-2:2014, 3.101]

3.139rulebasepre-established set of rules which interwork and which together form an autonomous whole

NOTE One considers a rulebase to be to rules as database is to data.

[ISO/IEC 15944-2:2014, 3.102]

3.140SC identifierunique, linguistically neutral, unambiguous, referenceable identifier of a Semantic Component

[ISO/IEC 15944-2:2014, 3.107]

3.141scenario attributeformal specification of information, relevant to an Open-edi scenario as a whole, which is neither specific to roles nor to Information Bundles

[ISO/IEC 14662:2010, 3.26]


217

212521262127

2128

2129213021312132

2133

213421352136

21372138

2139

2140214121422143

21442145

2146

21472148

2149

215021512152

2153

2154

215521562157

2158

2159216021612162

2163

CD ISO/IEC 15944-12:2014(E)

3.142scenario componentone of the three fundamental elements of a scenario, namely role, Information Bundle, and Semantic Component

[ISO/IEC 15944-2:2014, 3.104]

3.143scenario contentset of recorded information containing registry entry identifiers, labels and their associated definitions and related recorded information posted (or reposted) in any registry for business objects

[ISO/IEC 15944-2:2014, 3.105]

3.144scenario specification attributeany attribute of a scenario, role, Information Bundle, and/or Semantic Component

[ISO/IEC 15944-2 2014, 3.106]

3.145sellerPerson who aims to hand over voluntarily or in response to a demand, a good, service and/or right to another Person and in return receives an acceptable equivalent value, usually in money, for the good, service and/or right provided

[ISO/IEC 15944-1:2011, 3.62]

3.146Semantic Component (SC)unit of recorded information unambiguously defined in the context of the business goal of the business transaction

NOTE A SC may be atomic or composed of other SCs.

[ISO/IEC 14662:2010, 3.27]

3.147semantic identifier (SI)IT-interface identifier for a semantic component or other semantic for which (1) the associated context, applicable rules and/or possible uses as a semantic are predefined and structured and the Source Authority for the applicable rulebase is identified and (2) for which more than one or more Human Interface Equivalents(HIEs) exist

NOTE The identifier for a Semantic Component (SC), an Information Bundle (IB) and/or an ID code for which one or more human interface equivalents (HIEs) exist are considered to have the properties or behaviours of semantic identifiers.

[ISO/IEC 15944-5:2014, 3.136]

3.148set of personal information (SPI)set of recorded information (SRI) which is of the nature of or contains personal information

3.149set of recorded information (SRI)recorded information of an organization or public administration, which is under the control of the same and which is treated as a unit in its information life cycle

NOTE 1 A SRI can be a physical or digital document, a record, a file, etc., that can be read, perceived or heard by a person or computer system or similar device.


219

2164216521662167

2168

2169217021712172

2173

217421752176

2177

21782179218021812182

2183

2184218521862187

2188

2189

219021912192219321942195

21962197

2198

21992200220122022203220422052206

22072208

CD ISO/IEC 15944-12:2014(E)

NOTE 2 A SRI is a unit of recorded information that is unambiguously defined in the context of the business goals of the organization, i.e., a semantic component.

NOTE 3 A SRI can be self-standing (atomic), or a SRI can consist of a bundling of two or more SRIs into another “new” SRI. Both types can exist simultaneously within the information management systems of an organization.

[ISO/IEC 15944-5:2014, 3.137]

3.150Source Authority (SA)Person recognized by other Persons as the authoritative source for a set of constraints

NOTE 1 A Person as a Source Authority for internal constraints may be an individual, organization, or public administration.

NOTE 2 A Person as Source Authority for external constraints may be an organization or public administration.

EXAMPLE In the field of air travel and transportation, IATA as a Source Authority, is an "organization," while ICAO as a Source Authority, is a "public administration".

NOTE 3 A Person as an individual shall not be a Source Authority for external constraints.

NOTE 4 Source Authorities are often the issuing authority for identifiers (or composite identifiers) for use in business transactions.

NOTE 5 A Source Authority can undertake the role of Registration Authority or have this role undertaken on its behalf by another Person.

NOTE 6 Where the sets of constraints of a Source Authority control a coded domain, the SA have the role of a coded domain Source Authority.

[ISO/IEC 15944-2:2014, 3.109]

3.151special languagelanguage for special purposes (LSP), language used in a subject field and characterized by the use of specific linguistic means of expression

NOTE The specific linguistic means of expression always include subject-specific terminology and phraseology and also may cover stylistic or syntactic features.

[ISO 1087-1:2000, 3.1.3]

3.152SRI destructionprocess of eliminating or deleting sets of recorded information, beyond any possible reconstruction

3.153SRI expungementprocess of eliminating completely, wiping out, destroying or obliterating completely a physical or (electronic) digital set of recorded information (SRI) without so that there can be no reconstruction

3.153SRI integrity(of records) reliability and trustworthiness of SRIs as copies, duplicates or comparable representations of SRIs; and reliability and trustworthiness of the IT system in which it was recorded or stored to produce reliable and trustworthy copies and duplicates of SRIs

NOTE 1 SRI integrity is important in the electronic records provisions of the evidence acts in the phrases “the integrity of the electronic records system” and “the integrity of the electronic record.” However, the term integrity is not defined. In the


221

22092210

22112212

2213

221422152216

22172218

2219

22202221

2222

22232224

22252226

22272228

2229

2230223122322233

22342235

2236

223722382239

22402241224222432244224522462247224822492250

22512252

CD ISO/IEC 15944-12:2014(E)

absence of a statutory or judicially created definition, the principles of this standard shall serve as an operational definition of the word integrity used in the evidence acts.

NOTE 2 Certain evidence acts provide that the integrity of the electronic record may be proved by evidence of reliable encryption.

3.155SRI life cyclestages in the life cycle of a SRI include but are not limited to its planning, creation and organization; the receipt and capture of data; the retrieval, processing, dissemination and distribution of a SRI; its storage, maintenance and protection; its archival preservation or destruction or expungement

3.156SRI migrationact of moving a SRI from one IT system to another Person within an organization or public administration while maintaining the authenticity, integrity, reliability and usability of the SRI

3.157SRI retention periodspecified period of time that SRIs are kept by a Person in order to meet operational, legal, regulatory, fiscal or other requirements

3.158standarddocumented agreement containing technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose

NOTE This is the generic definition of “standard” of the ISO and IEC (and now found in the ISO/IEC JTC1 Directives, Part 1, Section 2.5:1998). (See also ISO/IEC Guide 2:1996 (1.7)

[ISO/IEC 15944-1:2011, 3.64]

3.159termdesignation of a defined concept in a special language by a linguistic expression

NOTE A term may consist of one or more words i.e. simple term, or complex term or even contain symbols.

[ISO 1087-1:2000, 3.4.3]

3.160textdata in the form of characters, symbols, words, phrases, paragraphs, sentences, tables, or other character arrangements, intended to convey a meaning and whose interpretation is essentially based upon the reader's knowledge of some natural language or artificial language

EXAMPLE A business letter printed on paper or displayed on a screen.

[ISO/IEC 2382-23:1994, 23.01.01]

3.161third partyPerson besides the two primarily concerned in a business transaction who is agent of neither and who fulfils a specified role or function as mutually agreed to by the two primary Persons or as a result of external constraints

NOTE It is understood that more than two Persons can at times be primary parties in a business transaction.

[ISO/IEC 15944-1:2011, 3.65]


223

22532254

22552256

22572258225922602261

226222632264226522662267226822692270

22712272227322742275

22762277

2278

227922802281

2282

2283

22842285228622872288

2289

2290

22912292229322942295

2296

2297

CD ISO/IEC 15944-12:2014(E)

3.162transitory recordSRI that is required only for a very limited and specified (retention period) time to ensure the completion of a routine action or the preparation of a subsequent SRI

NOTE A transitory SRI is expunged at the end of a short existence.

3.163treatyinternational agreement concluded among jurisdictional domains in written form and governed by international law

NOTE 1 On the whole a treaty is concluded among UN member states.

NOTE 2 Treaties among UN member states when coming into force are required to be transmitted to the Secretariat of the United Nations for registration or filing or recording as the case may be and for publication. (See further Article 80 or the Charter of the UN)

NOTE 3 Treaties can also be entered into by jurisdictional domains other than UN member states, i.e. non-members such as international organizations and the rare sub-national units of federations which are constitutionally empowered to do so.

NOTE 4 A treaty can be embodied in a single instrument or in two or more related instruments and whatever its particular designations. However, each treaty is a single entity.

NOTE 5 Jurisdictional domains can make agreements which they do not mean to be legally binding such as for reasons of administrative convenience or expressions of political intent only, (e.g., as a Memorandum of Understanding (MOU)).

NOTE 6 Adapted from the Vienna Convention on the Law of Treaties, 1(a).

[ISO/IEC 15944-5:2014, 3.144]

3.164truncated nameshort form of a name or persona of a Person resulting from the application of a rule-based truncation process

[ISO/IEC 15944-5:2014, 3.145]

3.165truncated recognized name (TRN)truncated name, i.e., persona, of a Person which has the properties of a legally recognized name (LRN)

NOTE 1 Truncated recognized name(s) may be required for use in machine-readable travel documents, (e.g., passports or visas), identity tokens, drivers’ licenses, Medicare cards, etc.).

NOTE 2 The source of a truncated recognized name may be a legally recognized name (LRN).

[ISO/IEC 15944-5:2014, 3.146]

3.166truncationrule-base process, explicitly stated, for shortening an existing name of an entity to fit within a predefined maximum length (of characters)

NOTE Truncation may be required for the use of names in IT systems, electronic data interchange (EDI), the use of labels in packaging, in the formation of a Person identity (Pi), recognized Person identity (rPi), etc.

[ISO/IEC 15944-5:2014, 3.147]


225

229822992300230123022303

2304230523062307

2308

230923102311

231223132314

23152316

231723182319

2320

2321

2322232323242325

2326

232723282329

23302331

2332

2333

2334233523362337

23382339

2340

CD ISO/IEC 15944-12:2014(E)

3.167unambiguouslevel of certainty and explicitness required in the completeness of the semantics of the recorded information interchanged appropriate to the goal of a business transaction

[ISO/IEC 15944-1:2011, 3.66]

3.168vendorseller on whom consumer protection requirements are applied as a set of external constraints on a business transaction

NOTE 1 Consumer protection is a set of explicitly defined rights and obligations applicable as external constraints on a business transaction.

NOTE 2 It is recognized that external constraints on a seller of the nature of consumer protection may be peculiar to a specified jurisdictional domain.

[ISO/IEC 15944-1:2011, 3.67]

3.169vocabularyterminological dictionary which contains designations and definitions for one or more specific subject fields

NOTE The vocabulary may be monolingual, bilingual or multilingual.

[ISO 1087-1:2000, 3.7.2]


227

2341234223432344

2345

2346234723482349

23502351

23522353

2354

235523562357

2358

2359

2360

2361

2362

2363

2364

2365

2366

2367

2368

2369

2370

2371

2372

2373

2374

2375

CD ISO/IEC 15944-12:2014(E)

THIS PAGE INTENTIONALLY LEFT BLANK


229

2376

2377

2378

2379

2380

2381

2382

2383

2384

2385

2386

2387

CD ISO/IEC 15944-12:2014(E)

4 Symbols and abbreviations


1. The entries in Clause 4 will be reviewed and amended in the preparation of the next ballo0t version of this document.

2. In order to facilitate the referencing of the various Parts of ISO/IEC 15944, as well as there Clauses or sub-clauses, each of the Parts has been is represented by its acronym, i.e., as Part 1, Part 2, etc. {See further below}

For the purposes of this document, the following symbols and abbreviations apply.

Acronym Description

API Application Programming Interface

ATI Access to Information

BOV Business Operational View

BTI Business Transaction Identifier

BTM Business Transaction Model

cdRS coded domain Registration Schema

cdSA coded domain Source Authority

CV controlled vocabulary

DMA Decision Making Application

DMA Interface Decision Making Application Interface

EC European Community

EDI Electronic Data Interchange

EU European Union

FDT Formal Description Technique

FOI Freedom of Information

FSV Functional Service View

HIE Human Interface Equivalent

IB Information Bundle

ILCM Information life cycle management

IEC International Electrotechnical Commission

ii individual identity

IPD Information Processing Domain

ipRS individual persona Registration Schema


231

2388

2389

23902391

239223932394

2395

2396

2397

2398

2399

2400

2401

2402

2403

2404

2405

2406

2407

2408

2409

2410

2411

2412

2413

2414

2415

2416

2417

2418

2419

CD ISO/IEC 15944-12:2014(E)

ISO International Organization for Standardization

IT System Information Technology System

ITU International Telecommunications Union

ITU-R International Telecommunications Union – Radiocommunications Sector

ITU-T International Telecommunications Union – Telecommunications Sector

JTC1 Joint Technical Committee 1 “Information Technology” (of the ISO and IEC)

LRL legally recognized language

LRN legally recognized name (NRL nom reconnu legalement)

md-rii mutually defined – recognized individual identity

OeBTO Open-edi Business Transaction Ontology

OeDT Open-edi Descriptive Techniques

OeORI Open-edi Registration Organization Identifier

OeP Open-edi Party

OeR Open-edi Registry

OeRA Open-edi Registration Authority

OeRI Open-edi Registry Item

OeRO Open-edi Registration Organization

Oe-RRDS Open-edi records retention and disposal schedule

OeS Open-edi scenario

OeSI Open-edi Support Infrastructure

PAPI publicly available personal information

Part 1 ISO/IEC 15944-1









PCS privacy collaboration space


233

2420

2421

2422

2423

2424

2425

2426

2427

2428

2429

2430

2431

2432

2433

2434

2435

2436

2437

2438

2439

2440

2441

2442

2443

2444

2445

2446

2447

2448

2449

2450

CD ISO/IEC 15944-12:2014(E)

pRS persona Registration Schema

RA Registration Authority

RAI Registration Authority Identifier

RBT Regulatory Business Transaction

rii recognized individual identity

RIN Recognized Individual Name

rPi recognized Person identity

RA Registration Authority

RS Registration Schema

RS-rii Registration Schema (based) – recognized individual identity

SA Source Authority

SC Semantic Component

SI Semantic Identifier

SRI set of recorded information

TRN truncated recognized name

UML Unified Modelling Language

UN United Nations


235

2451

2452

2453

2454

2455

2456

2457

2458

2459

2460

2461

2462

2463

2464

2465

2466

2467

CD ISO/IEC 15944-12:2014(E)

THIS PAGE INTENTIONALLY LEFT BLANK


237

2468

2469

2470

2471

2472

2473

2474

CD ISO/IEC 15944-12:2014(E)

5 Fundamental privacy protection principles

5.1 Introduction

This Clause 5 is an abridged and summarized version of the full and complete text of that found in Clause 5 of ISO/IEC 15944-8 on which it is based. The rules found in Clause 5 of Part 8 are found in Annex B.7 (normative) “Consolidated set of rules in existing Parts of ISO/IEC 15944 of particular relevance to privacy protection requirements of an ILCM nature”.. This Clause 5 has a particular focus, i.e., those pertaining to the scope and purpose of this Part 12.

Rule 001:The rules stated in Annex B (normative) of other Parts of ISO/IEC 15944, and in particular those of ISO/IEC 15944-8, are relevant and apply to this Part 12.

5.2 Primary sources of privacy protection principles

The figure presented below is a copy from Clause 5.1 Figure 3 in Part 8. It is repeated in Part 12 to provide an overview of the sources of requirements of the privacy protection principles. They also apply to this Part 12.

Figure 3 — Primary sources for privacy protection principles


Primary Sources for Privacy Protection Principles

International External Constraints

OECD GuidelinesDirective 95/46/EC of the European Parliament2005 APEC Framework

(Common) Laws & Regs. of UN member states of a Privacy Protection nature & of their admin. units, (e.g., states, provinces, länder, etc., at whatever level) (including external constraints of localization requirements nature)

Relevant added public policy requirements of jurisdictional domains, (e.g., consumer protection, individual accessibility) requirements/standards of a jurisdictional domain

Privacy & Data Commissioners

GuidelinesPublicationstoolsrulingsetc.

Relevant international ISO standards

Eleven (11) Privacy protection Principles

eBusiness & user –driven req’mts (of a BOV nature)

Clause 5ISO/IEC 15944-8

239

2475

2476

24772478247924802481

2482248324842485

2486

248724882489

2490

CD ISO/IEC 15944-12:2014(E)

5.3 Key eleven (11) privacy protection principles

Clause 5.3 “Fundamental privacy protection principles” in Part 8 provides eleven (11) principles, rules and associated text. All apply to this Part 12. The eleven (11) privacy protection principles are:

Privacy protection principle 1: Preventing harm Privacy protection principle 2: Accountability Privacy protection principle 3: Identifying purposes Privacy protection principle 4: Informed consent Privacy protection principle 5: Limiting collection Privacy protection principle 6: Limiting use, disclosure and retention Privacy protection principle 7: Accuracy Privacy protection principle 8: Safeguards Privacy protection principle 9: Openness Privacy protection principle 10: Individual access Privacy protection principle 11: Challenging compliance

These eleven (11) Privacy Protection principles are placed in a business transaction context, i.e. that of the parties making a commitment on a commonly agreed upon goal for a business transaction.

From a FSV perspective, this includes ensuring that the IT systems of an organization are able to and do provide associated required technical implementation measures which must be capable of exchanging the necessary information among the parties to a business transaction. This is necessary to be able to determine when personal information is to be processed as against all other (non-personal) recorded information forming part of the business transaction. This includes ensuring that applicable controls are in place in the Decision Making Applications (DMAs) of the IT systems of organizations (and public administrations) where personal information is processed and interchanged among all parties to a business transaction30.

Finally, the privacy protection principles enumerated above represent a whole and should be interpreted and implemented as a whole and not piecemeal. Implementers of this standards should be aware that in subsequent clauses of this part of ISO/IEC 15944, two or more of the privacy protection principles referenced may be instantiated simultaneously.

5.4 Privacy protection principles in the context of ILCM requirements

The purpose of this Clause 5.4 is to supplement from an ILCM perspective, the rules and associated text from each of the eleven privacy protection principles which are already specified in Clause 5.3 of Part 8.

5.4.1 Privacy protection principle 1: Preventing harm31

Rule 002:Any personal information which is not accurate, timely, or relevant should not be entered, or if entered, expunged immediately from the IT system of the Open-edi party, and the IT system of all the Persons with which the Open-edi party shared such personal information.

Guideline 002G1:Any personal information of the nature identified in Rule 002 should be expunged immediately or at the minimum no later than as part of the information update cycle of the relevant DMA (or IT system) of the seller (and its agents).

30 On Decision Making Applications (DMAs), Information Processing Domain (IPD) and Open-edi Support Infrastructure (OeSI) in IT systems, see further Clause 5.2 Functional Service View in ISO/IEC 14662:2010 (3rd edition) and its Figure 3 Open-edi system relationships.

31 This Clause and its rules complement those of Part 8, Clause 5.3.1 which apply here.


241

2491

24922493

24942495249624972498249925002501250225032504

25052506

25072508250925102511251225132514

2515251625172518

2519

25202521

2522

2523252425252526252725282529253025312532

242243244

245

CD ISO/IEC 15944-12:2014(E)

It is vital that Persons do not collect or retain any personal information which may harm an individual. This applies especially where such personal information is not accurate, timely, relevant which would be associated with the individual.

5.4.2 Privacy protection principle 2: Accountability 32

Rule 003:An organization should ensure that its privacy protection officer (PPO) has direct liaison with the officer(s) in that organization responsible for ILCM related aspects for any and all SRIs maintained by the organization.

It is up to each organization to decide how to assign responsibility for ILCM, i.e., among records managers, archiving, information managers, IT managers, security managers, etc. However, in order to ensure that legal and regulatory requirements applicable to personal information in an IT system of that organization are implemented, it is vital that the PPO of that organization is given the mandate on an organization-wide basis, to be able to ensure that there is a very clear and transparent organization policy and process able to ensure and support full compliance with applicable ILCM aspects of privacy protection requirements.

NOTE: A privacy protection officer (PPO) is a role of an officer in an organization. It may well be that the same organization Person is assigned responsibility for more than one role within an organization including those pertaining to corporate information law compliance, responsibility for corporate internal constraints such as information/records management, security, etc.

Rule 004:Where an organization interchanges personal information (e.g., through EDI) with one or more other organizations, i.e., as via its agent(s), and/or third pparty(ies) (e.g., , its privacy protection officer (PPO) shall ensure that the other organization in their operations and IT Systems support privacy protection requirements.

Guideline 004G1:It is recommended from a legal, risk management, and “business best practices” perspective, that an organization request its Privacy Protection Officer(PPO), to review any (prospective) EDI of the (seller) organization of any SPIs pertaining to a (prospective)business transaction with any (potential) agent and/or third party, to ensure that any such Open-edi parties have in place in their IT systems the ability to support applicable privacy protection requirements, and are willing to sign a contractual arrangement in support of the same (e.g., of the nature of the Clause 10 Coformance Statement provided below in this Part 12).

The organization acting in the role of “seller” (or “regulator) has an obligation to ensure that privacy protection requirements are applied to personal information. This applies, especially where the organization interchanges such personal information with another organization (as per informed consent of the individual for that business transaction).

5.4.3 Privacy protection principle 3: Identifying purposes 33

Each business transaction pertains to a specific and specified goal which the parties to the transaction have committed themselves.

Rule 005:In specifying the purpose, the organization collecting or creating the personal information shall also identify and specify applicable ILCM aspects and inform the individual accordingly.

It is very important that in a business transaction (or any form of commitment exchange) that where the buyer is an individual, that the individual is fully informed on any and all ILCM aspects related to the personal information created or collected as part of that business transaction.




247

253325342535

2536

2537

25382539254025412542254325442545254625472548

2549255025512552

2553255425552556255725582559256025612562256325642565256625672568256925702571

2572

25732574

2575257625772578257925802581

248

249

CD ISO/IEC 15944-12:2014(E)

For example, the personal information pertaining to the business transaction will be kept for two years after the transaction is completed after which it will be expunged.

The records retention period depends on the type of transaction and the applicable laws in the jurisdictional domain, e.g., all finance records are kept for 6/7 years. There is thus a link to the organization’s records retention schedule which in term supports applicable laws/regulations in the jurisdictional domain. The personal information may have to be retained as well, i.e., the purpose for which it was collected is still valid, i.e., it has to meet legislation. Now if the finance/tax laws do not require the personal information, then there is another task, i.e., delete all personal information but keep the rest of the record for tax purposes. Logistics to be dealt with in rules/guidelines. Must be linked to RRDS.

Rule 006:As part of the identifying purpose, the seller shall state to the potential buyer, when an individual, whether personal information collected on or received from that individual will be expunged or retained for a specified time period, should be intended business transaction not be actualized.

Rule 007:As part of identifying purpose, the organization collecting or creating the personal information in the context of the particular transaction shall state whether or not such personal information will be shared, (e.g., via EDI) with other organizations, and if so, only with those organizations which in their operations support privacy protection requirements.

5.4.4 Privacy protection principle 4: Informed consent 34

The principle of “informed consent” requires that the individual, as prospective buyer, be fully and explicitly informed by the seller as to why and for what purpose, the individual is requested (or required) to provide (additional) personal information (of various kinds), i.e., in addition to that which may be required with respect to payment aspects. This principle is clearly a requirement to flag personal information supplied as being for limited use.

Rule 008:The principle of informed consent applies to any and all ILCM aspects of the personal information created or collected as may be required.

Guideline 08G1:Organizations should have and make available to prospective buyers, i.e., as individuals, the organization’s ILCM policy as it applies to the personal information forming part of the business transaction.

5.4.5 Privacy Protection Principle 5: Limiting Collection35

Rule 009:Where the organization needs to share personal information pertaining to a specified business transaction, (e.g., via EDI), such personal information shared shall also be limited to that which is absolutely necessary and relevant.

Most often the EDI aspects pertain to a limited sub-set of the personal information pertaining to a business transaction.




251

25822583

2584258525862587258825892590

25912592259325942595259625972598259926002601

2602

26032604260526062607

260826092610261126122613261426152616

2617

26182619262026212622

26232624

252

253

CD ISO/IEC 15944-12:2014(E)

5.4.6 Privacy Protection Principle 6: Limiting Use, Disclosure and Retention36

This Privacy Protection Principle consolidates and integrates what are considered “generic, primitive” Information Life Cycle Management (ILCM) principles. As such, Clause 6 below titled “Integrated set of information life cycle management principles in support of information law compliance” applies to these privacy protection principles.37

Rule 010:The integrated set of ILCM principles applies to and supports the external constraints of a privacy protection nature for any business transaction involving an individual and its personal information.

From an ILCM perspective, this principle is particularly relevant and important especially the requirement on an organization to limit the retention of personal information pertaining to a business transaction.

Rule 011:Unless expressly required to be retained due to external constraints of applicable jurisdictional domains, or directly linked to the purpose and nature of the business transaction all personal information collected, created or received pertaining to the planning, initialization and/or negotiation of a business transaction shall be expunged where the business transaction is not actualized.

Rule 012:The seller in a business transaction shall ensure that any and all use within an organization shall be limited to the purpose of the business transaction.

Guideline 012G1:It is advised that personal information pertaining to (the same type of) business transaction, be managed within a specified DMA(s) s to facilitate implementation of required functional support services.

Rule 013:Personal information shall be retained by the seller only for as long as is necessary for the fulfillment of those purposes as specified as part of the business transaction.

Note that this rule may require that some personal data must be retained specifically for this purpose and that therefore this purpose is implicitly necessary to a transaction involving personal data.

Personal information must be identified as having a specific ‘life’ of time of existence if this is to be other than that demanded for the purposes of national record keeping. This retention time period shall form part of the scenario definition and the time period will be explicit.

Rule 014:Organizations shall have in place auditable rules and procedures as are necessary to ensure that personal information no longer required for the post-actualization phase of a business transaction shall be destroyed (expunged) by the organization, or its agents where applicable, and in a manner which can be verified via audit procedures.

Guideline 014G1:


37 The focus and scope of ISO/IEC JTC1/SC32 standards development work is “Data Management and Interchange” was at first not only within the IT system(s) of a Person of primarily organizations (including public administrations) but now also includes individuals (and their IT systems). As such, Open-edi standards development, which focuses on the collaboration space among Persons and their IT systems, has from it inception supported information life cycle management (ILCM) requirements. The need to reflect and support ILCM requirements is of particular importance where external constraints apply to the modelling of a business transaction. This was reflected and explicitly supported in the development of the existing principles, rules and definitions in ISO/IEC 15944, i.e., its definitions of relevant concept, and rules and include those found in the “Characteristics of Open-edi”, those pertaining to state changes, record retention, the specification of the collaboration space, etc., as well as being found in the templates for scoping Open-edi transactions and modelling Open-edi scenarios and their components.Annex D below brings forward and states explicitly the ILCM principles in support of information law compliance, i.e. external constraints, applicable to the modelling of common business transactions via Open-edi scenarios.


255

2625

2626262726282629

263026312632263326342635

263626372638263926402641264226432644264526462647264826492650265126522653265426552656

265726582659

2660266126622663266426652666

256

257258259260261262263264265266267268

CD ISO/IEC 15944-12:2014(E)

For most, if not all, instantiated business transactions, external constraints of the applicable jurisdictional domain(s) require that specific sets of recorded information (SRIs) pertaining to any business transaction be retained by the seller for a specified period of time.

It is recognized that, depending on the nature of the good, service and/or right which is the goal of the business transaction, specified additional records retentions requirements of applicable jurisdictional domains may apply to all or specified subsets of all the recorded information pertaining to a business transaction.

It is also recognized that where the purchase of a good, service and/or right involves “post-actualization” aspects of a temporal nature that these will also impact record retention requirements and obligations resulting from an actualized business transaction. A primary example here of an internal constraint nature is that of a “warranty” for “n” number of years38. This includes the possibility that the individual who made the purchase may not be the “warranty holder”39.

The following rules summarize these requirements from a BOV perspective:

Rule 015:The seller shall identify to the buyer, especially where the buyer is an individual, any and all record retention requirements pertaining the resulting sets of recorded information forming part of the specified goal of a business transaction as a result of applicable external constraints of jurisdictional domain(s) as a result of the actualization of the business transaction.

Rule 016:Where the seller offers a warranty, or extended warranty, as part of the business transaction, the seller shall inform the buyer, when the buyer is an individual, of the associated added records retention requirements for the personal information associated with the warranty (including the purchase by the individual of an extended warranty).

The sale of many types of goods or services, require the seller to inform the buyer of possible safety and health considerations with respect to whatever was purchased. These include product recalls, repairs, verifications checks or testing of specific function or components, etc.

Rule 017:Where the buyer in a business transaction is an individual, the seller shall inform the individual of any and all records retention requirements of personal information which is recorded as the result of the actualization of the business transaction, including:

1) personal information which is required to actualize the business transaction and the time period(s) for which such sets of personal information are to be retained;

2) additional personal information, i.e., in addition to (1), which is required to be collected and retained as a result of applicable external constraints, of whatever nature, of relevant jurisdictional domain(s); and/or,

3) additional personal information, i.e. in addition to (1) or (2), which is required to be collected and retained as a results of the invocation of an associated warranty, purchase of an extended warranty, or any other personal information which is required to be collected or retained as part of the post-actualization phase of an instantiated business transaction.

From a customer service, many sellers, i.e. organizations (including public administrations), wish to stay in contact with their customers for a variety of reasons. These include providing catalogues of their offerings,

38 Here it is noted that in order to be able to support a “warranty” of whatever nature, the seller will need to maintain personal information for a time period other, i.e. longer, than that required by law, i.e. as part of the applicable external constraints of the relevant jurisdictional domain(s). This is especially so where consumers purchase an “extended warranty”.

39 For example, where the good or service purchased as a gift. Here the recipient of the gift, as an individual, would become the owner and also would complete the warranty information including personal information required for the warranty to be invoked.


270

2667266826692670267126722673

26742675267626772678

2679

268026812682268326842685268626872688268926902691269226932694

2695269626972698269927002701

270227032704

2705270627072708

27092710

271272273274

275276277

CD ISO/IEC 15944-12:2014(E)

possible associated goods or services, etc., as well as obtaining client feedback, surveys, new product announcements, etc.

Rule 018:Where the buyer in business transaction is an individual, the seller shall inform that individual of the applicable record retention conditions where these pertain to personal information.

It is important that when the buyer is an individual that, prior to and at the actualization phase in a business transaction, that the individual is fully informed by the seller of its records retention requirements and practices of the seller particularly as these pertain to the personal information forming part of the set(s) of recorded information. Here it may well occur, depending on the nature of the business transaction, that certain types of personal information may be subject to differing records retention periods.

It is noted that where the business transaction is one of the nature of the provision of a service or a right, (such as a license or authority of some kind) that the seller needs to retains a specified set(s) of personal information for as long as a business transaction of this nature remains active.

Rule 019:Where a business transaction does not reach the actualization phase, any personal information collected by the organization in support of that transaction shall be deleted by the organization (unless the individual concerned explicitly consents to the prospective seller to the retention of such personal information for a defined period of time).

An individual may have provided personal information to a seller as part of the identification or negotiation phase. However, in this case the individual decides not to commit to the actualization of the business transaction. As such the personal information provided by the individual to the seller is no longer relevant, and therefore the organization concerned shall delete the personal information pertaining to that individual.

It is noted that this rule makes provision for the possibility that the individual, as a prospective buyer, may consent to be kept informed by the seller about product information (e.g. via a catalogue), special sales, new offerings, etc. Such a decision by the individual is of the nature of obtaining “informed consent”.

Particular care must be taken to avoid collecting or providing data that are not actually necessary for the purpose(s) of the transaction itself. By way of example, in the transaction given in section 6 of a purchase and payment it may not be necessary for the seller to know the actual personal identity of the buyer, but to have an identifier by which that buyer may be uniquely identified to the seller. It may be sufficient that the seller is certain of payment because the seller has an authority from a third party such as a bank that the transaction will be paid. Thus the bank may need to know the identity of the buyer and seller in order to fulfill its requirements in the transaction (but not the content of the transaction), whilst the seller does not need to know the identity of the buyer. The same is true when agents are used, or when a public administration is a supervisor to a transaction, where the other parties need to know and perhaps be able to prove that the public administration was involved, but not be able to identify the individual within the public administration actually involved (although the internal functions of the public administration may need that information for their own supervisory purposes).

5.4.7 Privacy Protection Principle 7: Accuracy40

It is to the mutual benefit of all parties to a business transaction, and also a good business practice, to ensure that any and all recorded information pertaining to a business transaction be as timely, accurate, complete, up-to-date, etc., as possible. Accuracy of recorded information is an essential component of “integrity41” which is a major asset of any organization. Organization should not keep recorded information on its business transaction or its clients which is not accurate or out-of-date, especially in the DMAs of its IT systems.


41 It is noted that an organization which does not have policies and auditable procedures in place, as part of its overall governance, to ensure that the recorded information on which its decisions and commitments are made, does not have the required level of “integrity” (e.g. timeliness, accuracy, being-up-to data, etc.) and ensures that all its recorded information which does not meet these criteria is expunged (unless required to be retained due to applicable external constraints), may find itself (and particular its officers) being subject to legal action for not exercising stewardship, due diligence, damages, etc., for not implementing these requirements (which in turn form part of the implementation of ILCM principles).


279

27112712

271327142715

27162717271827192720

272127222723

27242725272627272728

2729273027312732

273327342735

273627372738273927402741274227432744274527462747

2748

27492750275127522753

280

281282283284285286

CD ISO/IEC 15944-12:2014(E)

Organizations concluding business transactions with buyers, as individuals, should have no difficulties in support the external constraint of “accuracy” of a privacy protection nature (including in the DMAs of their IT systems).

The “Accuracy” principle is closely related to ensuring the “integrity” of the SRIs in an ILCM context, i.e., the trustworthiness of personal information throughout its life cycle.

Rule 020:Personal information shall be as accurate, complete and up-to-date as is necessary for the specified purposes for which it was collected in support of the business transaction.

Here, the scenario definition shall make it clear that the data identified shall subsequently be capable of amendment (including deletion). It may be that there are other data for which alteration may be forbidden, either by automatic or manually inspired processes.

One should consider the implementation of this principle to be of the nature of good corporate governance and best practices. For a variety of reasons, organization should not retain personal information, or retain the same in its IT systems, if such personal information is not accurate, complete and up-to-date.

Guideline 020G1:In order to support the privacy principle of accuracy, organizations should consider informing their clients, who are individuals, of the personal information retained on that individual, and do so on a cyclical basis in order to ascertain whether such personal information, collected earlier and still maintained by the organization, is still accurate.

5.4.8 Privacy Protection Principle 8: Safeguards42

Rule 021:Personal information shall be protected by operational procedures and safeguards appropriate to the level of sensitivity of such recorded information and shall have in place (and tested) measures in support of compliance of compliance with privacy protection requirements of applicable jurisdictional domains, as well as any other external constraints which may apply such measures as are appropriate to ensure that all applicable legal requirements are supported.

Rule 022:To support the “safeguard” principle, in an ILCM requirements context, an organization shall ensure that no personal information is destroyed, altered, falsified, rendered meaningless or useless, etc., thereby ensuring the continued integrity and authenticity of any and all SRIs, IBs, and SCs pertaining to a business transaction.

Guideline 022G1:Where an organization does not have a single designated focal point and “officer, i.e., a “privacy protection officer (PPO)” responsible for ensuring the identification and implementation of safeguard requirements applicable to all of its recorded information, it should ensure that all of its personal information meets privacy protection requirements.

This principle also introduces the concept of protection. Protection involves one or more constraints that are to be applied to specific data that are expected to provide the safeguard that is appropriate. It should be noted that the actual sensitivity of the data to be protected may be of national or cultural expectation, and need not be consistent. It should also be noted that in modelling, specific data fields are labelled with the type of privacy protection that is to be provided, but that it is for the FSV implementation to determine how such privacy protection requirements are given technical effect. In this part of ISO/IEC 15944 only the means of determining the agreed (or required) privacy protection that is attaching to specified SRIs, (e.g., data elements fields, records, etc.), is addressed.



288

275427552756

27572758

275927602761

276227632764

276527662767

27682769277027712772

2773

277427752776277727782779

27802781278227832784

27852786278727882789279027912792279327942795279627972798

289

CD ISO/IEC 15944-12:2014(E)

5.4.9 Privacy Protection Principle 9: Openness43

The principle of “openness” pertains to the privacy protection requirement that any organization which collect and uses personal information shall be fully transparent in its use of personal information. This means that all of its policies and business practices pertaining to the collection, use and management of any personal information shall be made readily and publicly available, free of charge, and via various means and media of communication. This also applies to those of an ILCM nature.

Rule 023:An organization shall have and make available to any individual, as a buyer in a business transaction, specific information about its policies and practices of an ILCM nature including state changes, retention periods, disposal, etc., including of how these are enforced with respect to the use of agents and/or third parties to the business transaction.

Guideline 023G1:It is recommended that the organization make available such ILCM information at the planning phase, or if not, during the identification phase and no later than the negotiation phase of the business transaction.

5.4.10 Principle Protection Principle 10: Individual Access44

A key component of privacy protection requirements is that an individual shall be able to enquire of any organization (private or public sector) whether or not that organization has and maintain personal information about that individual anywhere in its record/information management systems. From a business transaction and Open-edi perspective, this principle applies in particular to the DMAs in the IT systems of an organization.

It is anticipated that this principle will be enacted not through this part of ISO/IEC 15944 but through laws and regulations of the applicable jurisdictional domain(s) pertaining to the business transaction where the individual is the buyer.

Rule 024:An individual, in the role of a buyer, in a business transaction with an organization, shall be able to request and receive from the organization information of the existence, current state, use and disclosure of his or her personal in formation pertaining to that business transaction and especially any and all ILCM aspects.

5.4.11 Privacy Protection Principle 11: Challenging Compliance45

Challenging compliance is a key privacy protection principle. It pertains to the right of an individual to question and thus challenge whether or not: (1) an organization has under its control (or maintains on behalf of other organizations) personal information on the individual; and, (2) if it does, that such personal information is accurate, timely, and relevant to the nature of the informed consent provided by that individual.

Depending on the privacy protection requirements of the applicable jurisdictional domain, an individual may have the right to:

(a) challenge compliance directly with the organization to whom the challenge is directed;

(b) direct such a challenge, (e.g., complaint) to a privacy or data protection commissioner/ombudsman as provide for in the jurisdictional domain; or,

(c) various combinations of (a) or (b) above”.

It is anticipated that this principle will be enacted not through this part of ISO/IEC 15944 but through laws and regulations of the applicable jurisdictional domain(s) pertaining to the business transaction where the individual is the buyer.





292

2799

28002801280228032804

28052806280728082809

2810281128122813

2814

2815281628172818

281928202821

28222823282428252826

2827

2828282928302831

28322833

2834

28352836

2837

283828392840

293

294

295

CD ISO/IEC 15944-12:2014(E)

Rule 025:An individual shall be able to challenge the timeliness and accuracy of his or her personal information including ILCM aspects such as state changes, retention, and expungement with respect to a business transaction.

5.5 Requirement for tagging (or labelling) data elements in support of privacy protection requirements46

The application of the general privacy protection principles, as stated in Part 8, Clause 5.3, requires an organization to be able to identify and tag any and all personal information when it is created or collected in its IT systems. Such tagging is required enable an organization’s compliance with specific privacy protection requirements, (e.g., via metadata or properties/actions assigned to cells in a database). An organization can do such tagging of sets of recorded information at the records level (e.g. client file level) down to the more granular data element level.

Rule 026:An organization shall have in place policies and procedures in order to identify and tag (or label) all sets of recorded information (SRIs) which contain personal information, i.e., where the buyer to a business transaction is an individual and do so at the appropriate level of granularity to facilitate compliance with both generic and specific privacy protection requirements.

Rule 027:Where necessary to comply with ILCM requirements, the organization shall add tags to SRIs required to support the execution and management of state changes, retention periods, disposition, etc.

46 The requirements and rules stated in Part 8, Clause 5.4 apply here.


297

2841284228432844

28462847

284828492850285128522853

28542855285628572858

285928602861

2862

2863

2864

2865

298

CD ISO/IEC 15944-12:2014(E)

6 Integrated set of information life cycle management (ILCM) principles in support of information law and privacy protection requirements47


1. The text found below is based on existing Annex D (normative) in Part 8 as amended in a Part 12 context. Further development of Clause 6 is a key element in the development of Part 12.

2. JTC1/SC32 P-members are requested to review Clause 6 carefully to determine whether any new ILCM principles should be added, existing ones amended (or consolidated), etc., i.e., via their ballot comments.

6.1 Introduction – Primary purpose of Clause 6

The primary purpose of Clause 6 in this 1st edition of Part 12 is to bring forward a high level set of generic information life cycle management (ILCM) principles which integrate and consolidate the essential elements of any law, regulation, etc., which have an information law component(s). These ILCM principles and their implementation are essential in order to ensure that any organization (or public administration) complies with ILCM related requirements which are embedded in their compliance with privacy protection requirements of applicable jurisdictional domains. These principles are generic in nature. On the whole they apply to both internal constraints and external constraints. These ILCM principles therefore also provide an overall context for the privacy protection principles presented in Clause 5.3 above and which in particular, those which are required to be implemented in order to support privacy protection requirements of applicable domains.

Further, there are also legal requirements which pertain to any set of recorded information interchanged among parties to a business transaction. These include record retention requirements, those of an evidentiary nature, archiving, contingency/disaster planning, etc., a.k.a., “information law” requirements, governing information management and data interchange of an organization.

The procedures, documentation and related activities pertaining to business transactions and resulting sets of recorded information (SRIs) (consisting of one or more IBs or SCs) used in EDI require that the highest standards of integrity and trustworthiness are maintained. A primary factor here is that business transactions represent the most common form of making and executing commitments among the parties concerned.

These pertain not only to the flows of information and the contents of the recorded information but also there exists many other laws, regulations, etc., impacting information management and interchange including supporting documentation. Examples of such laws impacting business transactions include those pertaining to records keeping, access and use, disposition, archiving, etc. These are stated in the form of laws, pursuant regulations, statutory instruments, policies, codes, etc.

From a high level perspective, and taking into account specific information law requirements of jurisdictional domains (as well as those pertaining to, privacy protection requirements one can group these ILCM requirements into a number of discrete categories.

Discrete categories of "information law" already identified with respect to personal information include those that:

require one to keep or retain certain personal information;

require one to track, note, any state changes to personal information;

require one to have the ability to produce or retrieve certain types of personal information48;

require one to submit or file personal information to a government or regulatory agency;

47 The text and rules found in normative Annex D, Part 8 apply to this Clause 6 in Part 12. The text and rules in this Clause 6 focus on ILCM aspects.

48 See further below Clause 7.4 “Rules governing specification of state changes of personal information”.


300

28662867

2868

28692870

287128722873

2874

287528762877287828792880288128822883

2884288528862887

2888288928902891

28922893289428952896

289728982899

29002901

2902

2903

2904

2905

301302

303

CD ISO/IEC 15944-12:2014(E)

require one to create and/or make available personal information if one undertakes a particular activity, i.e., pertaining to a product, service and/or right;

require one retain personal information “indefinitely” or for a specified period of time;

require one to destroy personal information;

place conditions on the manner in which one handles personal information;

place conditions on the reproduction, distribution or sale of personal information; and,

place conditions on the sharing, linking or flows of personal information (within or among jurisdictions).

With respect to these categories:

(1) one or more of these categories of information law can apply to a "set of recorded information (SRI); and,

(2) an "information law" can include more than one category of requirements.

Two basic approaches are possible. The first, which is the current, traditional approach, is that of addressing each information law requirement on its own, i.e., as a "vertical silo". Here different operational areas within an organization comply with information law requirements on their own, integrate them into their applications, and deal with issues as they are identified, a crisis occurs, an audit discovers gaps, lack of compliance results in court actions, liability suits, etc. Convergence in and information communication technologies (ICT), increased the need for trustworthiness and integrity, accountability, etc., has made this "traditional" approach increasingly less viable.

It is vital that such an integrated approach to information life cycle management of the recorded information of an organization be senior management approved and driven. It is also very important that such ILCM principles focus on the WHATs not the HOWs and be stated in simple, non-technical language

6.2 Information life cycle management (ILCM) principles in support of privacy protection requirements

6.2.1 Compliance with privacy protection (and associated information law) requirements

Rule 028:Where external constraints (of a relevant jurisdictional domain(s)), with respect to privacy protection requirements to a business transaction, the Person as a seller shall ensure that such privacy protection requirements are identified and supported.

The Annex B.7 below provides a consolidated list of rules found in ISO/IEC 15944-8 which identify external constraints of relevance to supporting privacy protection requirements. Further, Clause 7 in Part 8 identifies a number of other public policy requirements of jurisdictional domains which apply where and when the Person in the role of a buyer in a business transaction is an “individual”. These include “consumer protection”, and “individual accessibility”.

These and related information law based requirements are often quite similar in nature. It therefore benefits an organization to take an integrated approach to supporting and complying with information law requirements.

Guideline 028Gn:An organization (for-profit or not-for-profit basis) (or public administration) should have: (a) an accurate and up-to-date list of all information law requirements which apply to the organization, i.e., both of a generic horizontal nature and those specific to the mix of goods and/or services it provides; and, (b) must be in full compliance with such information law requirements.


305

29062907

2908

2909

2910

2911

2912

2913

2914

2915

2916291729182919292029212922

292329242925

2926

29272928

2929

2930293129322933293429352936293729382939

294029412942

29432944294529462947

CD ISO/IEC 15944-12:2014(E)

6.2.2 Direct Relevance

Rule 029:Any personal information which exists at an organization pertaining to a (potential) buyer in a business transaction shall be directly relatable to and relevant to the (Agreed upon) goal of the business transaction.

Privacy protection requirements include the need that one collect or create only personal information which is directly related to the goal of the business transaction may be retained.

6.2.3 Timely, accurate, relevant and “under control”

Rule 030:All personal information pertaining to a business transaction shall be timely, accurate and relevant, and under “control” of the seller, i.e., it must be identifiable, retrievable and accountabilities must be assigned.

Rule 031:The organization which is the primary party to a business transaction, i.e., the seller, shall maintain “control” of all personal information pertaining to a business transaction, including where such personal information is shared with an agent or third party, (e.g., via EDI). {See further Clause 7.2 below}

6.2.4 Integrity and quality

Rule 032:Information management policies and practices, as well as those of supporting information handling systems for personal information must ensure that the level of trustworthiness, (data) integrity, quality and dependability for such personal information is consistent with and supports the organization’s objectives and information law requirements.

6.2.5 Safeguards for non-authorized disclosure requirements

Rule 033:Where required (or warranted), personal information should be protected from premature and/or non-authorized disclosure. Adequate safeguards must be enacted to ensure the required levels of privacy protection within the seller organization (and its EDI parties).

It is important to note that the corollary of this ILCM principle, i.e., mandated disclosure, is supported equally. That is, recorded information, to which the public in general and/or specified Persons have a right of access to, must not be withheld from disclosure.

6.2.6 Back-up, retention and archiving

Rule 034:Recorded information which has long-term value and/or forms part of the corporate memory should be identified and conserved. This includes recorded information required for contingency planning, back-up, emergency response and related requirements.

Rule 035:Where the buyer is an individual, personal information shall be considered confidential among the parties to the business transaction and not disclosed to any other party unless: (a) so permitted or authorized under applicable privacy protection legislation and regulation; or, (b) with the explicit and informed consent of the individual whose personal information it is.

Rule 036:


307

29482949

2950295129522953

29542955

2956

2957295829592960296129622963296429652966296729682969297029712972297329742975297629772978297929802981298229832984298529862987

29882989299029912992299329942995299629972998

2999

CD ISO/IEC 15944-12:2014(E)

Organizations shall ensure adequate back-up and contingency planning for personal information pertaining to a business transaction.

Rule 037:Organizations shall retain personal information at the required level of detail as required by applicable information law and/or post actualization requirements, (e.g., in relation to a warranty).

6.2.7 Disposition and expungement

Rule 038:Any personal information which is no longer relevant to an organization’s operations and which does not meet the above criteria should be disposed of immediately. This includes any personal information whose ILCM properties from part of the business transaction.


1. Add text and rules as required based on CD ballot comments

2. ? Do we need a short one page informative Annex on further clarification, examples, of “expungement”? P-members are invited to make CD ballot comments on this matter. The PEs are willing to prepare such a short informative document as a new Annex to Part 12.

3. Basically such a new informative Annex would expand on the definition of Clause 3.152 SRI expungement.

6.2.8 Organizational archiving

Rule 039:Where a business transaction involves personal information, the Open-edi records retention and disposal schedule (Oe-RRDS) period shall be established by the (seller) organization prior to the actualization of the business transaction.

Guideline 039G1:It is advised that with respect to any good, service and/or right which is the goal of business transactions offered that the seller (organization) has prepared and has available the information and the associated Oe-RRDS to prospective individuals as buyers.

Organizations (and public administrations) can group or categorize their Oe-RRDSs, generally or by categories of their (offered) business transactions). For cost-effective and efficient conduct of their business activities, organizations also have in place Oe-RRDs which are cost-effective, efficient and implemented in a very systematic manner.

6.2.9 Historical, statistical and/or research value


1. Ballot comments here from P-members are most welcome.

2. Personal information provided by individuals to public administrations in support of business transactions by the individual with a Person in the role of a “public administration” is often shared with and used by other public administrations within the same (level) of jurisdictional domain. A commonly used label here is “administrative data”.

3. From privacy protection requirements perspective and in an Open-edi context there are several sub-types of SPIs as administrative data , namely,


309

3000300130023003300430053006

3007

30083009301030113012

3013

3014

301530163017

30183019

3020

3021

30223023302430253026302730283029303030313032303330343035

3037

30383039304030413042304330443045304630473048

CD ISO/IEC 15944-12:2014(E)

3.1 Those which an individual is required to provide when so requested to a public administration (e.g., under a “(national) Statistics Act”, “income Tax Act”, etc., and where the access and use of such SPIs is (severely) restricted and controlled under applicable legislation (and associated regulations), i.e., any identified information law of a jurisdictional domain which “compel” an individual to provide one or more pre-defined SPIs to a public administration. Where this is the case, it is assumed that the

3.1.1 the relevant/applicable specified information law is harmonized with and supports the privacy protection requirements within that jurisdictional domain;; and,

3.1.2 that any information law requirements of a jurisdictional domain which impact privacy protection requirements of that jurisdictional domain and in turn harmonized with those of other jurisdictional domains, when and where such SPIs are shared with other jurisdictional domains, the privacy protection requirements of the jurisdictional domain of the individual rule and take precedence.49

3.2 Those which an individual decides to provide on his/her own volition in order to obtain a good, service and/or right.

4. In these cases, and others, there exist laws, regulations, policies and procedures, which govern, i.e., provide a legal basis to “take’, i.e., copy, SPIs collected, managed and used for a specific goal of a business transaction by a public administration (and also by private organization), is required to be interchanged by the seller organization to (another) public administration. On the whole data of this nature is known as “administrative data”. From an ILCM needs perspective, “administrative data”, copied, via EDI to another organization, and in particular where such EDI is either required or sanctioned by law, the originating organization loses “control” of data of this nature to the receiving organization.

5. Here it is assumed that once such an EDI takes place that there are no more “state changes” to the SRIs transferred as IBs. This is the “default” rule. At the same time, there are occasions (or applications”) which required continues data flows of SRIs pertaining to a business transaction to another organization (as legal entity) for “administrative data” purposes. Where such SRIs are or include SPIs, privacy protection requirement’s apply and must be supported.

6. The development of an ISO standard based solution to the issues identified above requires additional work and resources, as well at a level of detail which is more than that of this 1 st edition of this Part 12. Therefore consideration should be given to addressing issues of this nature via a new ISO/IEC 15944 project as a “Technical Report” to be incorporated into the 2nd edition of this Part 12, a new Part of ISO/IEC 15944, or remain as a TR ( to be referenced document for new editions of existing Parts of ISO/IEC 15944.

7. JTC1/SC32 P-members are requested to provide input on the best ways to address these and related issues via their CD ballot comments.

It is a common practice, as well as one sanctioned and supported through relevant applicable information law that personal information collected or provided as SPIs for a specific purpose in support of particular decision taking and commitment-making pertaining to the individual, i.e., in any type of business transaction, is and can be used for other purposes where so permitted or sanctioned based on applicable information law. (and pursuant regulations and related legal instruments). This is especially so with respect to SPIs provided to or collected by public administrations use in a business transaction.

Rule 040:Personal information which has historical value should be identified and conserved (as part of the organization’s and/or electronic cultural heritage/” (“patrimoine informatisée”).

49 This requirement links to consumer protection requirements which state that the legal and regulatory requirements of the jurisdictional domain on the “consumer” govern the rights of the consumer, independent of any other jurisdiction al domains of the parties involved to the particular business transaction.


311

3049

305030513052305330543055305630573058305930603061306230633064306530663067306830693070307130723073307430753076307730783079308030813082

3083308430853086308730883089

3090309130923093309430953096309730983099310031013102

312313314

CD ISO/IEC 15944-12:2014(E)

It is not uncommon that personal information resulting from a business transaction may have historical or research value. This is especially so in public organizations and governments. For example, many jurisdictional domains have archiving legislation which allows their archives to retain non-active personal information. The same situation is common in medical institutions.

Rule 041:Applicable archival or research oriented legislation or regulation may exempt specified personal information from being expunged.

It is noted that research oriented legislation, as well as (international) research protocols usually require that personal information to be used with respect to (longitudinal) research projects be anonymized. In addition, personal information which is retained for archival purposes can become publicly available after the death of the individual, after 100 years, or according to legislative or regulatory constraints which are similar in nature.

Rule 042:An individual may request or agree to, as part of his explicit and informed consent in entering into a business transaction, to allow the party in the role of seller to retain specified personal information after normal or statutory retention period has expired.

Rule 043:Where the buyer in a business transaction is an individual the seller shall provide detailed information on the seller’s retention and disposal schedule for personal information created or collected during any of the five phases of the business transaction.

Apart from the fact that privacy protection requirements apply to the seller with respect to retention and disposal of any and all personal information pertaining to the prospective individual buyer, depending on the nature of the business transaction, various legal, regulatory, statutory, etc., records retention and disposal authorities apply. For example, the financial aspects of a business transaction may be required to be retained for a minimum of seven (7) years following the completion of a business transaction. Also, certain types of personal information may be required to be retained “forever”. Many of these involve information law requirements of a generic nature and are usually maintained by public administrations or their agents, (e.g., notaries, lawyers, etc.). Examples include titles of property, (sale records), marriage (and divorce) records, etc.


316

31033104310531063107

3108310931103111311231133114311531163117311831193120312131223123312431253126

312731283129313031313132313331343135

CD ISO/IEC 15944-12:2014(E)

7 Rules governing the specification of ILCM aspects of personal information

7.1 Introduction

Generic aspects of external constraints of jurisdictional domains as rules and definitions governing business transactions are found in ISO/IEC 15944-5.

Note: Users of this document are advised to familiarize themselves with the rules, definitions and associated text of Clause 6.6.4 “Data component”, as found in ISO/IEC 15944-5 (a “freely available standard”).

Within a data management and interchange context, it is important that parties to a business transaction control the states of their IT systems. This is a fundamental characteristic of Open-edi. Under internal constraints it is a best practice of organizations and public administrations to maintain control of the sets of recorded information (SRIs) in their IT systems (as especially those in their DMAs). This includes both state changes as well as records retention and scheduling requirements. This pertains to basic information life cycle management (ILCM) principles in support of information law compliance. {See further above Clause 5)}

The need for information law compliance is even more so and mandatory when the set(s) of recorded information pertain to a business transaction, i.e., a “commitment exchange”, where the buyer is an individual.

These generic Open-edi aspects and rules pertaining to a business transaction are mandatory in any business transaction context which involves an individual as a buyer. This is because, where this is the case, privacy protection requirements apply.

The generic aspects of external constraints of jurisdictional domains of a privacy protection nature as rules and definitions governing business transactions are found in ISO/IEC 15944-8.

The purpose of this Clause 7 is to bring forward in an integrated manner in an Open-edi context applicable concepts and their definitions as well rules and related normative text found in Part 5 and Part 8 in the particular context of this Part 12 of ISO/IEC 15944 which focuses on privacy protection of an ILCM nature requirements; namely:

1) those pertaining to state changes in the sets of recorded information (at whatever level of granularity); and;

2) those pertaining to records retention requirements, including assured disposition of personal information.

As such, the purpose of Clause 7 is to bring forward normative text, rules and associated coded domains from ISO/IEC 15944-5, Clause 6.6.4.2 and 6.6.4.3 and present them in an amended form, as and where required, in the context of privacy protection requirements focusing on ILCM aspects. (This approach is similar to that taken for Clause 8 in this document which also applies normative text from others parts of ISO/IEC 15944 and applies it in a privacy protection requirements and ILCM context.)

A common requirement of external constraints of a public policy nature is that they mandate records retention (and deletion) requirements, (e.g., consumer protection, privacy protection, etc.). In order to bridge legal, operational, public policy and IT perspectives, records retention is defined as in an Open-edi context 50 as:

Open-edi records retention and disposal schedule (Oe-RRDS)

specification of a period of time that a set of recorded information (SRI) shall be retained by a Person in order to meet operational, legal, regulatory, fiscal or other requirements as specified in the external constraints (or internal constraints) applicable to a Person who is a party to a business transaction

50 Multiple definitions exist for “records retention” within a single jurisdictional domain as well as among jurisdictional domains, professional organizations, etc. In order to differentiate the concept of “records retention” within the context of e-business, e-government, etc., i.e., an Open-edi context, a unique label or term has been invented/coined, i.e. that of “Open-edi records retention and disposal schedule (Oe-RRDS). This “generic” Open-edi definition links to privacy protection requirements in that these are legal or regulatory in nature.


318

3136

3137

313831393140

31413142

314331443145314631473148

31493150

315131523153

31543155

3156315731583159

31603161

31623163

31643165316631673168

316931703171

3172

317331743175

319320321322323

CD ISO/IEC 15944-12:2014(E)

As stated in ISO/IEC 15944-1 records retention requirements need to be specified:

in the scoping of an Open-edi scenario, (e.g., as a Post-actualization requirement, of a Data Component requirement);

as an attribute of an Information Bundle, (e.g., for specifying internal constraints). {See ISO/IEC 15944-1 Clause 8.5.2.8 and Rule 140; and, for external constraints, see ISO/IEC 15944-1, Clause 8.5.2.9 and Rule 141}.

It is important to be able to specify which of the parties to a business transaction is responsible for retention of IBs or the complete set(s) of recorded information.51

Many, if not most, of the privacy protection requirements are of an information management nature. A key reason here is that privacy protection requirements are a type of information law. Consequently, the integrated set of information life cycle management (ILCM) principles applies.

Rule 044:Management and control of state change, retention and destruction of personal information shall be based on the application of the integrated set of information life cycle management (ILCM) principles.

7.2 Rules governing establishing ILCM responsibilities for personal information

It is important that in the modelling of a scenario for a business transaction that one establish which party (or combination of parties) to business transaction has (primary) responsibility for ILCM aspects.

Rule 045:Where an individual is a buyer to a business transaction, the seller shall specify who is responsible for the retention and disposal of any (combination) of SRIs and in particular all SPIs and do so during, or before, the negotiation phase and no later than at the actualization phase in accordance with privacy protection requirements.

Guideline 045G1:Unless required to be otherwise or negotiate otherwise, the default is that the Person in the role of seller is responsible all aspects of ILCM of the SRIs pertaining to a business transaction and especially all SPIs.

Rule 046:Where an individual is a buyer in a business transaction, the seller shall ensure that all other parties to the instantiated business transaction, as applicable, (e.g., a regulator, an agent, and/or third party) are informed of records retention (and disposal requirements) and agree to abide by and support them.

Guideline 046G1:In support of Rules 045 and 046, the seller, as well as any other parties to the business transaction involving an individual as buyer, (e.g., a regulator, an agent, and/or third party) should use ISO/IEC 15944-2 Coded domain 02 Codes Representing Specification of Records Retention Requirements. This coded domain is presented below as Table 01.

Guideline 046G2:The nature of the goods, services, and/or rights of the business transaction may limit or specify which of the options in coded Domain ISO/IEC 15944-12:01 can be used or are valid.

Guideline 046G3

51 The concept of “information bundle (IB)” pertains to the grouping of one or more semantic components(SCs) of data interchanged among Open-edi parties to a business transaction. From a data management perspective and. in an ILCM context, the concept of “set of recorded information (SRI) is used. An SRI can be the content value of a single data element, several grouped and managed together, a complete record or file, etc.


325

3176

31773178

317931803181

31823183

318431853186

318731883189319031913192

319331943195319631973198319932003201320232033204320532063207320832093210321132123213321432153216321732183219322032213222

326327328329

CD ISO/IEC 15944-12:2014(E)

Use of an ID Code 02 in Coded Domain ISO/IEC 15944-12:01 is considered a “rarity” and the individual as a prospective buyer in a business transaction should be informed of the rationale for being responsible for ILCM requirements pertaining to the relevant personal information

Rule 047:Unless otherwise specified by the seller the business transaction number (BTN) shall serve as its common unique ID for the instantiated business transaction for linking ILCM requirement to applicable SRIs..

External constraints of a public policy nature such as privacy protection (and consumer protection as well) require, i.e., make mandatory, both (1) the retention of personal information pertaining to a business transaction where the individual is the buyer; and, (2) the assured destruction of personal information based on both legal requirements and contractual obligations. {See further above Annex D (Normative) Integrated set of information life cycle management (ILCM) principles in support of information law compliance}.


1. This Part 12 Coded Domain 01 presented below as Table 1 is an amended and more detailed version of Coded Domain 02 in Part 5.

2. NOTE: These Project Co-Editors’ comments also apply to the other Part 12 Coded Domains presented in Clause 7.

Table 1 — ISO/IEC 15944-12:01 Codes representing specification of records retention responsibility for personal information52

ISO/IEC 15944-12:01 Codes representing specification of ILCM responsibility for personal information where the buyer is an individual

IT Interface Human Interface Equivalents (HIEs):Linguistic – Written Form

Source Authority ID

Coded Domain

ID

ID Code

ISO English ISO French

15944-12 01 00 other autre

15944-12 01 01 seller is responsible for all ILCM aspects and shall inform the buyer of what they are

15944-12 01 02 Individual as buyer is responsible for ILCM aspects and the seller shall specify what these are53. | (Note: The seller shall inform the buyer of the basis as to why ILCM responsibilities are assigned to the buyer.)

15944-12 01 03 seller and buyer are both responsible and seller shall inform the buyer, as individual, what his/her ILCM responsibilities are

15944-12 01 04 Seller shall specify to the individual as buyer what specific IBs to retain as resulting from the business transaction

52143 NOTE: Should there be a requirement for additional conditions for the specification of records retention responsibilities these can be added via a Technical Corrigenda to this part of ISO/IEC 15944 or in the next edition of this part of ISO/IEC 15944.

53 Use of ID Code 2 is a “logical” possibility. Its use should be considered a “rarity”


331

32233224322532263227322832293230323132323233323432353236

3237

32383239

32403241

32423243

332333334

335

CD ISO/IEC 15944-12:2014(E)

ISO/IEC 15944-12:01 Codes representing specification of ILCM responsibility for personal information where the buyer is an individual

IT Interface Human Interface Equivalents (HIEs):Linguistic – Written Form

Source Authority ID

Coded Domain

ID

ID Code


15944-12 01 05 seller and individual shall use a common third party, (e.g., a notary)

15944-12 01 06 regulator is responsible for retaining the personal information54

15944-12 01 07 regulator and seller are responsible

15944-12 01 08 regulator and individual are responsible. (The buyer as individual is informed of the personal information being retained)

15944-12 01 09 regulator, buyer and individual are all responsible. (The buyer as individual is informed of the personal information being retained).

15944-12 01 10 regulator mandates the involvement of a (role) qualified or designated third party, i.e., on behalf of seller, the individual and regulator.55

15944-12 01 98 not known inconnu

15944-12 01 99 not applicable sans objet

7.3 Rules governing establishing specifications for retention of personal information – applicable “SRI retention triggers”

External constraints of a record retention nature have requirements which specify (1) when a retention requirement is to start, i.e., via a limited number of triggers; and, (2) then a specified (minimum) retention period. On the whole, records retention requirements are triggered by an action or event. The basic conditions here from an external constraints perspective for "retention triggers" are limited. The most common ones are presented in the following Coded Domain 04 of ISO/IEC 15944-5 (and also Annex F in Part 8). It has been amended in the context and focus of Part 12.

Rule 048:Where an individual is a (potential) buyer to a business transaction, the seller shall specify the “retention triggers” activating records retention requirements for the SRIs (and any combination of the same) pertaining to that business transaction and do so in accordance with applicable privacy protection requirements of the applicable jurisdictional domain(s) for that business transaction..

Guideline 048G1:In support of Rule nn, the seller as well as any other parties to the business transaction, (e.g., a regulator, an agent, and/or third party) should use the ISO/IEC 15944-12 Coded Domain 02 “Codes representing retention triggers for retention and disposition of personal information”.

54 An example would be the personal information for a driver’s license, or any other transaction where the regulator is the “authoritative” source.

55 Examples include notarial acts, a regulator assigning a record-keeping registry, etc., function to a third party.


337

3244

32453246

324732483249325032513252

32533254325532563257325832593260326132623263

338339

340

CD ISO/IEC 15944-12:2014(E)

Table 2 — ISO/IEC 15944-12:02 Codes representing SRI retention triggers for retention of personal information56

ISO/IEC 15944-12:02 Codes representing SRI retention triggers for retention and disposition of personal information

IT Interface Human Interface Equivalents(HIEs): Linguistic –Written Form

Source Authority ID

Coded Domain

ID

IDCode


15944-12 02 00 other autre

15944-12 02 01 start applicable retention period at the date/time for set(s) of recorded information as received, created and/or collected as part of the “identification phase” of the business transaction

15944-12 02 02 start applicable required retention period at date/time for set(s) of recorded information as received, created or collected as part of the “actualization phase” of the business transaction (including those based results of completion of the “negotiation phase”)

15944-12 02 03 start applicable required retention period from date of last action or use of the SRIs with respect to the business transaction

15944-12 02 04 start applicable retention period at end of calendar year when the business transaction was completed at end of the “actualization phase”

15944-12 02 05 start applicable retention period at end of fiscal year when the business transaction was completed at end of the “actualization phase”

15944-12 02 06 start applicable retention period at end of calendar year when the business transaction was completed at end of the “post-actualization phase”

15944-12 02 07 start applicable retention period at end of fiscal year when the business transaction was completed at end of “post-actualization phase”

15944-12 02 99 not applicable 57 sans objet


57 This would apply to recorded information, i.e. A particular SRI, deemed to be ephemeral or transitory in nature (e.g., such as a “session cookie”).


342

326432653266

3267

343344345

346347

CD ISO/IEC 15944-12:2014(E)

It is also important to state the actual retention period, i.e., temporally. At the same time, it is a not uncommon occurrence that privacy legislation, or pursuant regulation, does contain a minimum temporal period for the retention of personal information, particularly where such personal information pertains to decision-taking or commitment-making such as takes place in the formation of a business transaction.

In many jurisdictional domains it is a requirement (e.g., consumer protection-based), that the potential buyer is fully informed of all the conditions which apply to an eventual purchase of a good, service and/or right. Similarly, privacy protection requirements require informed consent with respect to any collection, use, sharing, retention, etc., of personal information where the buyer is an individual. This includes the seller providing full and complete information on the duration of the retention of personal information. These and related requirements are captured in the following rules.

The record retention period(s) for SRIs and associated IBs (and SCs) need to be specified and stated explicitly. The retention period is independent of the retention triggers.

Rule 049:The period that recorded information pertain to a business transaction where the individual is a buyer, is retained (as once or more SRIs) shall be specified and made known to the individual.

Guideline 049G1:In support of this Rule nnn, the seller as well as any other party (ies) to the business transaction, (e.g., a regulator, an agent and/or third party) should use the ISO/IEC 15944-12 Coded Domain 03 “Codes representing retention period.

Rule 050:

Where the (prospective) buyer is an individual, the seller shall inform the buyer of minimum record retention period(s) of applicable privacy protection requirements which apply where a business transaction enters the “identification phase” and further.

Guideline 050G1

Sellers should apply Rule 050 as a best business practice and inform all buyers of their applicable minimum retention period for SRIs of buyer information.

Rule 051:

Where the (prospective) buyer is an individual, the seller shall inform the buyer of a maximum record retention period(s) of applicable privacy protection requirements which apply where a business transaction enters the “identification phase” and further.

Guideline 051G1

Sellers should apply Rule 051 as a best business practice and inform all buyers of their applicable maximum retention period for SRIs of buyer information.

Rule 052:

Where the (prospective) buyer is an individual, the seller shall inform the buyer of any record retention period(s) as required by applicable laws or regulations requirements which apply and which “override” those of a privacy protection nature, including “permanent” retention where a business transaction enters the “identification phase” and further.

Rule 053:

Where the (prospective) buyer is an individual, the seller shall inform the buyer of the record retention period(s) of applicable privacy protection requirements (other than those of a minimum or maximum nature) which apply where a business transaction enters the “identification phase” and further.


349

3268326932703271

327232733274327532763277

327832793280328132823283328432853286328732883289

3290

329132923293

3294

32953296

3297

329832993300

3301

33023303

3304

3305330633073308

3309

331033113312

CD ISO/IEC 15944-12:2014(E)

Table 3 — ISO/IEC 15944-12:03 Codes representing the specification of types of record retention period

ISO/IEC 15944-12:03 Codes representing the specification of types of record retention period


Source Authority ID

Coded Domain

ID

IDCode


15944-12 03 00 other autre

15944-12 03 01 Minimum retention period is stated in applicable privacy protection requirements58

15944-12 03 02 Maximum retention period as stated in applicable privacy protection requirements. (Seller to provide information to individual as buyer )59

15944-12 03 03 Nature of the good, service and/or right as the goal of the business transaction invoke other minimum retention periods which of a longer temporal nature than that of privacy protection requirements60 (Seller to provide information to individual as buyer)

15944-12 03 04 Nature of the good, service and/or right as the goal of the business transaction requires permanent retention of specified personal information.61

15944-12 03 05 The retention period is specified using date/ time referencing based on the ISO 8601 standard, i.e. a temporal period specified in years, months, weeks, days, hours, minutes, etc., a.k.a the .Gregorian calendar.62

15944-12 03 06 The retention period is specified based on a temporal referencing schema other than that based on ISO 8601 standard, and if so needs to be

58 A common default for personal information is two (2) years after business transaction completed. For SRIs of a financial nature it is a minimum retention period of seven (7) years.

59 For example, IBs pertaining to the use of a telecom service often have a maximum retention period after which the telecom provide deletes the record of the same. This varies per jurisdictional domain.

60 An example here would be financial information pertaining to an actualized business transaction where financial information may have to be retained for a minimum of seven years.

61 A code “04” would apply to the purchase and sale of what are commonly known as “immovables” (e.g., a piece of land, a house, etc.

62 On temporal referencing, see further, ISO/IEC 15944-5, Clause 6.6.45 titled “Date/Time referencing”


351

331333143315

352353

354355

356357

358359

360

CD ISO/IEC 15944-12:2014(E)

ISO/IEC 15944-12:03 Codes representing the specification of types of record retention period


Source Authority ID

Coded Domain

ID

IDCode


specified63

15944-12 03 07 ??

15944-12 03 08 ??

7.4 Rules governing identification and specification of state changes of personal information64

7.4.1 Introduction

A fundamental aspect of data management and interchange among autonomous Persons (or even within an organization or public administration) is that of ensuring the accuracy, timeliness and relevancy of its (sets of) recorded information (SRI). A second fundamental aspect here is that any Person (or whatever nature) shall do so in compliance with applicable external constraints of the relevant jurisdictional domain.

A key characteristic of Open-edi is that "parties control and maintain their states". {See Clause 5.4, ISO/IEC 15944-1} As such, it is important to know whether or not the value of an Information Bundle (IB) (or one of its Semantic Components (SCs) interchanged among parties to a business transaction is allowed to be changed during any stage in the process component. Knowing whether or not state changes are allowed for a specific IB or SC is important for the management of state description and automated change management of the state machines of the parties involved in an electronic business transaction.

This is a requirement which also exists in modelling business transactions involving internal constraints only. However, those which exist here are likely to be a sub-set of those which arise from external constraints.

It is not that during the life cycle of a business transaction, i.e., from its planning through post-actualization phases, that are more of the SRIs which are personal information in nature and pertain to the business transaction may require a state change to their content value(s). For example, the address of the buyer as individual may change or the planned delivery date, delivery location, etc.

At the same time, there are SRIs pertaining to personal information in a business transaction for which no state changes are allowed, (e.g., the Business Transaction Number (BTN).

It is also understood that with respect to any personal information pertaining to an individual as a party to a business transaction, that privacy protection requirements.

Rule 054:Where the recorded information pertaining to a business transaction contains personal information (as one or more SRIs), the seller shall specify: (a) for which such SRIs, there will be no state changes; and, (b) for which SRIs state changes are allowed and, if so, under which conditions.

63 See ftnt. 60 above. The Clause in Part 5 provides information on other temporal referencing schemas such at the “atomic clock”, the “GPS calendar/clock”, etc.

64 This Clause integrates applicable text and rules of Clause 6.6.4.3 of Part 5, and that of Clause F.2 in Part 8.


364

3316

33173318331933203321

3322

3323332433253326

332733283329333033313332

33333334

3335333633373338

33393340

33413342

33433344334533463347

365366

367

CD ISO/IEC 15944-12:2014(E)

Rule 055:A business involves an individual as a buyer in a business transaction the seller shall inform and obtain informed consent from the buyer, as individual, to any state changes to any SRIs pertaining to the business transaction, including those forming the basis for (one or more SCs or SRIs), as IBs in EDI with parties to a business transaction.

A related issue is that of “What happens to recorded information, i.e., SRIs, which existed prior to a state change being made”? It is important for parties to a business transaction to know this. In summary, two attributes are required to specify state change of data. They are:

number of state changes allowed, if any; and,

store change type.

The inter-working of these two attributes, i.e., as codes in two coded domains, covers the various combinations of state changes in the data value for each IB and SC as well as what actions are required with respect to both “new” and “old” data including those required for information life cycle management (ILCM) within an organization, audit trails, evidentiary requirements, disposition/expungement, etc., and any external constraints of this nature of jurisdictional domains.

7.4.2 Specification of state changes allowed to personal information

Rule 056:Where an individual is a party to a business transaction, i.e., as a buyer, the seller (as an organization or public administration) shall have in place rules governing state changes, if any, for personal information (at whatever level of granularity required) in support of ILCM and EDI required to comply with privacy protection requirements.

Rule 057:Where the buyer is an individual, the seller shall inform the buyer whether or not state changes will be allowed for one or more of the SRIs constituting the recorded information pertaining to that business transaction.

Guideline 057G1:Depending on the nature of the good, service and/or right which is the goal of the business transaction external constraints of applicable jurisdictional domain(s) may prohibit a state change to one or more SRIs.

An example of use of Code “0” would be the transaction record ID number as the business transaction identifier (BTI), {See further Clause 11.2 above} i.e., the unique ID number assigned by the seller to an instantiated business transaction. Codes “1”, “2”, “3”, etc., are used to deal with IBs and SCs pertaining to location information, (e.g., physical or electronic addresses), price and terms negotiations, the buyer changing its decision on a choice of options, etc.

An example of an IB (or SC) having a Code “09” with respect to state changes would be in item tracking in a logistics system, (e.g., the seller provides to a buyer a facility to access the seller or logistic provider system to track the movement of an item to be delivered to the buyer). The content value of the related SRI would undergo state changes of a dynamic basis.

Note: If several SRIs pertaining to a business transaction are allowed to be changed, care must be taken to prevent the business transaction from transforming itself into a completely new business transaction. A factor to be considered is for those SRIs allowing (too many) changes may lead to “disharmony” among the various SRIs, thereby compromising the integrity of the recorded information on a business transaction. For example, as already stated below as a rule, no state change shall be allowed to the BTN on an instantiated business transaction

Rule 058:An instantiated business transaction shall have one or more IB or SC for which no state changes are permitted. One of these is to serve as the transaction ID number, i.e., a business transaction identifier (BTI), for the instantiated business transaction.


369

33483349335033513352335333543355335633573358

3359

33603361336233633364

3365

336633673368336933703371337233733374337533763377337833793380338133823383338433853386

3387338833893390

339133923393339433953396

3397339833993400

CD ISO/IEC 15944-12:2014(E)

Guideline 058G1:It is advised that in modelling scenarios, scenario attributes roles, information bundles and scenario components that one set the state change code to “00” wherever applicable especially for those pertaining to personal information.

This Guideline serves to ensure that all parties to a business transaction agree to and have knowledge of permitted state change to the value of an IB or SC.

Rule 059:If a state change is required, the seller (and/or regulator) shall specify the number of state changes permitted.

Guideline 059G1:In support of rules nn-a and nn-b, the seller as well as other parties to the business transaction as applicable, (e.g., the regulator, an agent, or third party) should use the ISO/IEC 15944-12 Coded domain 04 to specify the applicable state change ID codes.


371

34013402340334043405340634073408

34093410341134123413341434153416

CD ISO/IEC 15944-12:2014(E)

Table 4 — ISO/IEC 15944-12:04 Codes for specifying whether state changes allowed for the content values of SRIs containing personal information65

ISO/IEC 15944-12-04 Codes for specifying whether state changes allowed for the content values of SRIs containing personal information


Source Authority ID

Coded Domain ID

ID Code ISO English ISO French

15944-12 04 000 no state change allowed (default)

15944-12 04 010 One state change allowed as per nature of business transaction

15944-12 04 011 One state change allowed as requested by buyer as individual

15944-12 04 012 One state changes allowed as requested by the seller and consented to by the buyer

15944-12 04 013 One state change allowed as may be required by the regulator

15944-12 04 020 Two state changes allowed as per nature of business transaction

15944-12 04 021 Two state changes allowed as requested by buyer as individual

15944-12 04 022 Two state changes allowed as requested by the seller and consented to by the buyer

15944-12 04 023 Two state changes allowed as may be required by the regulator

15944-12 04 030 Three state changes allowed as per nature of business transaction

15944-12 04 031 Three state changes allowed as requested by buyer as individual

15944-12 04 032 Three state changes allowed as requested by the seller and consented to by the buyer

15944-12 04 033 Three state changes allowed as may be required by the regulator

15944-12 04 090 No limit on the state changes allowed as per nature of the business transaction

15944-12 04 091 No limit on the state changes allowed as requested by the buyer as individual and agreed to



373

341734183419

374375376

CD ISO/IEC 15944-12:2014(E)

ISO/IEC 15944-12-04 Codes for specifying whether state changes allowed for the content values of SRIs containing personal information


Source Authority ID

Coded Domain ID

ID Code ISO English ISO French

by the buyer

15944-12 04 092 No limit on the state changes allowed as per nature of the business transaction as requested by the seller and agreed to by the buyer as an individual

15944-12 04 093 No limit on state changes allowed as may be required by the regulator

7.4.3 Specification of store change type

It is important to specify clearly and explicitly the action to be taken and the processes to be followed by the seller (as well as its agents and third parties) with respect to the original content value of an SRI (and related IBs and SCs) when the content value for these is changed during any of the phases in a business transaction.

Rule 060:If a state change is permitted to the original data value of the SRI and resulting IB (or its associated SCs), i.e., (1) any entered in the DMA(s) of the IT system(s) of the organization or public administration which acting in the role of a seller or a regulatory in a business transaction involving an individual and/or as, (2) interchanged among the Persons involved, it is necessary to specify in the business object being modelled the store change type permitted.

Guideline 060G1:

In support of Rule 060, the seller as well as other parties to the business transaction as applicable. (e.g., the regulator, an agent or a third party) should use the ISO/IEC 15944-12 Coded Domain 05 to specify store change type.

The ID code in this coded domain defines and specifies what action is to be taken when a state change in the content value of a SRI is allowed. This is necessary to support required audit trails, data integrity and ILCM including archiving/disposition requirements as well as from a legal/evidentiary requirements perspective. The ID codes for Store Change Type in 66Table??? below identify whether the previous content value of an SRI are required to be retained, in addition to the most current data value. IF they are not required, the new value can replace the existing content value. If an audit history must be maintained then the relevant DMA in the IT system of the seller (and its agents and/or third parties) must be able to maintain multiple versions of the content value of the SRI including possible associated IT systems-generated date/time stamps.

Table 5 — ISO/IEC 15944-12:05 Codes representing store change type for SPIs (and SRIs)67

66 An example by analogy is that of an historical record of changes to the balance in one’s bank account. Another example, (linked to ISO/IEC 15944-9) is that of traceability data in the form of SRIs pertaining to the movement/logistics of a “good” being delivered from a seller to a buyer.-0o/

67 NOTE: Should there be a requirement for additional conditions for the specification of records retention responsibilities these can be added via a Technical Corrigenda to this part of ISO/IEC 15944 or in the next edition of this


378

3420

3421

342234233424

34253426342734283429343034313432

343334343435

34363437343834393440344134423443

3444

3445

379380381

382383

CD ISO/IEC 15944-12:2014(E)

ISO/IEC 15944-12-05 Codes Representing Store Change Type for SRIs as Information Bundles and Semantic Components


Source Authority

Coded Domain

ID

ID Code


15944-12 05 00 other autre

15944-12 05 01 store new data value for the specified SRI and expunge previous data value

15944-12 05 02 store new data value, expunge previous value for the specified SRI with date/time stamp when state change occurred

15944-12 05 11 store new data value for the specified SRI and previous data value only

15944-12 05 12 store new data value for the specified SRI and previous data value for the specified SRI only and add a date/time stamp

15944-12 05 21 store new data value for the specified SRI and “nn” previous values for the specified SRI maintaining a sequence number of all state changes. here “nn” must be specified

15944-12 05 22 store new data value and “nn” previous values maintaining security, and maintaining a date/time stamp for each state change. Here “nn” must be specified set of unique identifiers.

15944-12 05 31 store new data value for the specified SRI and all changes maintaining a sequence number of all state changes for the specified SRI

15944-12 05 32 store new data value for the specified SRI and all changes, maintain a date/time stamp for each state change for the specified SRI

15944-12 05 99 not applicable, i.e., no state change allowed 68

One notes that a code “99” here works in tandem with a Code “00” in the previous Coded Domain. Use of a Code “01” or “02” means that having the previous value only is sufficient. This is often the case for change in location, (e.g., for physical or electronic address information). The use of the other codes links to ensuring record of decision, audit trails, evidentiary requirements and other external constraints which may apply due to the nature of the business transaction.

part of ISO/IEC 15944.

68 For example, a code 99 here is automatic when a code 00 was assigned to the SRI or SPI based on Coded Domain 4 in ISO/IEC 15944-12.


385

3446

34473448344934503451

3452

386

387388

CD ISO/IEC 15944-12:2014(E)

7.4.4 Rules governing specification of source of state changes

Basically there are three primary sources of state changes to SRIs pertaining to a business transaction namely: (1) those initiated by the buyer; (2) those initiated by the seller; and, (3) those required by applicable external constraints.

The state change requirements of these three sources are not necessarily exclusive and may well be complementary to each other.

Rule 061:In order to comply with privacy protection requirements, the source of the state change to a content value of any SRI forming part of a business transaction shall be specified as seller, buyer, and/or an external constraint.

Guideline 061G1:

In support of Rule 061, the seller as well as other parties to the business transaction as applicable. (e.g., the regulator, an agent or a third party) should use the ISO/IEC 15944-12 Coded Domain 06 to specify source of state change type. (and an ID code of “99” for those SRIs for which no state change is allowed). It is noted that use of one or more the ID codes in this Coded Domain are not exclusive but may well be complimentary.

Table 6 — ISO/IEC 15944-12:06 Codes representing source of state change type ID code for SRIs69

ISO/IEC 15944-12-06 Codes representing source of state change type ID code


Source Authority

Coded Domain

ID

ID Code


15944-12 06 01 Buyer originated, i.e., the buyer as an individual is the only one who can request a state change to the content of one or more SRIs pertaining to a business transaction.

autre

15944-12 06 02 Seller originated, i.e., those which the seller identifies and proposes to the buyer as a state changes associated with the business transaction.

15944-12 06 03 Regulator originated, i.e. those which apply to the nature of the good, service and/or right and which are identified as such by the seller to a (prospective) buyer in a (proposed) business transaction.

15944-12 06 11 The seller has informed the buyer of conditions pertaining to ID codes 01. 02 and 03, and the buyer has agreed to the application of a combined combination of the same , i.e., as a result of the negotiation phase, with respect to the business transaction to be actualized

15944-12 06 ??



390

3453

345434553456

3457345834593460346134623463

3464

34653466346734683469

3470

391392393

CD ISO/IEC 15944-12:2014(E)

ISO/IEC 15944-12-06 Codes representing source of state change type ID code


Source Authority

Coded Domain

ID

ID Code


15944-12 06 ??

15944-12 06 99 Not applicable, i.e., no state change is allowed, (therefore source of state change does not apply)

7.5 Rules governing disposition of personal information

Project Co-Editors” Notes:

1. Within the information/document management community, the concept and application of the process. actions pertaining to “disposition” of any SRI are well understood. They include those aspects which are already covered by IS standards of ISO TC46/SC11 (see those ISO standards identified in initial Project Co-Editors’ Notes to this CD document.

2. However within the JTC1/SC32 community of participating P-members and individual experts, participating in one or more WGs of JTC1/SC32, the importance of applicability and incorporation of ILCM aspects and applicable in ‘ JTC1/SC32 “Data Management’ standards for “Data Management and Interchange”{ are not either appreciated or understood.

2. In addition, the “disposition” action with respect to any SPECIFIED set of recorded information, i.e., as an SRI or a combined set of SRIs basically has the same set of disposal actions. |These are presented below but are conditioned governed by those which are applicable and pertain to any SRI containing “personal information is not addressed in current JTC1/SC32 standards including those which pertain to JTC1/SC32/WG2 “Metadata” and SC32/WG3 & WG4 SQL related standards.

4. Here from a privacy protection requirements standard perspective for any “personal information” whether from an (a) metadata perspective, when and wherever any personal information is of a “metadata” nature or not; and/or includes application and use of JTC1/SC32 “SQL standards”, it is important that any such existing and all existing/future personal information is of a “direct” personal information: is mature, or an “indirect “metadata” personal information nature” is recognized as being ot the same personal information requirements, i.e., as sets of applicable external constraints.

This clause integrates applicable text and rules of Clause 6.5.4.3 Part 5, and Clause F.4 Part 8. It does so in a privacy protection requirements context and from a, more granular, ILCM needs perspective.

A key privacy protection requirement is that of the mandatory destruction of personal information, i.e. as the reverse of records retention. Within an information/records management and archiving context this process requirement of an organization is known as "disposition". Disposition is an authorized action to remove, i.e., alienate, a set of recorded information, from under the control of a Person and thereby extinguishing ownership and accountability70. In the context of this part of ISO/IEC 15944, “Open-edi disposition” is defined as:

Open-edi disposition

70 This is more than “erasing” or “deleting” an SRI in an IT system. From an “evidentiary” requirements perspective, the requirement here is that of “expungement” (= eliminate completely, wipe out, destroy or obliterate an electronic record).


395

3471

34723473

3474

3475347634773478

3479348034813482

34833484348534863487

348834893490349134923493

34943495

349634973498349935003501

3502

396397

CD ISO/IEC 15944-12:2014(E)

process governing the implementation of formally approved records retention, destruction (or expungement) or transfer of recorded information under the control of a Person which are documented in disposition authorities or similar instruments

NOTE Adapted from ISO 15489-1:2001

Within the purpose of this 1st edition of Part 12, only the more basic, i.e., primitive, disposal actions are identified. However, even this limited set covers more than 85% of the statutory requirements and best business practices of most organizations world-wide, and especially those of public administrations.

A key aspect of a “disposition” action is that the specified SRI(s) is removed from the normal and ordinary course of business use of the organization, i.e. “control”. Another key aspect of any disposal action is that no state changes of any kind are allowed to the content value of any SRI(s) which has been “disposed” by the organization.

While the normal default result of a disposition action is the destruction, i.e., expungement of the recorded information, it is not uncommon for other results of a disposition action to occur. Examples of these include:

> the transfer of the “disposed” SRI(s) to an archive (IT system) within the organization, and if so with the same or different access and use controls71;

> the transfer of the “disposed” SRI(s) to an archive (IT system) of (a) an agent of the organization 72; (b) an organization which is a third party to the organization73; or, (c) a totally separate, and largely removed, separate organization;

> the transfer of personal information by an organization for (officially recognized) research purposes 74; along with associated legally supported access and use requirements, including formally accepted (and legally permitted) access and use protocols, specified via formal rules (and associated guidelines) and supported by applicable coded domain as necessary/applicable. Here such transfers may need to incoprate ensure “individual anonymity”

? other?

Rule 062:Where the buyer in a (prospective) business transaction identifies himself/herself as an “individual” is in the “identification phase’ of a business transaction, the (prospective) seller shall inform the (prospective) buyer of any and all ILCM conditions and options as part of the applicable personal information privacy protection requirements and associated rules required to be provided by the buyer as part of the “planning phase’ or at the latest at the end of the “identification phase” and no later of a potential business transaction

71 For example, when an SRI(s) has as disposal action to be assigned the status of “archival”, it is normally physically removed from the DMA of the organization and transferred to the “archival IT system” of the organization at which time access to and use of such SRI(s) fall under the control of the |Archivist”, as an officer of the organization.

72 A common example here is an organizational entity of a public administration, i.e. an organizational entity of a jurisdictional domain government organization which has established a separate and distinct organizational part” as a separate entity governed by separate legislation, regulation (or similar legal instrument) which have as result, from a Part 12, context and perspective, of having its own distinct legal basis and associated rules for access to and use of such associated personal information for all the SRIs which constituting the specified “archival collection” for that natural person which are physically (and logically) maintained as a distinct “collection” the specified archival repository. In addition, it is not an uncommon occurrence for all the personal information (public or private) for a “very important person (VIP” in an organization to be transferred to a new separate organization, or legal entity within an existing organization (e.g., as a “presidential Archive, a Prime Ministerial Archive”, a private archive (including those of a university), etc.

73 An example here is that of a private sector organization disposing of its specified SRIs to a university or a private sector (often non-profit) organization.

74 A primary example here is that of public administrations providing personal information on specified data elements relating to an (identified) individual on a systematic, including, continuous basis to with respect to an officially approved research project


399

350335043505

3506

350735083509

3510351135123513

35143515

35163517

351835193520

35213522352335243525

3526

35273528352935303531353235333534

400401402

403404405406407408409410411

412413

414415416

CD ISO/IEC 15944-12:2014(E)

Rule 063:Where an individual is a buyer to a business transaction, the seller shall specify the disposition action to be taken at the end of the expiry of the record retention period in accordance with privacy protection requirements of the applicable jurisdictional domain as well as those applicable to the nature of the product, service and/or right which is the agreed upon goal of the (to be) actualized, business transaction=, and in particular those SRI retention requirements which are mandatory based on the nature of a the good, service and/or right which is the agreed upon goal of the business transaction

Guideline 063G1:In support of Rule 063, the seller as well as any other parties to the business transaction, (e.g., a regulator, an agent, and/or third party) should use the ISO/IEC 15944-12 Coded Domain 05 “Codes representing disposition of personal information”.

It is also a common and well-established practice for sets of personal information (SPIs) to be scheduled and disposed of via by their transfer to an archive for historical and research purposes. As a matter of fact, many jurisdictional domains have in place legislation (and pursuant regulations) for this purpose (e.g., in the form of a “National Archives Act”, a “Medical research Act’, legally enforced protocols governing access and use of personal information retained as part of longitudinal research, sampling, etc. This is especially so with respect to public administrations.

On the whole , once a SRI is “disposed”, according to the applicable RRDS, the content value(s) are not, cannot be changes, i.e., if state changes were permitted before on the SRI while it was active and being retained, once it is disposed no more state changes are allowed. Where SPIs including SRIs, are not destroyed/expunged as the disposal action, they are transferred to an archive either within the organization itself or to archive of another organization as per (legal/contractual) agreement as so supported by applicable information law.

Certain types of SRI and associated SPIs resulting from completing the goal of a business transaction, may be required to be retained permanently. This so for various types of business transactions which do not have any “post-actualization” requirements. Examples of these include educational records, i.e. those pertaining to completion of high school, a degree at a college or university, sale and transfer of an immovable property, etc.

Rule 061:

Where the disposition action of an SRI, and in particular that of a SPI, is that of transfer to an archive to be retained permanently, i.e., as “permanent” SPI or SRI, no further state changes are allowed for the same.

Guidelines 061G1:

Where the condition of Rule 061 applies, it is advised that one use the ID Cods 11 or 12 in Coded domain 07.

In addition, it can happen that the individual would like to organization to retain its SPIs (and associated SRIs) after the scheduled disposition date/action. This approach is provided for in privacy protection, as a corollary to the organization to be able to ask an individual whether or not PI collected for one purpose, may be used and retained for another purpose.75.

Rule 062:Where the disposition action of an SRI, and in particular that of an SPI, is that to be retained permanently for historical or research purposes, i.e., as a “permanent” SPI or SRI, no further state

75 For example, an organization may have established a dossier on an individual, with the individual’s consent with respect to security clearance, level of competency and qualifications, etc., especially those which include letters of reference, certified copies of key documents, etc. It may very well be that according to applicable privacy protection the p[particular applicable SPI(s) is mandated too be destroyed /expunged two years after last use. requirements, However, the individual concerned, having expended significant resources and time to compile the dossier and have it accepted by the organization, including the organization


418

353535363537353835393540354135423543354435453546354735483549355035513552355335543555355635573558355935603561

3562356335643565

3566

356735683569

3570

357135723573357435753576357735783579358035813582

419420421422423424

CD ISO/IEC 15944-12:2014(E)

changes are allowed, and the SPIs (or SRIs) are subject to ne access and use conditions as well as no longer permitted to be used for decision-making actions with respect to the individual who SPI(s) it is.

Guideline 062G1:Where the condition of Rule 062 applies, it is advised that one use the ID Code 13 in Coded Domain 07.

Table 7 — ISO/IEC 15944-12:07 Codes representing disposition types as actions of personal information (as SPIs)76

ISO/IEC 15944-512;007 Codes representing disposition of personal information (as SPIs)


Source Authority ID

Coded Domain

ID

ID Code


15944-12 07 00 other autre

15944-12 07 01 Disposition as destruction, i.e., total expungement of the applicable SRI(s) by the organization which controls the ILCM aspects of the specified personal information as SPIs.

This not only includes expungement by he seller as the originating institution, i.e. ,Person, ensuing that any of its associated agents and/or third parties, to the relevant business transaction

15944-12 07 02 Disposition as destruction, i.e. total expungement of the applicable SPI (and related) SRIs) and notification to the individual of the disposal action

15944-12 07 10 Disposition via transfer to an archival institution for permanent retention or specified time period retention – General (no further state changes are permitted)

15944-12 07 11 Disposition via transfer to an archival institution which functions as a separate legal entity. (When such a transfer takes place no further state changes are allowed to the SPI(s) and its related SRI(s).

15944-12 07 12 Disposition via transfer to another organizational entity (within the same organization, as an archival record. (When such a transfer takes place no further state changes are allowed to the SPI(s) and its related SRI(s).

15944-12 05 13 transfer to an archival institution (for historical and research purposes).

76 NOTE; Should there be a requirement for additional conditions for the specification of records retention responsibilities these can be added via a Technical Corrigenda to this part of ISO/IEC 15944 or in the next edition of this part of ISO/IEC 15944.


426

358335843585358635873588358935903591

427428429

CD ISO/IEC 15944-12:2014(E)

ISO/IEC 15944-512;007 Codes representing disposition of personal information (as SPIs)


Source Authority ID

Coded Domain

ID

ID Code


(When such a transfer takes place no further state changes are allowed to the SPI(s) and its related SRI(s), and specified (new) access and use conditions apply).

15944-12 05 20 Destruction of the complete SRI, including its SPIs by the organization with return to individual whose personal information it is (e.g., via a printout of the (final) record, an e-mail with a .pdf, file, etc.)

15944-12 05 30 Other?

15944-12 05 98 not known inconnu

15944-12 05 99 not applicable 77 sans objet

77 This would apply to recorded information deemed to be transitory or ephemeral which can be discarded anytime.


431

3592

432

CD ISO/IEC 15944-12:2014(E)

8 Rules governing EDI of personal information between primary ILCM Person, i.e., the seller, and its “agent”, “third party” and/or “regulator”

Project Co-Editors’ Notes

1. CD ballot comments on this Clause are welcome.

2. One question is “Should “primary ILCM Person” be a defined concept?” It links to the fact that someone needs to be identified and be responsible for the maintenance of the “source/original/core” personal information (and SPIs) pertaining to a business transaction. as well as related data synchronization requirements On the whole this is the seller, by default. This is similar to the approach and practices in the financial services sector where there is always a designated financial institution responsible for maintaining and updating a source financial record (=account).of an individual.

8.1 Introduction

This Clause 8 integrates and summarizes existing normative text and rules of Clauses 6.2.3.-> Clause 6.2.6 of Part 1 and of (many) applicable Clauses in Part 8 such as .its Clause 5.3.2 “.Privacy Protection Principle 2: Accountability/

This Clause 8 focuses on EDI aspects of personal information, i.e., criteria and rules which must be complied with by both the primary ILCM Person, i.e., the seller, and a prospective “agent” and or “third party” prior to the seller deciding to use an “agent”, or “third party” as a separate autonomous party, in support of an instantiated business transaction where the buyer is an individual.

The increased use of organizations to outsource some or most of their IT systems including their DMAs and related processing to “cloud-based” services increases the important of ensuring that applicable ILCM aspects of SPIs continue to be supported.78

With respect to the engagement of a third party in a business transaction, it is already stated in Clause 6.2.5 of ISO/IEC 15944-1, that a third party is not an agent of either the buyer or seller but is one who fulfils a specific role or function in the execution of a business transaction as mutually agreed to by the two primary Persons or as a result of applicable external constraints.

8.2 ILCM rules pertaining to use of an “agent”

A seller should not interchange SPIs its agent(s) unless the agent has in place procedures and mechanisms which support privacy protection requirements.

Rule 063:Where a seller uses an agent, the seller shall ensure that before interchanging any personal information with an agent (and its IT System), the seller ensures that the agent (and its IT Systems) support applicable privacy protection requirements.

Guideline 063G1:

Prior to an organization delegating part (or all) of the instantiation of a business transaction to an agent, the organization should obtain (written) assurance of the “agent’s compliance with privacy protection requirements and particularly in the DMAs in the IT systems of the agent.

Rule 064:Where a state change occurs to personal information pertaining to a business transaction, and the seller has interchanged such personal information to its agent(s), the seller shall notify the agent of such a state change(s) and the agent shall acknowledge receipt of the same and verify that it has made the same state change in its IT Systems.

Rule 065:

78 Users and implementers of Parts 12 are urged to familiarize themselves with the text and rules of Part 8, Clause 5.3.2.


434

35933594

3595

3596

359735983599360036013602

3603

360436053606

3607360836093610

361136123613

3614361536163617

3618

361936203621362236233624362536263627

362836293630

3631363236333634363536363637

435

CD ISO/IEC 15944-12:2014(E)

Where a seller uses an agent and interchanges personal information pertaining to a business transaction, the seller shall ensure that the agent in its IT Systems supports applicable records retention and disposal scheduling of that personal information.

Guideline 065G1:A seller can ensure that records retention and disposal requirements pertaining to personal information of a seller in a business transaction are maintained by its agent(s) through the use of state changes.

For example, when the seller destroys, i.e., expunges the personal information as required pertaining to a specified business transaction, the seller could send a state change whereby as the SCs (and IBs) pertaining to that business transaction would be changed in their content value to “000”.

Rule 066:

At the completion of a business transaction, where the buyer is an individual and the seller does not dispose of all related SPIs but instead transfer those SPIs to an archive for add temporal or permanent retention, the seller shall inform the individual of the same along with (new) access and use provisions which may apply, and where applicable the name and coordinates of the agent, i.e., another party, rather than by the organization itself.

8.3 ILCM rules pertaining to use of a “third party”

Rule 067:Where a seller uses a third party, the seller shall ensure that before interchanging any personal information with a third party (and its IT System), the seller ensures that the agent (and its IT Systems) support applicable privacy protection requirements.

A seller should not interchange IBs or SCs with its agent(s) unless the third party has in place procedures and mechanisms which support privacy protection requirements.

Rule 068:Where a state change occurs to personal information pertaining to a business transaction, and the seller has interchanged such personal information to its third party (ies), the seller shall notify the agent of such a state change(s) and the third party shall acknowledge receipt of the same and verify that it has made the same state change in its IT Systems.

Rule 069:Where a seller uses a third party and interchanges personal information pertaining to a business transaction, the seller shall ensure that the third party in its IT Systems supports applicable records retention and disposal scheduling of that personal information.

Guideline 069G1:A seller can ensure that records retention and disposal requirements pertaining to personal information of a seller in a business transaction are maintained by its third party (ies) through the use of state changes.


Rule 070:

At the completion of a business transaction, where the buyer is an individual and the seller does not dispose of all related SPIs but instead transfer those SPIs to an archive for add temporal or permanent retention, the seller shall inform the individual of the same along with (new) access and use provisions which may apply, and where applicable the name and coordinates of the third party, i.e., another party, rather than by the organization itself.


437

363836393640364136423643364436453646364736483649

3650

36513652365336543655

3656

36573658365936603661366236633664

3665366636673668366936703671367236733674367536763677367836793680368136823683

3684

36853686368736883689

CD ISO/IEC 15944-12:2014(E)

8.4 ILCM rules pertaining to involvement of a “regulator”

Rule 069:Where a seller uses a regulator, the seller shall ensure that before interchanging any personal information with a regulator (and its IT System), the seller ensures that the agent (and its IT Systems) support applicable privacy protection requirements.

A seller should not interchange IBs or SCs with its agent(s) unless the agent has in place procedures and mechanisms which support privacy protection requirements.

Rule 070:Where a state change occurs to personal information pertaining to a business transaction, and the seller has interchanged such personal information to a regulator(s), the seller shall notify the agent of such a state change(s) and the agent shall acknowledge receipt of the same and verify that it has made the same state change in its IT Systems.

Rule 071:Where a seller uses a regulator and interchanges personal information pertaining to a business transaction, the seller shall ensure that the regulator in its IT Systems supports applicable records retention and disposal scheduling of that personal information.

Guideline 071G1:A seller can ensure that records retention and disposal requirements pertaining to personal information of a individual in a business transaction are maintained by the regulator(s) through the use of state changes.


It is assumed that a regulator is involved in EDI pertaining to a business transaction due to applicable external constraints which require some or all of the SRIs pertaining to the business transaction to be interchanged with the regulator.


439

3690

36913692369336943695369636973698

3699370037013702370337043705370637073708370937103711371237133714371537163717

371837193720

CD ISO/IEC 15944-12:2014(E)

[THIS PAGE INTENTIONALLY LEFT BLANK]


441

3721

3722

3723

3724

3725

3726

CD ISO/IEC 15944-12:2014(E)

9 Data conversion, data migration, and data synchronization79

Project Co-Editors” Note:

1. This Clause has been added. It may require added text and rules, guidelines, etc. CD ballot comments are welcome.

2. A differentiation is made between (1) “data conversion which deals with/focuses on changes to the “format” and “representation” of the content of an SRI; and, (2) “data migration” which deals with/focuses on changes to the medium of recording, IT system (but not the application software).. Further “data synchronization” is included here but could be placed in another Clause or be made a Clause on its own.

9.1 Introduction

One characteristic of information and communication technologies (ITC) is that many of its components have a relatively short life cycle. Examples include system upgrades, new and different software, data storage devices, data processing approaches, communication devices and protocols, etc. As such it is not an uncommon occurrence that during the lifetime of a business transaction, especially where a business transaction covers several years (including post-actualization), that the organization, in the role of seller, undertakes a data conversion of its recorded information. Similarly during the life time of the recorded information pertaining to a business transaction, it may well happen that the organization undertakes an IT systems upgrade, migration to another IT system, etc., one result being a “data migration”. In either case, it is essential that all ILCM requirements are maintained and in particular those pertaining to personal information.

It is also necessary to ensure “data synchronization” of personal information pertaining to a business transaction, not only within all the DMAs of the IT system of the seller but also where the seller has an agent(s) or the nature of a business transaction involves the participation of .a third party (ies) among the DMAs of the seller and its agents and /or third parties.

9.2 Rules governing data conversion and data migration of personal information

It is necessary to differentiate between changes in the use of ITC by an organization which are (a) of the nature which impact .the format and/or representation of the content of the SRI(s), i.e., “data conversion”; and (b) of the nature which involve moving the SRI(s) from one IT system, data storage medium, etc., without any change to the application software used to manage and/or represent the contents of the SRIs pertaining to a business transaction.

In this context and in support of this e-business, it is necessary to differentiate between the concepts and definitions of “data conversion” and “data migration” as follows:

“data conversion:

process(es) of changing data, i.e., set(s) of recorded information (SRI(s)) from one format or representation to another which maintains the authenticity, integrity, reliability and usability of the SRI(s) as well as relevant ILCM requirements, and especially those of an external constraints nature including privacy protection requirements where the data involves personal information

NOTE: A characteristics of data conversion is a change in the technology used for managing and/or representing the contents of the SRI.”

EXAMPLE: Examples include data conversion resulting from a change in text processing software (e.g. MsWord to HTML), from one database software to another, from a non-data based software to a database based software approach or vice-versa, etc.”

79 The principles and rules presented in this Clause incorporate existing requirements and long established best practices of the established in the records management and archival community with respect to microfilming standards, evidentiary requirements, etc.


443

3727

3728

37293730

3731373237333734

3735

373637373738373937403741374237433744

3745374637473748

3749

3750

37513752375337543755

37563757

3758

3759376037613762

37633764

376537663767

444445446

CD ISO/IEC 15944-12:2014(E)

“data migration:

process(es) of moving existing data, i.e., set(s) of recorded information (SRIs) from one (storage) medium or IT system to another without changes in the application software while also maintaining the authenticity, integrity, reliability, and usability of the SRI(s) as well as relevant ILCM requirements, and especially those of an external constraints nature including privacy protection requirements where the data involves personal information

NOTE: A characteristic of data migration is that of the nature of “moving” the data from one IT system to another independent of its application system which manages the SRIs and their representation.

EXAMPLE: Examples of a data migration include the operation of a “back-up” site either by the organization itself or an agent of the organization.”

Rule 072:

Where an organization undertakes a data conversion of its SRIs pertaining to a business transaction and the SRIs contain personal information, the organization shall ensure that applicable ILCM aspects in support of privacy protection requirements are fully maintained (and carried forward)

Rule 073:Where an organization undertakes a data migration of its IT system(s) to another and the IT system contains SRIs pertaining to a business transaction and the SRIs contain personal information, the organization shall ensure that applicable ILCM aspects in support of privacy protection requirements are fully maintained (and carried forward).

Rule 074:

Whenever an organization undertakes a data conversion or a data migration, it shall maintain the authenticity, integrity, reliability and usability of the SRI(s) as well as relevant ILCM requirements, and especially those of an external constraints nature including privacy protection requirements where the SRIs are of the nature of personal information

Rule 075:

Whenever an organization undertakes a data conversion or a data migration, it shall maintain an audit log/audit trail whose purpose is to provide proof and evidence that the processes involved maintain the authenticity, integrity, and reliability of the contents of the SRIs and in particular those which are of the nature of personal information

Rule 076:

Whenever an organization plans to undertake a data conversion or a data migration pertaining to SRIs which contain personal information, it shall inform its Privacy Protection Officer (PPO) and request its PPO to review and assess whether such data conversion or data migration plans, processes, audit trails/logs, etc., comply with and support applicable privacy protection requirements.

9.3 Rules governing requirements for data synchronization of personal information

The need to ensure “data synchronization” for the Information Bundles (IBs) (and their Semantic Components (SC)) interchanged among Open-edi parties to business transaction has always been assumed, (as it is fundamental and logical conclusion of the application of the six fundamental characteristics of Open-edi, especially from a BOV perspective). Data synchronization is the process of establishing consistency of the content value of any SRI from the source IT system to and among any and all other IT systems , and vice-versa, through ensuring continuous harmonization of data over time, i.e., whenever a state change occurs.


448

3768

3769

37703771377237733774

37753776

37773778

3779

378037813782

37833784378537863787

3788

3789379037913792

3793

3794379537963797

3798

3799380038013802

3803

3804

380538063807380838093810

CD ISO/IEC 15944-12:2014(E)

Within IT systems of an organization, data synchronization can involve a number of tools such as “file synchronization”, “version control”, synchronized distributed systems, mirror computing and back-ups., etc., as well as timestamp synchronization, where all state changes to the content value are marked with time stamps. Data synchronization needs to be well designed and managed in order to prevent “sprawl” of data, ensure that security safeguards are in place, etc.

Not only is ensuring data synchronization among the IT systems of Open-edi parties participating in an business transaction, very important from both a BOV and FSV requirements perspective, where the buyer is an individual, privacy protection requirements make it mandatory.80

Rule 077:

Where the buyer in a business transaction is an individual, an the seller in its IT system uses more than one DMA (or IT systems) to process the SPIs pertaining to the instantiation of the business transaction, the seller shall ensure complete data synchronization among all such DMAs (and their IT system) including those of a back-up nature

Rule 078:

Where Rule 077 applies, and the seller uses an agent, and/or a third party, the seller shall ensure that data synchronization exists, or is enacted, prior to any EDI of SPIs with such parties

Guideline 077G1:

A seller should make data synchronization capabilities for SPIs, as stated in Rules 077 & 078, a pre-condition as part of a contractual agreement before engaging in EDI with any agent, and/or third party with respect to SPIs pertaining to a business transaction.

80 Privacy protection requirements are but one set of information law requiring data synchronization among all parties to a business transaction, Consumer protection law has requirements which are similar in nature. In addition, the nature of the particular good, service, and/or right, which is the goal of the business transaction will also invoke other external constraints, i.e., as based on applicable laws or regulations.


450

38113812381338143815

381638173818

3819

3820382138223823

3824

38253826

3827

382838293830

3831

3832

3833

451452453454

CD ISO/IEC 15944-12:2014(E)

10 Conformance statement81

10.1 Introduction

The first two types of conformance statements presented in Clause 10 below are at the most primitive level. More detailed conformance statement(s) with associated rules and procedures, including those pertaining to verification are expected to be developed either as Addendum(s) to this 1st edition or as part of the development of a 2nd edition for this part of ISO/IEC 15944.

Clause 10 is modelled on that found in Clause 6 in the 3rd edition for ISO/IEC 14662.

There are two different categories of conformance statements for this part of ISO/IEC 15944; namely:

(a) Category A – ISO/IEC 14662 Open-edi Reference Model; and, ISO/IEC 15944 compliance; and,

(b) Category B – ISO/IEC 15944-12 conformance only. These basically apply for use by a seller or regulator.

The reason for these two categories is to permit users and implementers of ISO/IEC 15944-8 to be conformant to its requirements without using the Open-edi modelling constructs as well as registration of Open-edi scenarios and scenario components as re-usable business objects.

In addition, there are conformance statements for sue by “agents” and “third parties”. {See further Clause 10.4 below}

10.2 Conformance to the ISO/IEC 14662 Open-edi Reference Model and the multipart ISO/IEC 15944 eBusiness standard

Any user/implementer conformance statement of this nature shall state:

(a) that it is conformant to the BOV class of standards of ISO/IEC 14662;

(b) the list of the basic concepts of the ISO/IEC Open-edi Reference Model and ISO/IEC eBusiness (BOV standards) as stated in the ISO/IEC 15944-7 eBusiness Vocabulary; and,

(c) whether or not it has any Open-edi compliant scenarios and scenario components registered using ISO/IEC 15944-2.

10.3 Conformance to ISO/IEC 15944-12

Any user/implementer conformance statement of this nature shall state:

“The existence, management, use, and/or interchange of personal information, i.e., as SPIs, by XYZ [insert name of organization or public administration] with any other party (to the business transaction) is conformant and consistent with the eleven Privacy Protection principles and associated information life cycle management (ILCM) requirements as stated in ISO/IEC 15944-12 definitions, its concepts, rules, guidelines and related requirements”.

10.4 Conformance by agents and third parties to ISO/IEC 15944-12

It is the seller in a business transaction who is responsible for ILCM of personal information pertaining to a business transaction where the buyer is an individual.

81 Similar to that of Clause 13, Part 8 but with added sub-clauses re: conformance statement for “agent”, “third party”, and “regulator”.


456

3834

3835

3836383738383839

3840

3841

3842

3843

384438453846

38473848

38493850

3851

3852

38533854

38553856

3857

3858

38593860386138623863

3864

38653866

457458

459

CD ISO/IEC 15944-12:2014(E)

This means that such personal information maintained under the control of the organization acting in the role of seller, including as ILLCM of the organizations’ IT Systems (and related DMAs). Where and when a (seller) organization decides to use an agent or a third party in the fulfillment of a business transaction containing personal information, the seller organization shall ensure that any agent or third party with which it interchanges personal information is “conformant” with ISO/IEC 15944-12.

Rule nnn:An organization, in the role of seller, in a business transaction where the buyer is an individual and the business transaction contains personal information, the organization shall ensure that before interchanges of any such personal information the agent or third party that such an agent or third party is conformant with applicable privacy protection requirements.

Conformance statement for use by parties who function as agents or third parties to a seller organization in a business transaction where the buyer is an individual and the business transaction involves personal information.

“Organization “XYZ” [insert name of organization] acting as an agent or third party [indicate which] to organization “ABC” [insert name of organization of the seller in a business transaction] hereby states that it is conformant in its IT systems with respect to the content value(s) of any and all SPIs pertaining any EDI of such SPIs with the eleven Privacy Protection principles and associated information life cycle management (ILCM) requirements as stated as in ISO/IEC 15944-12 definitions, its concepts, rules, and related requirements”.


461

38673868386938703871

3872387338743875387638773878387938803881388238833884388538863887

3888

CD ISO/IEC 15944-12:2014(E)

Annex A(normative)

Consolidated list of terms and definitions with cultural adaptability: ISO English and ISO French language equivalency

[similar to Annex A, of Part 8, 9 and 20, i.e., only for added new definitions and terms]

A.1 Introduction

This part of ISO/IEC 15944 maximizes the use of existing standards where and whenever possible including relevant and applicable existing terms and definitions. These are presented in Clause 3 above. This Annex A contains only those new concepts and their definitions introduced in this part of ISO/IEC 15944, i.e. as ISO English and ISO French language HIEs.

The ISO/IEC 15944-7 “eBusiness Vocabulary” (a “freely available ISO standard”) in its normative Annex E already contains the consolidated ISO English and ISO French language equivalents for all the other concepts and definitions found in Clause 3 of this document ISO/IEC 15944-7 also contains ISO Russian and ISO Chinese langue HIEs for all the concepts and their definitions. It is anticipated that the contents of Annex A.5 below will serve as the basis for an Addendum to ISO/IEC 15944-7 and that this Addendum will also contain the ISO Russian and ISO Chinese HIEs for the contents of Annex A.5 below.

A.2 ISO English and ISO French

This part of ISO/IEC 15944 recognizes that the use of English and French as natural languages is not uniform or harmonized globally. (Other examples include use of Arabic, German, Portuguese, Russian, Spanish, etc., as natural languages in various jurisdictional domains).

Consequently, the terms "ISO English" and "ISO French" are used here to indicate the ISO's specialized use of English and French as natural languages in the specific context of international standardization, i.e., as a "special language".

A.3 Cultural adaptability and quality control

ISO/IEC JTC1 has "cultural adaptability" as the third strategic direction which all standards development work should support. The two other existing strategic directions are "portability" and "interoperability". Not all ISO/IEC JTC1 standards are being provided in more than one language, i.e., in addition to "ISO English," in part due to resource constraints.

Terms and definitions are an essential part of a standard. This Annex serves to support the "cultural adaptability" aspects of standards as required by ISO/IEC JTC1. Its purpose is to ensure that if, for whatever reason, an ISO/IEC JTC1 standard is developed in one ISO/IEC "official" language only, at the minimum the terms and definitions are made available in more than one language.82

A key benefit of translating terms and definitions is that such work in providing bilingual/multilingual equivalency:

should be considered a "quality control check" in that establishing an equivalency in another language ferrets out "hidden" ambiguities in the source language. Often it is only in the translation that

82 Other ISO/IEC member bodies are encouraged to provide bilingual/multilingual equivalencies of terms/definitions for the language(s) in use in their countries.


463

38893890389138923893

3894

3895

3896389738983899

390039013902390339043905

3906

390739083909

391039113912

3913

3914391539163917

3918391939203921

39223923

39243925

464465

CD ISO/IEC 15944-12:2014(E)

ambiguities in the meaning, i.e., semantics, of the term/definition are discovered. Ensuring bilingual/multilingual equivalency of terms/definition should thus be considered akin to a minimum "ISO 9000-like" quality control check; and,

is considered a key element in the widespread adoption and use of standards world-wide, especially by users of this part of ISO/IEC 15944 who include those in various industry sectors, within a legal perspective, policy makers and consumer representatives, other standards developers, IT hardware and service providers, etc.

A.4 Organization of Annex A – Consolidated list in matrix form

The terms/definitions are organized in matrix form in alphabetical order (English language). The columns in the matrix are as follows:

Table A.1 — Columns in Table A.2Col. No. Use

IT-Interface – Identification

1 Clause 3 ID (ID definition as per ISO/IEC 15944-12 Clause 3)

2 Source. International standard referenced or that of ISO/IEC 15944-12 itself.

Human Interface Equivalent (HIE) Components

3 ISO English Language – Term

4 Gender of ISO English Language Term+

5 ISO English Language – Definition

6 ISO French Language - Term *

7 Gender of the ISO French language Term+

8 ISO French Language - Definition

The primary reason for organizing the columns in this order is to facilitate the addition of equivalent terms/definitions in other languages as added sets of paired columns, (e.g., Spanish, Japanese, German, Russian, Chinese, etc)83.

+ The codes representing gender of terms in natural languages are those found in Clause 6.2.6 in ISO/IEC 15944-5 “Gender and official, languages”, and Table 1 – “ISO/IEC 15944-5:01 Codes representing grammatical gender in natural languages”;

ISO English, in Column 4, the gender code = “99” since the English language does not have gender in its grammar; and,

ISO French, in Column 7, the gender codes are 01 = masculine, 02 = feminine and 03 = neuter

* The use of [French language equivalent required] in Colum (8) means that for these terms and definitions, ISO/IEC 20016-1 itself will be providing the ISO French language equivalent before the FDIS stage.

83 See further Part 7 “eBusiness Vocabulary” of ISO/IEC 15944 for an implementation of this approach.


467

392639273928

3929393039313932

3933

39343935

3936

3937

393839393940

394139423943

39443945

3946

39473948

468

CD ISO/IEC 15944-12:2014(E)

A.5 List of added Part 12 terms and definitions with cultural adaptability: ISO English and ISO French

The following Table A.2 contains entries for those definitions and terms found in Clause 3 which are new tothe existing set of ISO/IEC 14662 Open-edi and the multipart series of ISO/IEC 15944 e-Business family of standards. This is because Part 7 of ISO/IEC 15944 “..eBusiness Vocabulary” already contains all the concept/definitions and associated terms ofound in the existing ISO/IEC 14662 standard and ISO/IEC 15944 family of standards, i..e, and with their ISO English, ISO French, ISO Russian and ISO Chinese equivalents.

Table A.2 — List of added Part 12 terms and definitions with cultural adaptability of: ISO English and ISO French language equivalency

IT-Interface Human Interface Equivalent (HIE) Components

Identification ISO English ISO French

eBus. Vocab.

ID

SourceRef. ID

Term G Definition Term G Definition

(1) (2) (3) (4) (5) (6) (7) (8)

DXXX ISO/IEC 15944-12 :2014 (3.5)

audit trail 99 chronological record of IT system activities that is sufficient to enable the reconstruction, reviewing and examination of the sequence of environments and activities surrounding or leading to an operation, a procedure, or an event pertaining to sets of recorded information (SRIs) in a business transaction through all its processes, i.e., from planning to the end of post-actualization

DXXX ISO/IEC 15944-12 :2014 (3.8)

back-up copy 99 copy that is any of the following: a) additional resource or duplicate copy of data on different a storage medium stored off-line for emergency purposes; b) disk, tape or other machine-readable copy of a data or program file; c) data or program file recorded and stored off-line for emergency or archival purposes; d) record that preserves the evidence and information it contains if the original is not available


470

3949

39503951

39523953395439553956395739583959

CD ISO/IEC 15944-12:2014(E)



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

DXXX ISO/IEC 15944-12 :2014 (3.33)

data conversion

99 process(es) of changing data, i.e., set(s) of recorded information (SRI(s)) from one format or representation to another which maintains the authenticity, integrity, reliability and useability of the SRI(s) as well as relevant ILCM requirements, and especially those of an external constraints nature including privacy protection requirements where the data involves personal information

NOTE: A characteristics of data conversion is a change in the technology used for managing and/or representing the contents of the SRI.”.

EXAMPLE: Examples include data conversion resulting from a change in text processing software (e.g. MsWord to HTML), from one database software to another, from a non-data based software to a database based software approach or vice-versa, etc

DXXX ISO/IEC 15944-12 :2014 (3.36)

data migration

99 moving sets of recorded information from one IT System or device to another, as required by changes in an IT System configuration or as requested by the user, while assuring that the data will remain


472

CD ISO/IEC 15944-12:2014(E)



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

addressable and that data integrity will be maintained in the new environment

DXXX ISO/IEC 15944-12 :2014 (3.39)

data synchronization (in business transaction)

99 process of continuous harmonization of a set(s) of recorded information among all the parties to a business transaction to ensure that the content value(s) of the current state of such a set(s) of recorded information is the same in the IT systems of all the participating parties

NOTE Adapted from GS1 Global Traceability Standard (GDSN) Glossary.

DXXX ISO/IEC 15944-12 :2014 (3.48)

electronic signature

99 signature that consists of one or more letters, characters, numbers or other symbols in digital form incorporated in, attached to or associated with a particular digital/electronic set of recorded information (SRI)

NOTE Adapted from PIPEDA, Part 2, section 31(1); CAN/CGSB-72.34-2005, 3.28.

DXXX ISO/IEC 15944-12 :2014 (3.62)

individual anonymity

99 state of not knowing the identity or not having any recording of personal information on or about an individual as a buyer by the seller or regulator, (or any other party) to a business transaction


474

CD ISO/IEC 15944-12:2014(E)



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

DXXX ISO/IEC 15944-12 :2014 (3.63)

individual authentication

99 provision of the assurance of a recognized individual identity (rii) sufficient for the purpose of the business transaction

DXXX ISO/IEC 15944-12 :2014 (3.148)

set of personal information (SPI)

99 set of recorded information (SRI) which is of the nature of or contains personal information

DXXX ISO/IEC 15944-12 :2014 (3.152)

SRI destruction

99 process of eliminating or deleting sets of recorded information, beyond any possible reconstruction

DXXX ISO/IEC 15944-12 :2014 (3.153)

SRI expungement

99 process of eliminating completely, wiping out, destroying or obliterating completely a physical or (electronic) digital set of recorded information (SRI) without so that there can be no reconstruction

DXXX ISO/IEC 15944-12 :2014 (3.154)

SRI integrity 99 (of records) reliability and trustworthiness of SRIs as copies, duplicates or comparable representations of SRIs; and reliability and trustworthiness of the IT system in which it was recorded or stored to produce reliable and trustworthy copies and duplicates of SRIs

NOTE 1 SRI integrity is important in the electronic records provisions of the evidence acts in the phrases “the integrity of the electronic records system” and “the integrity of the electronic


476

CD ISO/IEC 15944-12:2014(E)



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

record.” However, the term integrity is not defined. In the absence of a statutory or judicially created definition, the principles of this standard shall serve as an operational definition of the word integrity used in the evidence acts.

NOTE 2 Certain evidence acts provide that the integrity of the electronic record may be proved by evidence of reliable encryption.

DXXX ISO/IEC 15944-12 :2014 (3.155)

SRI life cycle 99 stages in the life cycle of a SRI include but are not limited to its planning, creation and organization; the receipt and capture of data; the retrieval, processing, dissemination and distribution of a SRI; its storage, maintenance and protection; its archival preservation or destruction or expungement

DXXX ISO/IEC 15944-12 :2014 (3.156)

SRI migration 99 act of moving a SRI from one IT system to another Person within an organization or public administration while maintaining the authenticity, integrity, reliability and usability of the SRI

DXXX ISO/IEC 15944-12 :2014 (3.157)

SRI retention period

99 specified period of time that SRIs are kept by a Person in order to meet operational, legal, regulatory, fiscal or other requirements


478

CD ISO/IEC 15944-12:2014(E)



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

DXXX ISO/IEC 15944-12 :2014 (3.162)

transitory record

99 SRI that is required only for a very limited and specified (retention period) time to ensure the completion of a routine action or the preparation of a subsequent SRI


The primary reason for organizing the columns in this order is to facilitate the addition of equivalent terms/definitions in other languages as added sets of paired columns, (e.g., Spanish, Japanese, German, Russian, Chinese, etc)84.

+ The codes representing gender of terms in natural languages are those found in Clause 6.2.6 in ISO/IEC 15944-5 “Gender, and official, de facto, or LRL languages”, and especially its Table 1 – “ISO/IEC 15944-5:01 “Codes representing gender and official languages”.

84 See further ISO/IEC 15944-7 “eBusiness Vocabulary” of ISO/IEC 15944 for an implementation of this approach.


480

3960

3961

3962

396339643965

396639673968

481

CD ISO/IEC 15944-12:2014(E)

Annex B(normative)

Consolidated set of rules in existing Parts of ISO/IEC 15944 of particular relevance to privacy protection requirements as external constraints on business transactions which apply to personal information in an ILCM

requirements context

[similar in nature to Annex B, Part 8]

B.1 Introduction

This part of ISO/IEC 15944 already makes extensive use of relevant rules and guidelines as found in referenced Clauses in ISO/IEC 15944-1 and adapts them in a privacy protection requirements context. Similarly relevant rules and guidelines found in ISO/IEC 15944-2, ISO/IEC 15944-4, and ISO/IEC 15944-5 have been adapted or serve as the basis for rules of this nature required to support privacy protection requirements.

The purpose of Annex B is to provide a consolidated presentation of all the rules in the existing parts of ISO/IEC 15944 for the scoping and specification of Open-edi scenarios and their components which pertain to external constraints relevant to privacy protection requirements. Jurisdictional domains are the primary source of external constraints. The existing parts of ISO/IEC 15944 address, in an integrated manner, the already many of the requirements arising pertaining to specifying common external constraints of jurisdictional domains which are relevant to privacy protection requirements either in a generic or specific manner.

Only the Rules themselves are presented here. For related text, as well as associated Guidelines, where applicable, see the relevant Clauses in the current editions of Parts of ISO/IEC 15944 identified in the matrixes below.

Also there are parts of ISO/IEC 15944 which do not contain any rules (or guidelines) of relevance to privacy protection requirements. These are:

1) ISO/IEC 15944-4

The primary reason for this is that ISO/IEC 15944-4 focuses on “accounting and economic ontology” at the Person level as parties to a business transaction, i.e., in their roles as buyers, sellers, and/or regulators.

2) ISO/IEC 15944-6

ISO/IEC 15944-6 is of the nature of an ISO/IEC “technical report (TR)” providing a “Technical Introduction to e-Business Modelling. As such, it contains no rules.

B.2 Organization of Annex B: Consolidated list in matrix form

The rules and associated references are presented in matrix form. The rules are presented in the numeric order in which they are presented in ISO/IEC 15944-1. The columns in the matrix are as follows:


483

3969397039713972397339743975

3976

3977

39783979398039813982

3983398439853986398739883989

399039913992

39933994

3995

39963997

3998

39994000

4001

40024003

4004

4005

CD ISO/IEC 15944-12:2014(E)

Col. No Use

1 Number of Rule as per ISO/IEC 15944-1.

2 Clause ID in ISO/IEC 15944-1 of which the Rule is part

3 Rule Statement as per ISO/IEC 15944-1

Note: Only text of the Rule itself is presented. For associated guidelines, requirements and text see the relevant clauses in that part of ISO/IEC 15944. All Parts of ISO/IEC 15944 are ISO “freely available standards”.

B.3 Consolidated list of rules in ISO/IEC 15944-1 pertaining to external constraints relevant to supporting privacy protection requirements

Rule No. Clause ID Rule Statement

(1) (2) (3)

3 6.1.3 In (electronic) business transactions, all commitments shall be stated explicitly and unambiguously and be understood by all Persons involved in a business transaction.

13 6.2.2 The level of unambiguity, i.e., certainty/reliability of a persona and resulting identification of the Person identity used by a Person shall be appropriate to the goal of the business transaction.

15 6.2.2 Business transactions having different goals may allow a Person to use the same persona and its associated identification schema (including resulting identifiers), while others may prohibit this.

27 6.2.4 Unless bound by external constraints, "buyers" and "sellers" as Persons are free to undertake any business transaction involving any good, service, and/or right they mutually agree to.

28 6.2.4 External constraints governing rules and practices of "buyers" and "sellers" in business transactions apply either to Persons (undifferentiated) or distinguish among "individuals", "organizations", and "public administrations".

29 6.2.5 Rights or obligations arising from commitments in a business transaction shall be fulfilled either directly by the Person as the end entity or by an agent acting on its behalf.

30 6.2.5 The ability to delegate a role to an agent shall be explicitly stated. If constraints must be satisfied before such delegation can take place they shall be explicitly stated.

31 6.2.5 Where delegation of a role cannot take place this shall be explicitly stated.

32 6.2.5 A business transaction takes place between two Persons. Other Persons, i.e., third parties, may fulfil specified role(s) or functions(s) on mutual agreement or as a result of external constraints.


485

4006

4007

40084009

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

33 6.2.6 External constraints exist on the provisioning of goods and services and the behaviour of Persons as players in business transactions including those provided via electronic commerce.

34 6.2.7 From a minimal external constraints perspective, the three basic sub-types of Persons as role players in any business scenario are:

A. individual,

B. organization, and

C. public administration.

35 6.2.7 A legal (or artificial) Person consists of one or more natural persons and/or one or more other legal persons. A unifying term and common concept used internationally is the standard term "organization" as the collective common term for all the different ways legal (or artificial) persons can be composed and be recognized in various jurisdictions.

38 6.2.8 From a minimal external constraints perspective, a common set of constraints on a business transaction where the buyer is an individual are those of a consumer protection nature.

39 6.3.1 Conceptually a business transaction can be considered to be constructed from a set of fundamental activities. They are planning, identification, negotiation, actualization and post-actualization.

40 6.3.1 The five fundamental activities may take place in any order.

44 6.4.1 Electronic business transactions require "recorded information".

47 6.4.2 The definition of "data", and related information technology terms and definitions found in this part of ISO/IEC 15944 shall able to be mapped into legal frameworks.

48 6.4.2 Standards development work in support of electronic business transactions shall incorporate and support data granularity requirements. The level of granularity reflects the degree of detail appropriate to the level of certainty required in the data being interchanged among the parties participating in a business transaction.

49 6.5.1 Open-edi scenarios and Information Bundles shall therefore be capable of reflecting constraints to be applied which may be as a result of:

- commitments among parties, i.e., as internal constraints;

- external constraints.

50 7.2 The requirement for an Open-edi scenario to incorporate external constraints on a business transaction shall be stated at the outset.

51 7.2 It is necessary to state whether the Open-edi Parties in the business transaction being modelled are (a) Persons in general, i.e., undifferentiated; or (b) differentiated among categories of Persons, i.e., subtypes, as individuals, organizations and public administration.


487

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

57 7.2 If the business transaction being modelled through an Open-edi scenario incorporates external constraints which impact FSV demands on Open-edi Support Infrastructure (OeSI), these shall be specified.

66 8.3.2.4 The set of Roles applicable to the scenario shall be specified and referenced through their Role Identifiers.

67 8.3.2.4 One shall state which roles are mandatory, conditional, or mandatory subject to a conditional.

68 8.3.2.4 Where applicable, constraints on the same Open-edi Party playing more than one of the roles in the set of roles applicable to the OeS shall be specified

70 8.3.2.5 If applicable, one should state which IBs are mandatory, conditional, or mandatory subject to a conditional.

71 8.3.2.5 Where applicable, constraints on IBs pertaining to roles in the OeS shall be specified.

72 8.3.2.6 The business requirements, rules and practices applicable at the scenario level shall be specified. This specification shall be stated at a level of detail to ensure that there is no ambiguity in the commitments among Open-edi Parties at the scenario level.

73 8.3.2.6 Business constraints, if any at the scenario level, pertaining to Open-edi Parties and scenario components shall be specified. All of these shall be accounted for in scenario components, i.e., roles and/or Information Bundles.

74 8.3.2.7 Requirements or constraints arising from applicable laws or regulations at the scenario level shall be explicitly stated including the source jurisdictions.

75 8.3.2.7 Where multiple laws and regulations apply at the scenario level, the constraints applicable shall be integrated.

101 8.4.2.5 Constraints, if any, on an Open-edi Party being able to play a role shall be specified.

103 8.4.2.7 Any external constraints arising from laws or regulations to any aspect of the role and its attributes shall be identified and stated including the reference/source of the applicable law or regulation, i.e., qualifications for a role, prescribed behaviour, restrictions on the delegation of a role, etc.

135 8.5.2.4 Any business rules controlling content of an IB shall be identified and the nature and functioning of these rules explicitly stated. The source of such business rules shall also be referenced.

136 8.5.2.5 Any external constraints arising from laws and regulations governing the content of an IB shall be identified, the requirements explicitly stated and the source referenced.

137 8.5.2.5 Any IB created to meet a requirement of external constraints of the nature of laws and regulations should be so identified, the contents of the IB explicitly defined, at the level of granularity required, and the source law/regulation referenced.

140 8.5.2.8 Requirements for retention of recorded information for an IB, if any, shall be


489

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

specified as well as which OePs involved in the associated role(s) have the primary responsibility for retaining this recorded information

141 8.5.2.9 Requirements arising from laws or regulations for the retention of recorded information applicable to the IB, if any, shall be explicitly stated and the source(s) referenced.

146 8.5.5.1 A Semantic Component can be a single (simple) data element, a composite data element, or a data structure, (e.g., a set of data elements which interwork in order to ensure semantic completeness and ensure the required unambiguousness).

147 8.5.5.1 A Semantic Component shall be a component of at least one Information Bundle when exchanged among Open-edi Parties.

153 8.5.5.2.2 A SC name is the designation of the SC ID by a linguistic expression. More than one SC name as equivalent linguistic expressions may be associated with an SC ID, (e.g., as "aliases").

B.4 Consolidated list of rules in ISO/IEC 15944-2 pertaining to external constraints of relevance to supporting privacy protection requirements


(1) (2) (3)

2 5.3 The registration of any scenario or scenario component shall be capable of supporting multilingual semantic equivalents at the human interface.

3 5.3 On the while, and from an internal constraints only based perspective, parties to a business transaction are free to choose the language(s) to be used.

9 6.5 Only valid, superseded, and retired OeRIs shall be exposed when the contents of a register are made available to the public.



(1) (2) (3)

002 5.2.1 Unless a particular external constraint governing the commitment made requires that it be made in a specific jurisdictional domain, Persons are free to choose the jurisdictional domain in which the business transaction is (deemed) to take place

003 5.2.3 Depending on the nature of the goods, services or rights being provided (as the goal of the business transaction being modelled), applicable external constraints may specify and require the transaction to be enacted in a specified jurisdictional


491

4010

40114012

4013

40144015

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

domain

004 5.2.3 Within a particular jurisdictional domain, it may be required to reference a specific act or regulation as well as require the participation (in some form) of a regulator.

005 5.2.3 For any business transaction (or part thereof) which involves external constraint(s), the role of regulator(s) shall be included and modelled as part of the scenario and scenario components.

006 5.3 The primary source of a regulator having the authority to prescribe external constraints is that of the nature of a jurisdictional domain.

008 5.4 When modelling a business transaction, where one includes external constraints, it is necessary to differentiate among the three common sub-types of Person, namely "individual", "organization" and "public administration". A jurisdictional domain shall be modelled as a "public administration".

016 5.7 An external constraint may specify the "explicitly shared goal" of a business transaction as a whole.

017 6.2.1 It is vital that all parties to a business transaction have a complete and unambiguous understanding, i.e., level of certainty and explicitness required, to ensure that the commitments being entered into are fully and completely understood and agreed upon by all the parties involved.

018 6.2.1 Persons, whether as “individuals” or as “organization Persons” acting on behalf of their organization or public administration (on whose behalf they are qualified and authorized as role players to make commitments), must agree to the language(s) to be utilized in a business transaction, i.e., by all the parties involved, in order to ensure that the semantics of the commitments being entered into are completely understood by all parties involved.

019 6.2.1 Choice of use of language(s) is governed by three primary factors:

(1) seller, i.e., supplier choice;

(2) buyer, i.e., user, demands; and/or;

(3) regulator, i.e., requirements of a jurisdictional domain.

020 6.2.1 In business transactions which are modelled and registered as scenarios and scenario components which involve internal constraints only, the parties involved are free to choose and decide among themselves the natural language(s) to be used for the recorded information in a business transaction.

021 6.2.1 In modelling a business transaction which involves internal constraints only, it is advisable that parties concerned use the 3-alpha language code(s) as stated in ISO 639-2/T code set for the identification of the language(s) to be used and/or supported.

022 6.2.2 In business transactions which are modelled (and registered) as scenarios and scenario components, i.e., as business objects, which involve external constraints, one shall specify the official language(s) to be supported based on the requirements of the jurisdictional domain(s) which is the source(s) for these external constraints.


493

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

023 6.2.2 In modelling a business transaction (or parts thereof) and registering them as re-useable business objects involving external constraints, these shall be modelled in a manner which supports the language requirements, including a multilingual approach, of the source of such external constraint(s), (e.g., jurisdictional domain(s)).

024 6.2.2 A jurisdictional domain has either an official language(s) or a de facto language.

025 6.2.2 It is for a jurisdictional domain to decide whether or not it has an official language. If not, it will have a de facto language.

026 6.2.2 A law or regulation of a jurisdictional domain may require the use of or the ability to support a specific language within a particular context, i.e., as a “legally recognized language (LRN)”.

027 6.2.3 Where a jurisdictional domain has more than one official language, Persons as suppliers shall be capable of communicating with buyers (particularly as individuals) in any one of the official languages of that jurisdictional domain.

028 6.2.4 A jurisdictional domain may have either one or more official languages and, if not, may have only one “de facto language”.

029 6.2.6 In order to be able to specify the gender of a noun or term used as may be required based on the official (or de facto) language utilized, the set of "Codes Representing Gender in Natural Languages" shall be used in the modelling of a business transaction and registration of any related business object.

030 6.2.6 Where the official language (or de facto language) of a jurisdictional domain has no gender this shall be stated.

031 6.2.7 Where a jurisdictional domain has more than one official language, human interface equivalents (HIEs) are required in each official language in order to ensure unambiguity in the semantics of the commitments made.

032 6.2.7 It is up to a jurisdictional domain to establish HIEs in its official language(s) where these are part of the specification and implementation of external constraints.

033 6.2.8 In order to ensure unambiguity in the use of a natural language in business transactions it is necessary to specify the jurisdictional domain for the varied forms of that natural language to be utilized using common standard default conventions for the unambiguous identification, interworkings and referencing of combinations of codes representing countries, language and currencies.

034 6.2.8 In modelling a business transaction through scenarios and scenario components which involve external constraints and for which the Source Authority is a UN member state (or an administrative sub-division of the same), it is advisable that all parties concerned use the 3-digit numeric country code plus the 3-alpha language code, and in this order.

035 6.2.9 The official language of a treaty-based international organization recognized as having primary competence in a specific sector can override the official language requirements of the jurisdictional domains of UN member states.

036 6.2.9 In modelling a business transaction (or parts thereof) as scenarios and scenario components, and registering them as re-useable business objects involving


495

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

internal constraints, these should be modelled in a manner which supports the language(s) of the source authorities referenced and utilized in such referenced specifications.

037 6.3.2 A common set of external constraints of a jurisdictional domain on a business transaction, where the buyer is an individual, are those of a consumer protection nature.

038 6.3.2 Where the buyer is an individual, the seller shall ascertain that the individual has the age qualification required by the jurisdictional domain to be able to be involved in and make commitments pertaining to the good, service and/or right being offered in the proposed business transaction.

039 6.3.2 A seller shall ensure that where its intends to sell a good, service and/or right to a buyer as an individual that consumer protection requirements of the applicable jurisdictional domain of the buyer are supported.

040 A common set of external constraints of a jurisdictional domain on a business transaction, where the buyer is an individual, are those of a privacy protection nature.

041 6.4 When an external constraint of a jurisdictional domain requires use of a specific identification system with respect to a recognized Person identity (rPi) and/or with respect to a good, service and/or right, pertaining to the business transaction being modelled as scenarios and scenario components as re-useable business objects, such modelling shall be done in a manner which supports the requirement of the identification system referenced.

042 6.5 Where an external constraint of a jurisdictional domain requires the use of a specific classification system and the same forms part of the business transaction being modelled, or as an identifiable and registered scenario component, i.e., as a re-useable business object, this shall be done in a manner which supports the requirements of the classification system being referenced.

043 6.5 Where a classification system uses identifiers for each distinct entry, (with the associated semantics in that classification system), such identifiers (or "composite identifiers") shall be utilized as well as their structure in modelling a scenario or scenario component.

044 6.6.2.2 Any external constraint of a jurisdictional domain which governs, limits or qualifies a Person, a Person sub-type, any role qualification, etc., with respect to a business transaction of a particular nature shall be specified unambiguously and in a manner so as to be able to be modelled using an OeDT.

045 6.6.2.3 A LRN may have both a long, i.e., complete, persona, or a short, i.e., truncated, persona.

046 6.6.2.3 The formation of a LRN of an incorporated organization, i.e., a legal person, is governed by the rules of the jurisdictional domain in which it is incorporated, registered and recognized as such.

047 6.6.2.3 The establishment and representation of name(s) of a public administration, i.e., its personae, is determined by the jurisdictional domain of which it is part.

048 6.6.2.3 The personae of an individual shall include at least one LRN in order to confirm the


497

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

existence of that individual as a "natural person", i.e., the birth certificate name (or a similar name).

049 6.6.2.3 The establishment and representation of an individual, i.e., its personae, is determined by the role and context of that individual within a jurisdictional domain, i.e., as controlled by a regulator and the associated public administration.

050 6.6.3 Conceptually a business transaction can be considered to be constructed from a set of fundamental activities. They are planning, identification, negotiation, actualization and post-actualization.

051 6.6.3 The five fundamental activities may take place in any order.

052 6.6.3 A Person may terminate a business transaction by any agreed method of conclusion.

053 6.6.3 The five fundamental sets of activities may be completed in a single continuous interactive dialogue or through multiple sets of interactions among buyer and seller and possibly involve agents or third parties as well.

054 6.6.4.3 An instantiated business transaction shall have one or more IB or SC for which no state changes are permitted. One of these is to serve as the transaction ID number, i.e., a business transaction identifier (BTI), for the instantiated business transaction.

055 6.6.4.5 In the modelling of a business transaction, through a scenario and scenario components, and/or registering them as referenceable and reusable business objects, one shall specify the temporal schema, i.e., date/time referencing system, if one is utilized as well as the level of granularity supported.

056 6.6.4.5 Any calendar, date/time referenced, etc., identified and referenced shall be one based on (or linkable to) an ISO 8601 or ISO 19108 and conformant to the requirements of either one of these two standards.

057 66.4. Where the Gregorian calendar is utilized, the ISO 8601 compliant representation of

1) a date in a YYYY-MM-DD format ; and,

2) a time of day in an hh:mm:ss format ,

shall be used.

058 6.6.4.5 Where from an IT-system perspective and/or financial system needs perspective, a “GPS calendar clock” or an “atomic clock” is to be used, this shall be specified.

059 7.1 The basic rules for the formation and identification of jurisdictional domains are governed by the Charter of the United Nations and more specifically by the Vienna Convention on the Law of Treaties.

060 7.2 UN member states as peer jurisdictional domains are to be referenced by their 3-digit numeric code as stated by the UN statistical system.

061 7.2 Where the 3-digit numeric code of a UN member state is to be utilized in conjunction with, i.e. required to interwork with (1) a code representing an official (or de facto) language of that jurisdictional domain; (2) a code representing a currency recognized for use in that jurisdictional domain; and/or, (3) both (1) and


499

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

(2), one shall use the standard default conventions for the identification, interworking and referencing of combinations of codes representing countries, languages and currencies as provided in Annex D.

063 7.3.2 Two jurisdictional domains, of whatever category, can bind themselves in a bilateral treaty, to form a new common jurisdictional domain, either generally or as pertaining to a specified set of goods, services and/or rights

064 7.3.3 Three or more jurisdictional domains, of whatever category, can bind themselves via a plurilateral treaty to form a new jurisdictional domain, either generally or as pertaining to a specified set of goods, services and/or rights.

065 7.3.4 Three or more jurisdictional domains can bind themselves via a multilateral treaty to form a new jurisdictional domain either generally or as pertaining to a specified set of goods, services an/or rights.

066 7.8.2 In order to ensure unambiguous identification in referencing UN member states, the 3-digit numeric codes of the UN Statistical Division representing the UN member state shall be utilized as its primary identifier.

070 8.2 It is important in scoping an Open-edi Scenario to specify at the outset whether or not external constraints apply to the business transaction being modelled.


ISO/IEC 15944-7 titled “…eBusiness Vocabulary” provides the ISO English and ISO French language equivalents, i.e., as HIEs, for all the definitions of concepts (and associated terms) found in the most recent editions of the ISO/IEC 14662 Open-edi Reference Model and ISO/IEC 15944-1, ISO/IEC 15944-2, ISO/IEC 15944-4, and ISO/IEC 15944-6 Business Operational View.

Although ISO/IEC 15944-7 is of the nature of a consolidated and integrated “controlled vocabulary”, it does contain rules which are relevant from a privacy protection requirements perspective. These are rules which are of the nature of supporting and assuring “unambiguity” in definitions of (key) concepts in the recorded information provided in support of a business transaction where the buyer is an individual and thus privacy protection requirements apply. These rules also support (and facilitate) the provision of HIEs in many a languages. Finally, it is a requirement that any organization or public administration (which is subject to privacy protection requirements) shall make publicly available its privacy protection policy. As such, it is advised that any definitions in an organization‘s privacy protection policy apply and implement these ISO/IEC 15944-7 rules to support and ensure “unambiguity” in any definitions as well as HIE support.


(1) (2) (3)

001 5.2 The use of a rule-based and flexible object oriented approach for the eBusiness Vocabulary requires rigorous quality and integrity control of the definitions to ensure that there is no tautology, i.e. circularity, in the full set of concepts definedin the international standard.

002 5.2 In order to ensure a harmonized “system of concepts,” a definition for a concept


501

4016

40174018

4019402040214022

402340244025402640274028402940304031

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

shall be established as early as possible in the development of the standard.

003 5.2 A concept may be totally atomic or may consist, i.e., inherit, one or more other concepts.

004 5.2 A concept may be part of one or more other concepts.

005 5.2 The presentation for a HIE eBusiness Vocabulary shall be in a form and format as already provided in Annex D, E or F in this part of ISO/IEC 15944.

006 5.3 The set of essential elements of each entry (or record) in the eBusiness Vocabulary, for each defined concept, consists of:

(a) the definition (of the concept);

(b) the term (representing the concept);

(c) the abbreviation of the concept (as applicable);

(d) the gender code for the term;

(e) the composite identifier (for the concept); and,

(f) the internal eBusiness vocabulary identifier.

007 5.3.1 The characteristics (and their unique combination) of a (new) concept shall be identified and agreed to prior to the drafting of a definition for that concept.

008 5.3.1 In the identification of the unique combination of characteristics for a concept, one shall maximize use of those already defined in existing international standards, i.e., where and whenever applicable or relevant.

009 5.3.1 Any concept requiring a definition for the clarity of the understanding and use of the ISO/IEC JTC1 international eBusiness standards shall be included in that standard.

010 5.3.1 There must be 1) a business case and rationale for the need to introduce a (new) concept into an international standard with its resulting definition and assigned term; and, 2) such a business case and rationale must maximize re-use and integration of existing international standards, i.e. those of ISO, IEC, ISO/IEC and/or ITU.

011 5.3.1 The descriptive statement comprising a definition must be clear, explicit and unambiguous and stated in the form of a single sentence.

012 5.3.1 Only a concept with a single definition shall be included and both the definition and associated term shall be stated in the singular.

013 5.3.1 Any definition of an eBusiness concept must be developed with two or more human interface equivalencies (HIEs) in order to maximize its unambiguity and subsequent use in support of any and all commitments made among parties to a business transaction.

014 5.3.1 As stated in 5.1, a concept can consist of, i.e. inherit, one or more other concepts. Consequently, where this occurs, the definition for a concept of this nature shall explicitly support this requirement.

015 5.3.1 When a concept incorporates one or more other concepts, the terms representing


503

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

these concepts shall be included in bold in the definition for that concept.

016 5.3.2 The issue of “polysemy” shall be avoided in international standards development.

017 5.3.2 The term chosen to designate a concept and its definition shall be unambiguous and not easily confused with terms representing other concepts.

018 5.3.2 The fact that the primary use of the eBusiness Vocabulary is to support the making of commitments, it is important that the term chose to designate a concept and its definition, is unambiguous and not confused with other concepts (meanings).

019 5.3.2 A term assigned to a definition of a concept is deemed to be a “noun” (or the gerundial form of a noun like “identification”).

020 5.3.3 In the development of a definition for a concept, the committee responsible shall decide as to whether or not an abbreviation or acronym needs to be assigned to the definition of a concept in addition to the term.

021 5.3.4 The gender of each term, as a noun, in the eBusiness Vocabulary shall be specified using Coded Domain ISO/IEC 15944-5:01 “Codes Representing Gender in a Natural Language”.

022 5.3.5 The identifier of any eBusiness Vocabulary entry is of the nature of a composite identifier and shall meet the requirements of “identifier (in business transaction)”.

023 5.3.5 The eBusiness Vocabulary composite identifiers are composed of a minimum set of four discrete and mandatory data elements, consisting of:

(a) the source international standard reference for the vocabulary entry;

(b) the unique identifier assigned by international standards organization for the standards

(c) document including part number where applicable;

(d) the date of the standard document as applicable

(e) the identifier of the Clause number in the standards document referenced.

024 5.3.5 An eBusiness Vocabulary identifier, as a composite identifier is deemed to be linguistically neutral and as such will have one or more Human Interface Equivalents (HIEs) for the definitions and terms they represent.

025 5.3.6 Each eBusiness Vocabulary identifier shall be assigned an internal unique identifier (as its common pivot code) as part of its entry in Annex D of ISO/IEC 15944-7, i.e., in the form of “Dnnn”. See Annex D.

026 5.3.6 Any subsequent, i.e., new, entry to the eBusiness Vocabulary shall be assigned the next available sequential “Dnnn” number.

027 5.4 In the development of a controlled vocabulary for an international standard, or a family of international standards (e.g. as here in the field of eBusiness), one shall maximize use (re-use) of applicable concepts already defined in existing international standards.

028 5.4 Where the term assigned to a defined concept, essential to the identification and


505

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

referencing of a concept is already in use, the term shall be accompanied by the qualification, (e.g., as for “identifier (in a business transaction))”.

029 6.2 The ISO/IEC JTC1/SC32 P-member bodies working with and through their national body standards organization are responsible in their jurisdictional domains for developing the human interface equivalents (HIEs) of the term/definition of a concept into the official language(s) of that jurisdictional domain as an Annex to this part of ISO/IEC 15944.

030 6.2 Any submission by an ISO/IEC, ISO, IEC and/or ITU P-member body of an Annex of HIEs to this part of ISO/IEC 15944 shall use the template of Clause 9 to specify the criteria governing the presentation of the eBusiness Vocabulary in that language.

031 6.3 Any UN member may submit, via its National Standards body, a new Annex to this part of ISO/IEC 15944 of the eBusiness Vocabulary in the official language(s) of its jurisdictional domain.

032 6.4 It is up to each ISO/IEC JTC1 P-member (or UN member state working via its national standards body), to develop and decide on the development of the HIE definition and assignment of the associated term for each ISO concept.

033 6.4 For the definition of a concept, the ISO/IEC JTC1 P-member body (or UN member state) may use (1) a transliteration of the ISO English (or ISO French) term for that concept in one’s language(s); or, (2) one can coin a new term for that concept.

034 6.4 Where a concept also has an abbreviation for the term in ISO English (or ISO French), the ISO/IEC JTC1 P-member (or UN member state), may (1) use an existing ISO English (or ISO French) abbreviation; or (2) develop a new abbreviation in its language(s).

035 7.0 The structure and presentation of any eBusiness Vocabulary to be added in other languages, i.e., as an Annex to this part of ISO/IEC 15944, shall be considered to be a set of HIE equivalent(s) in the official language(s) of the jurisdictional domain submitting such a new Annex to this part of ISO/IEC 15944.

036 7.0 The submission of such a set of eBusiness Vocabulary entries as a new Annex to this part of ISO/IEC 15944 shall be done in conformance with the rules stated in Clause 6.

037 7.0 The structure and representation of any additional eBusiness Vocabulary as an HIE Annex to this part of ISO/IEC 15944 shall conform to one or more of the following options (or combinations thereof):

1) be only in the official language(s) of the submitting ISO/IEC JTC1 P-member body (or UN member state);

2) include an ISO official language, i.e., English, French or Russian, as part of its submission for an Annex, the equivalent language(s) of the jurisdictional domain of the ISO/IEC P-member (or UN member state);

3) where there is more than one writing system for the official language(s) of that jurisdictional domain specify the applicable writing systems.

038 7.0 In support of the above rules, any submission of the addition of a HIE version of an eBusiness Vocabulary, i.e., as an Annex to this part of ISO/IEC 15944 shall be in


507

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

one of the following formats: (1) the format as presented in Annex D of this ISO/IEC 15944-7(with either unilingual, bilingual or multilingual HIEs); or, (2) the format as per Clause 3 in ISO/IEC 15944-7 (with either unilingual, bilingual, or multilingual HIEs).

039 7.0 Where the official language(s) of an ISO/IEC JTC1 P-member (or UN member state), or any jurisdictional domain includes the use of more than one writing system for the official language(s) of that jurisdictional domain, the submitting ISO/IEC JTC1 P-member or submitting jurisdictional domain shall state in its submission, as a new Annex to ISO/IEC 15944-7 whether it: (a) submits such in only one writing system of its official language; or, (b) submits such an Annex in two (or more) writing systems for representation of its language.

040 7.0 Any structure and presentation of a HIE version of the eBusiness Vocabulary shall contain the mandatory essential elements of such a “controlled vocabulary” as stated in 5.3.

041 7.0 In addition, any eBusiness Vocabulary of a HIE nature, submitted as an added Annex, to this part of ISO/IEC 15944 shall include the,

1) its UN member 3 digit ID code for which the UN is the coded domain Source Authority (cdSA). (This 3 digit code is also repeated in ISO 3166-1);

2) the 3 alpha code(s) of its official language(s) used in the HIE version of the eBusiness Vocabulary provided. The 3 alpha code shall be one based on the ISO 639-2/T set of codes; and,

3) the Annex D entry ID number, (e.g., D125) which serves as the pivot ID code).

042 8.1 The source for any amendments or additions to the entries in the eBusiness Vocabulary as stated in Annex D of this part of ISO/IEC 15944 shall be either:

1) this part of ISO/IEC 15944 itself;

2) amendments or additions to existing eBusiness standards namely ISO/IEC 14662 or current Parts of ISO/IEC 15944 which are already international standards, i.e., ISO/IEC 15944-1, ISO/IEC 159544-2, ISO/IEC 15944-4, ISO/IEC 15944-5, ISO/IEC 15944-6, and ISO/IEC 15944-7; and/or,

3) new parts of ISO/IEC 15944 which are under development, namely: ISO/IEC 15944-3 and ISO/IEC 15944-8.

043 8.2 A repository of the eBusiness Vocabulary, as an integrated and harmonized controlled vocabulary, shall be maintained for ISO eBusiness standards. Currently, these include ISO/IEC 14662, ISO/IEC 15944-1, ISO/IEC 15944-2, ISO/IEC 15944-4, ISO/IEC 15944-5, ISO/IEC 15944-6, and ISO/IEC 15944-7 eBusiness standard (and ISO/IEC 15944-3, and ISO/IEC 15944-8 which are currently under development).

044 8.2 The eBusiness Vocabulary shall also be maintained in the form of an online computer database.

045 8.3 The form and format for referencing an eBusiness Vocabulary entry is that of


509

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

“ISO/IEC 15944-7::nnn” where the “nnn” is that of the “nnn” in the “Dnnn” entry in Annex D of ISO/IEC 15944-7.

046 8.3 The overall approach to the maintenance of entries in the eBusiness Vocabulary shall be based on and harmonized with the rules governing the maintenance of “business objects” as stated in ISO/IEC 15944-2.

047 8.4 An eBusiness Vocabulary Dnnn once assigned is deemed to be permanent and if retired shall not be re-assigned.

048 8.4 The definition in an eBusiness Vocabulary entry, in a Clause 3, which is part of more than one eBusiness standard, shall not be changed without taking into consideration the other standards in which it is also a sub-clause in Clause 3.



1. This Annex B.7 currently contains all the rules found in ISO/IEC 15944-8.

2. In the preparation of the 2nd CD/or draft DIS document for Part 12, the consolidated list of rules below will be culled so that only those of particular relevance to ILCM will remain.


(1) (2) (3)

001 5.2 Where exceptions to the application of privacy protection principles exist, they shall be:

1) limited and proportional to meeting the objectives to which these exceptions relate; and,

2) a) made known to the public; or,

b) in accordance with law.

002 5.3.1 The protection of personal information shall be designed to prevent the misuse of such personal information.


511

4032

4033

4034

4035

4036

4037

40384039

4040

4041

40424043

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

003 5.3.2 An organization subject to privacy protection requirements in the jurisdictional domain (at whatever level) in which it delivers a good, service and/or rights, shall have in place implemented, enforceable policies and procedures with the proper accountability controls required to ensure its compliance with applicable privacy protection requirements

004 5.3.2 An organization is responsible for all personal information under its control and shall designate an organization Person, i.e. a privacy protection officer (PPO), who is accountable for the organization's compliance with established privacy principles which, in turn, are compliant with and support the legal requirements of a privacy protection nature of the applicable jurisdictional domain(s) in which the organization operates.

005 5.3.2 Any organization to which privacy protection requirements apply shall have in place policies and practices which make it clear as to who (and where), in an enforceable and auditable manner, in their business operations is responsible for compliance with these external constraints as applicable to the conduct of business transactions where the buyer is an individual.

006 5.3.2 Where an organization, as a seller, delegates any aspect of a business transaction involving an individual , and interchanges of personal information pertaining to that individual, to an “agent” (and/or “third party”), the organization shall ensure that: (1) in its arrangement with the designated agent (and/or third party), the agent (and/or third party) is fully aware of the applicable privacy protection requirements; and, (2) such parties commit themselves to support the applicable privacy protection requirements pertaining to the business transaction.

007 5.3.2 An agent (and/or third party) which commits itself to act on behalf of a Person acting as a seller in a business transaction, where the buyer is an individual in a jurisdictional domain where privacy protection requirements apply, shall ensure that the DMA(s) in its IT system(s) is capable of supporting applicable external constraints requirements.

008 5.3.2 An organization shall ensure that in the execution of an (instantiated) business transaction, i.e., as identified by its business transaction identifier (BTI), that where these involve parties, other than the individual as a buyer, that such parties, are capable of and have implemented the requirements of the privacy protection principles.

009 5.3.3 The specified purpose(s) for which personal information is collected with respect to the (the (potential) goal of the business transaction shall be identified by the organization at or before the personal information is collected.

010 5.3.4 Where in a business transaction, the seller requires the buyer, as an individual, to provide personal information, the seller shall ensure that the collection and use of such personal information shall have the informed and explicit consent of the individual and that the same be directly linked to the specified goal of the business transaction (to be) entered into.

011 5.3.4 Any secondary use of personal information of the individual in a business transaction requires the explicit and informed consent of the individual.

012 5.3.4 Except with the explicit informed consent of the individual, or as required by law, personal information shall not be used or disclosed for purposes other than those for which it was collected, i.e., in the context of the specified goal of the business


513

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

transaction to which it pertains.

013 5.3.5 The collection of personal information shall be limited to only that which is necessary and relevant for the identified and specified purpose, i.e., the goal, of the specified business transaction.

014 5.3.5 Any collection of personal information by the seller, or other parties to a business transaction, which pertains to a buyer as an individual in that business transaction, shall be lawful and fair.

015 5.3.5 An organization collecting personal information shall inform the individual concerned whether or not the personal information collected is:

1) essential to the intention of the business transaction;

2) required to be provided by the individual due to identified and specified constraints of jurisdictional domains applicable to the nature and goal of the business transaction; and/or,

3) “optional”, i.e., desired to have by the organization, acting as the seller, but not required.

016 5.3.6 The integrated set of ILCM principles applies to and supports the external constraints of a privacy protection nature for any business transaction involving an individual and its personal information.

017 5.3.6 Personal information shall not be used or disclosed by the seller (or regulator) for purposes other than for those it was originally collected as part of the business transaction, except with the informed consent of the individual, or as required by law. Secondary or derivative uses of personal information are not permitted.

018 5.3.6 Where the organization, having collected personal information for a specific purpose and goal of the execution of the business transaction, desires to use the relevant personal information for another purpose, it is necessary to obtain revised/new “informed consent” directly from the individual concerned.

019 5.3.6 Personal information shall be retained by the seller only for as long as is necessary for the fulfillment of those purposes as specified as part of the business transaction.

020 5.3.6 The seller shall identify to the buyer, especially where the buyer is an individual, any and all record retention requirements pertaining the resulting sets of recorded information forming part of the specified goal of a business transaction as a result of applicable external constraints of jurisdictional domain(s) as a result of the actualization of the business transaction.

021 5.3.6 Where the seller offers a warranty, or extended warranty, as part of the business transaction, the seller shall inform the buyer, when the buyer is an individual, of the associated added records retention requirements for the personal information associated with the warranty (including the purchase by the individual of an extended warranty).


515

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

022 5.3.6 Where the buyer in a business transaction is an individual, the seller shall inform the individual of any and all records retention requirements of personal information which is recorded as the result of the actualization of the business transaction, including:

1) personal information which is required to actualize the business transaction and the time period(s) for which such sets of personal information are to be retained;

2) additional personal information, i.e., in addition to (1), which is required to be collected and retained as a result of applicable external constraints, of whatever nature, of relevant jurisdictional domain(s); and/or,

3) additional personal information, i.e. in addition to (1) or (2), which is required to be collected and retained as a results of the invocation of an associated warranty, purchase of an extended warranty, or any other personal information which is required to be collected or retained as part of the post-actualization phase of an instantiated business transaction.

023 5.3.6 Where the buyer in business transaction is an individual, the seller shall inform that individual of the applicable record retention conditions where these pertain to personal information.

024 5.3.6 Where a business transaction does not reach the actualization phase, any personal information collected by the organization in support of that transaction shall be deleted by the organization (unless the individual concerned explicitly consents to the prospective seller to the retention of such personal information for a defined period of time).

025 5.3.7 Personal information shall be as accurate, complete and up-to-date as is necessary for the specified purposes for which it was collected in support of the business transaction.

026 5.3.8 Personal information shall be protected by operational procedures and safeguards and safeguards appropriate to the level of sensitivity of such recorded information and shall have in place (and tested) measures in support of compliance of compliance with privacy protection requirements of applicable jurisdictional domains, as well as any other external constraints which may apply such measures as are appropriate to ensure that all applicable legal requirements are supported.

027 5.3.9 An organization shall have and make readily available to any Person specific information about its policies and practices pertaining to the management and interchange of personal information under its control.

028 5.3.10 An individual has the right to know whether or not an organization has personal information under its control on or about that individual.

029 5.3.10 An organization, subject to privacy protection requirements, upon receiving a request from an individual shall inform that individual of the existence, use and disclosure of his or her personal information in any and all records management/information systems and in particular the DMAs of the IT systems which support the business transactions of that organization.


517

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

030 5.3.10 Where an organization discovers that it has personal information on the individual who made the request, that individual shall be given full and complete access to any and all personal information which the organization maintains on that individual (unless there exist specified and referenced external constraints of the applicable jurisdictional domain(s) which prohibit access to one or more sets of such personal information).

031 5.3.10 Where an organization has and maintains personal information on the individual making the request for access to his/her personal information and such personal information does exist, the organization shall provide access to the personal information in a manner which is convenient to that individual.

032 5.3.11 An individual shall be able to challenge the accuracy and completeness of his or her personal information held by an organization with respect to a business transaction (and/or part of a general client file) and have it amended or deleted as appropriate.

033 5.3.11 An individual shall be able to challenge an organization concerning its compliance with the above privacy protection principles 1 through 10, including assurance of privacy protection for any personal information that is interchanged with other organizations as agents or third parties (as well as secondary or derivative uses of personal information).

034 5.4 An organization shall have in place policies and procedures in order to identify and tag (or label) all sets of recorded information (SRIs) which contain personal information and do so at the appropriate level of granularity to facilitate compliance with specific privacy protection requirements.

035 5.4 For a field or data element comprising the recorded information pertaining to a business transaction, for personal information the following requirements apply from a data interchange perspective, the need to ensure the provision of a tag(s) to note that the personal information:

1) shall not be communicated with other parties;

2) may be communicated to other parties but with restrictions; or,

3) may be communicated to other parties with no restrictions.

036 5.4 For a field or data element comprising the recorded information pertaining to a business transaction, for personal information the following requirements apply from a data interchange perspective, i.e., the need to ensure the provision of a tag(s) to note that the personal information is subject to mandatory disclosure is:

1) the actual information;

2) anonymous information that represents the actual information; or,

3) pseudonyms that represents the actual information.

037 6.3 For any business transaction (or part thereof) which involves external constraint(s) of a privacy protection nature, the Open-edi model shall include:

1) the Person in the role of buyer as an individual;

2) the role of the regulator(s) representing the source of privacy protection


519

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

requirements for modelling as part of a scenario and scenario components;

3) the role of the regulator(s) providing proof of identity of the individual without necessarily disclosing the actual identity of the individual.

038 7.2.1 A common set of external constraints of a jurisdictional domain on a business transaction, where the buyer is an individual, are those of a privacy protection nature.

039 7.2.1 Where the buyer in a business transaction is an individual, external constraints of a privacy protection nature of jurisdictional domains apply and shall be supported in applicable business scenarios and scenario components.

040 7.2.1 Any Person offering a good, service, and/or right as a seller shall explicitly state whether or not the same is available for purchase by any Person in its role as an “individual”.

041 7.2.1 Where the buyer in a business transaction is an individual, external constraint of a privacy protection nature of jurisdictional domains apply and shall be supported in applicable business scenarios and scenario components.

042 7.2.1 A seller shall ascertain, at the identification phase in the process leading to a business transaction, whether or not the buyer is an individual (not someone as organization Person buying on behalf of an organization or public administration).

043 7.2.2 A common set of external constraints of a jurisdictional domain on a business transaction, where the buyer is an individual, are those of a consumer protection nature. As such, any business transaction involving an “individual” in the role of buyer shall be structured to be able to support applicable “consumer protection” requirements.

044 7.2.2 Where the buyer is an individual, the seller shall ascertain that the individual has the age qualification required by the jurisdictional domain to be able to be involved in and make commitments pertaining to the good, service and/or right being offered in the proposed business transaction.

045 7.2.2 A seller shall ensure that where it intends to sell a good, service and/or right to a buyer as an individual that consumer protection requirements of the applicable jurisdictional domain of the buyer are supported.

046 7.2.3 In the development of human interface equivalents (HIEs) for an ID code or a semantic identifier, these must also include those HIEs of a nature to ensure individual accessibility.

047 7.2.5 Privacy protection requirements apply only to a natural person, i.e., human being, acting in the role of an individual.

048 8.2 The primary set of generic principles and rules, as well as associated concepts and their definitions governing the creation, recognition, use, management of identities of a Person as stated in Clauses 6.1.4, and 6.2.2 of ISO/IEC 15944-1, apply here.

049 8.2 An individual may have and often does have multiple different personae, i.e., names in the lifetime of that individual. More than one persona may be valid in one


521

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

or more jurisdictional domains at the same time.

050 8.2 An individual may have, and often has, one or more recognized individual names (RINs), including two or more simultaneously existing RINs, and thus more than one recognized individual identity (rii).

051 8.3 Any Person acting in the capacity of a Registration Authority (RA) shall, for each of its Registration Schemas (RS) involving the registration of an individual, be identified as observing the rules governing and ensuring the assignment of a unique identifier for each individual as a member of that registration schema.

052 8.3 A Registration Authority shall assign a unique identifier to each of its registered members including, where relevant, where the member is acting as an individual.

053 8.3 Where the Registration Schema (RS) of a Registration Authority allows for the registration of Persons and differentiates among sub-types of Persons, i.e., individuals, organizations and/or public administrations, the Registration Authority shall ensure that:

1) any registration involving an individual is so identified; and,

2) that privacy protection requirements which apply to resulting or associated personal information are identified and supported.

054 8.3 Where a Registration Authority (RA) administers more than one Registration Schema which involves individuals (and their associated personal information), the RA shall not use personal information provided by the individual under one Registration Schema (RS) in another RS of the RA without the explicit consent of the individual concerned unless required by applicable law.

055 8.4 The individual identity, i.e., the persona and the associated identifier, used by an individual in a business transaction, shall be capable of being prescribed depending on the context and goal of the business transaction.

056 8.4 A specific individual identity (ii) established by a Registration Authority, (organization or public administration), should not be used for any purpose other than that for which it was created, without the express and explicit consent of the individual.

057 8.4 For any persona Registration Schema which includes, in whole or in part, individuals as members, external constraints of a privacy protection nature apply and all its registrants which are individuals shall be managed as members of an individual persona Registration Schema (ipRS) in accordance with applicable privacy protection requirements.

058 8.4 A Registration Authority (RA) for individuals shall have explicitly stated rules for transforming an individual identity into a recognized individual identity to meet a stated business requirement.

059 8.4 The rules governing a business transaction shall either require the use of a specified recognized individual identity (rii) or allow for several of a similar nature.

060 8.4 In a business transaction, individual authentication is established by either:


523

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

1) mutual definition and acceptance: or,

2) referring to predefined individual persona registration schema (ipRS) and process of a particular RA

061 9.2 The Clause 8.4 “Rules for the specification of Open-edi roles and role attributes”, as stated in ISO/IEC 15944-1 are mandatory where the business transaction involves an individual as a buyer.

062 9.2 Prior to the start of the actualization phase of a business transaction, a seller shall ascertain whether or not the Person acting as a buyer is doing so in its capacity or status as an individual (rather than as an organization Person or other roles of a Person).

063 9.2 Where the buyer in a business transaction is an individual, the buyer shall:

1) ensure that privacy protection requirements as stated in this part of ISO/IEC 15944 are applied; and,

2) ascertain whether or not other external constraints apply with respect the individual meeting specified criteria of the applicable jurisdictional domain(s) in qualifying for the role of buyer with respect to the good, service, and/or right which is the goal of the business transaction.

064 9.2 When the identification and negation phase of a business transaction does not result in its actualization and the prospective buyer is an individual, the seller (or regulator) shall delete all personal information on that individual gathered at that time.

065 9.3 The rules in Clause 6.6.2.3 “Personae as legally recognized names (LRNs)”, as stated in ISO/IEC 15944-5 apply.

066 9.3 Where the buyer in a business transaction is an individual, the seller shall inform itself as to whether external constraints apply which require the individual to use a legally recognized name (LRN) as its persona, as well as the nature of the Source Authority for such a LRN.

067 9.4 The rules governing the truncation of a persona, as stated in ISO 7501 and ISO 7812 ISO/IEC 15944-1, apply to this Part of ISO/IEC 15944.

068 9.4 Where external constraints on a business transaction require an individual as a (potential) buyer using a legally recognized name (LRN) as the persona for that individual, the seller shall specify the types of LRNs permitted to be used by the individual.

069 9.4 Where external constraints on a business transaction require that the personae of the individual be provided using a specified language or character set which is different from the language which the individual uses for his/her persona (or is his/her birth name), then the transliteration rules of ISO 7501 shall apply.

070 9.5 Identification of a Person as buyer in a business transaction is not always necessary in (electronic) business transaction involving the seller knowing whether or not the buyer is an individual.


525

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

071 9.5 Unless explicitly proscribed, (not allowed) by external constraints of the relevant jurisdictional domain applicable to the specified goal of the business transaction to be entered into, an individual as buyer many decide to remain anonymous in that business transaction, and no personal information on the individual is maintained by the seller or other parties

072 10.1 Conceptually, a business transaction can be considered to be constructed from a set of fundamental activities: planning, identification, negotiation, actualization and post-actualization.

073 10.1 These five fundamental activities may take place in any order.

074 10.1 A Person may terminate a business transaction by any agreed method of conclusion.

075 10.1 The activities may be completed in a single continuous interactive dialogue or through multiple sets of interactions among buyer and seller.

076 10.3 During the identification phase, the seller shall ascertain whether or not the buyer is an individual, and if so, inform the individual of the privacy policy of the seller.

077 10.4 Where the buyer is an individual, the end of the negotiation phase shall include the explicit consent of the individual for provision of its personal information, as identified and specified, as well as the specification of the information life cycle management (ILCM) and EDI aspects of such personal information, as stated in Clause 5.3 “Privacy Principles”.

078 10.5 Where the buyer is an individual, the seller shall ensure and have in place supporting procedures and mechanisms to support both the generic privacy protection requirements as: (1) found in this part of ISO/IEC 15944 and stated in its rules and guidelines; and, (2) as well as those resulting from the negotiation phase, i.e., as negotiated between the seller and the individual as buyer.

079 10.6 A buyer (and its agent(s)) or third party (or any other party to the business transaction), shall not retain any personal information on the individual as the buyer for any time longer than is consented to by the individual for post-actualization purposes unless external constraints of the applicable jurisdictional domain requires retention of such personal information for a longer period.

080 10.6 Where the buyer gifts the product to another individual, and the terms of the purchase allow the recipient individual to assume the warranty, extended service contract, etc., the seller shall ensure that such a recipient individual is fully informed of its privacy protection rights, including the record retention requirements.

081 11.2 Each instantiated business transaction involving an individual as a buyer shall have a business transaction identifier (BTI) assigned by the seller or the regulator.

082 11.2 Where an individual as a buyer in a business transaction decides to be anonymous (as permitted by the external constraints of the applicable jurisdictional domain), the business transaction identifier (BTI) serves as the sole identifier.

083 11.2 Where the business transaction is of the nature of a regulatory business transaction (RBT) and the rules governing the RBT permit an individual to be a buyer, such rules shall explicitly state and define the associated personal


527

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

information in conformance with this part of ISO/IEC 15944.

084 11.3 The rules governing state changes of recorded information (Clause 6.6.4.3 “State Changes” in ISO/IEC 15944-5) apply to any business transaction involving an individual as a buyer.

085 11.4 The rules governing the specification of records retention requirements are stated in Clause 8.5.2.8 and 8.5.2.9 in ISO/IEC 15944-1 and in Clause 6.6.4.2 of ISO/IEC 15944-5 and are mandatory to any business transaction involving an individual as a buyer, i.e., to all resulting information.

086 11.4 Where the buyer is an individual, the seller shall inform the buyer of all records retention aspects, whether of internal or external information, with respect to the sets of recorded information (SRIs) pertaining to the personal information forming part of the business transaction, and in particular those pertaining to the post-actualization phase.

087 11.5 The rules governing temporal referencing as stated in Clause 6.6.4.5 “Date/time referencing” as stated in ISO/IEC 15944-5 apply when the individual is a buyer in a business transaction and thus privacy protection requirements apply.

088 11.5 Unless otherwise specified and agreed to by the individual as buyer in a business transaction, the common temporal referencing schema of the jurisdictional domain of the individual applies.

089 11.5 The temporal referencing schema governing the business transaction where the buyer is an individual shall also be used to ensure deletion of sets of personal information as required by privacy protection requirements.

090 12.2 It is important in scoping an Open-edi scenario to specify at the outset whether or not external constraints apply to the business transaction being modelled.

091 12.2 It is equally important in scoping an Open-edi scenario which allows for an individual as buyer in a business transaction to note whether this is an adaptation of an existing “generic” Open-edi scenario or a new Open-edi scenario.

It is understood that (a) most of the Open-edi scenarios will be and are modelled at the Person level; and, (b) that many of these need only minor modifications in their modelling of such scenarios to incorporate privacy protection requirements.

F-001 F.1 Management and control of state change, retention and destruction of personal information shall be based on the application of the integrated set of information life cycle management (ILCM) principles.

F-002 F.2.2 Where an individual is a party to a business transaction, i.e., as a buyer, the seller (as an organization or public administration) shall have in place rules governing state changes, if any, for personal information (at whatever level of granularity required) in support of data management and interchange required to comply with privacy protection requirements

F-002 [sic] F.2.2 An instantiated business transaction shall have one or more IB or SC for which no state changes are permitted. One of these is to serve as the transaction ID number, i.e., a business transaction identifier (BTI), for the instantiated business


529

CD ISO/IEC 15944-12:2014(E)


(1) (2) (3)

transaction.

F-003 F.2.2 If a state change is required, the seller (and/or regulator) shall specify the number of state changes permitted.

F-004 F.3 Where an individual is a buyer to a business transaction, the seller shall specify who is responsible for the retention of any (combination of) set(s) of recorded information during the negotiation phase and no later than at the actualization phase in accordance with privacy protection requirements.

F-005 F.3 Where an individual is a buyer in a business transaction the seller shall ensure that all other parties to the instantiated business transaction, as applicable, (e.g., a regulator, an agent, and/or third party) are informed of records retention (and destruction requirements).

F-006 F.3 Where an individual is a buyer to a business transaction, the seller shall specify the “retention trigger” activating records retention requirements in accordance with privacy protection requirements of the applicable jurisdictional domain(s).

F-007 F.4 Where an individual is a buyer to a business transaction, the seller shall specify the disposition action to be taken at the end of the expiry of the record retention period in accordance with privacy protection requirements of the applicable jurisdictional domain.


531

CD ISO/IEC 15944-12:2014(E)

Annex C(normative)

Linking ILCM to process phases of a business transaction


1. Unfortunately, the June, 2013 Beijing meeting of SC32/WG1 was cancelled. On result being that important decision identified for the Beijing are now deferred to the upcoming November, 2014 Toronto meeting. where contents of this Annex be reviewed and discussed in detail and decision recorded as part of the CD ballot resolution comment process in order to finalize the contents of this Annex for Part 12.

2. It is recognized that decisions taken here may impact other clauses and Annexes in Part 12.

3. Comments and inputs from P-members and experts are welcome here.

C.1 Introduction

The purpose of this Annex is to provide an informative and high level view of the link of the ILCM to the five process phases85 in the Business Transaction Model (BTM)86.

C.2 Rules governing linkages of ILCM process to process component of the Business Transaction Model (BTM)

In modelling a business transaction, from a process perspective, five phases were identified. {See ISO/IEC 15944-1 Clause 6.3} They are:

a) planning;

b) identification;

c) negotiation;

d) actualization;

e) post-actualization.

From this perspective, the following rules apply.

Rule C01:If the SRIs interchanged between a seller and a buyer do not result in the actualization of a business transaction, any such EDI activities interchanged as IBs (or SCs) between the seller and the prospective buyer, as an individual shall be considered to be of the nature of a transitory record and any personal information pertaining to that individual shall be expunged unless the individual as a prospective buyer agrees to the retention by the prospective seller of one or more SRIs of his/her personal information.

85 The rules and definitions of “process component” of the Business Transaction Model (BTM) apply to this Part 12 Annex. They are stated in Clause 6.3 “Rules governing the process component” in ISO/IEC 15944-1.

86 The rules and definitions of the Business Transaction Model (BTM) apply to this Part 12 Annex. They are stated in Clause 6.1.5 “Business transaction model: Key components” in ISO/IEC 15944-1.


533

4044404540464047

4048

40494050405140524053

4054

4055

4056

40574058

40594060

40614062

4063

4064

4065

4066

4067

4068

4069407040714072407340744075

534535

536537

CD ISO/IEC 15944-12:2014(E)

For example, even though no business transaction was concluded the individual may consent to receive a catalogue, product offerings, information on sales, etc., by the prospective seller.

Rule C02:Where post-actualization requirements apply to the product, services and/or rights of the goal of a business transaction and its actualization apply, the organization acting in the role of seller (or regulator) needs to have rules which support the following (sub-) scenarios:a) the ability of the seller to transfer post-actualization responsibilities to an agent, (e.g., servicing of

a warranty) with the associated transfer of (defined) personal information of the buyer;b) the ability of the buyer, as an individual, to “gift” the product, service and/or right to another

individual. In such a context, the seller needs to (i) add personal information on the warranty holder; and, (ii) delete all “no longer required” personal information on the “individual” who was the buyer.

C.3 Figurative overview of linking the five phases of the process component of the Business Transaction Model (BTM) to ILCM requirements

Figure C.1 below provides a (high level) overview of the linkages of the five phases of the Business Transaction Model (BTM) to the ILCM model.


539

4076

40774078

4079

40804081408240834084408540864087408840894090

4091

40924093

40944095

CD ISO/IEC 15944-12:2014(E)

Figure C.1 Overview- linking the five phases of the process component of the Business Transaction Model (BTM) to ILCM requirements


Process Phases in modelling a business transaction where the “buyer’ is an “individual”

Planning

Identification

Negotiation

Actualization

Post-Actualization

ILCM & Privacy protection Requirements context not applicable to “cash” transactions, buyer is anonymous or no post-actualization is associated with the (proposed......???incomplete

Seller Side: Not applicable – no “binding” between seller and buyer. No personal information of a prospective buyer as an individual. Buyer Side: Applicable if individual as prospective buyer has made his/her personal information known (publicly available).

Seller required to determine whether prospective buyer is an individual or not. Seller (prospective) should identify his/herself as individual if in this role. If transaction ends here = transitory record to be expunged, unless individual agrees that buyer can retain personal information for a use which must be specified and agreed to.

Includes individual and seller determining and agreeing to ILCM aspects and conditions. Identify ICLM external constraints, when applicable,

If no “actualization” need agreement on how long personal information on prospective buyer (individual) can be retained by (prospective) seller. Then expunge (unless overridden by external constraints).

May include the provision of additional personal information by buyer to the seller. If agents or third parties are involved, the associated ICLM requirements need to accompany the IBs & SCs in the EDI. Further the seller needs to ensure that agents and/or buyers execute/implement the associated ICLM demands (especially those of a records retention nature).

Post-Actualization aspects can be established at any time, including in the Planning phase. This Phase may require the seller to retain specified SRIs for a determinate period before their expungement. It also may require the individual as warranty holder to retain certain SRIs. The seller may transfer warranty obligations to an agent (along with transfer of personal information).

541

4096

40974098409941004101410241034104

4105

CD ISO/IEC 15944-12:2014(E)

Annex D(normative)

Generic approach to I*LCM decisions in a privacy protection requirements context – ILCM decision template


1. At the June, 2014 Beijing meeting of JTC1/SC32/WG1 a significant amount of time is requested for the participating SC32/WG1 experts to develop this Annex further. Unfortunately, the June 2014 Beijing meeting had to be cancelled. This means that discussions planned and decisions to be made with respect to Annex D have been deferred to the November, 2014, Toronto meeting.

2. The primary purpose of this Annex is to serve as a self-standing document for use by implementers and users of ISO/IEC 15944-12, to facilitate their conformance with ISO/IEC 15944-12.

3. When completed this Annex will contain one (or more) decision charts and accompanying “check-off” templates.

D.1 Introduction

The primary purpose of this Annex is to provide a high level generic, i.e., primitive level, approach using a decision flow chart template approach for use by a Person, i.e., organization or public administration, in the role of a seller or regulator in a commitment exchange, (e.g., business transaction) process with respect to applicable ILCM requirements where the buyer (or client) is in the role of an individual.

D.2 Generic approach to ILCM decisions in a privacy protection requirements context

D.2.1 Link to applicable records and retention and disposal of personal information and “transitory records”

The Part 12 development work incorporates that of D.2. above re: “transitory records” and the post-actualization phase being applicable to a business transaction. These represent two very particular and specific sub-types of the overall approach (and model).

The purpose of Figure A.2 is to present a high-level approach of the key aspects and decisions pertaining to ILCM requirements without being linked to a particular process phase for modelling a business transaction.

A “transitory record” is a concept which pertains to SRIs which are ephemeral or have a short temporal life span. In the context of the (a) business transaction model (BTM) and the five phases of the process model; and, (b) privacy protection requirements, a “transitory record” pertains to any SRI (or combination of the same) interchanged as IBs (and their SCs) during the “planning, identification and negotiation phases” directed at the establishment, i.e., actualization, of a business transaction but which did not pass the negotiation phase and thus were never actualized.

This means that the buyer and seller interchanged as IBs (and their SCs) various SRIs. The prospective buyer is an individual, this means that personal information was provided by the individual, as buyer, to the seller, as organization.

Rule D01:


543

41064107410841094110

4111

4112411341144115

41164117

41184119

4120

4121412241234124

4125

41264127

41284129

413041314132

41334134

413541364137413841394140

414141424143

4144

CD ISO/IEC 15944-12:2014(E)

Unless explicitly agreed to by an individual as a prospective buyer in a business transaction any personal information provided by the prospective buyer to the seller (or collected by the seller) which did not result in the actualization phase of that business transaction, shall be considered to be a “transitory record” and be expunged by the seller organization.

Rule D02:In the context of Rule Dnn1 the seller (organization) may request that a limited and specified SRI(s) of personal information may be retained for pre-defined use of such personal information of the (prospective) buyer as an individual.

Examples include the individual agreeing the retention of specified personal information (SRIs) by the seller organization with respect to sending a catalogue, special sales/deals, the assignment of a (prospective) customer ID, etc.

Figure D.1 below presents a very primitive level approach only. It incorporates the concept of “transitory record” as well as “post actualization” phase being applicable to a business transaction. These represent two very particular and specific aspects of ILCM requirements for personal information.

{Figure D.1 below is a draft only.}

Figure D.1 Decision Tree Diagram for identification and disposition of a SPI from an ILCM requirements perspective (including it being declared a transitory record”


1. Creation of personal information as one or more SPIs pertaining to a business transaction

2. Transitory Yes/ No

2.1 If Yes, Expunge*

3. Establish/Apply Records Retention Schedule* (including retention triggers)

4. End of Retention period invoke disposition actions

4.3 destroy/expunge4.1 Transfer Out* –to another organization

4.2 Transfer in*- (copy) to archive, historical, research purposes

4.4 Maintain as permanent record/SRI*

4.5 Other?

* Indicates that external constraints related to the nature of the business transaction may apply

545

4145414641474148414941504151415241534154415541564157

415841594160

41614162

416341644165

CD ISO/IEC 15944-12:2014(E)

D.2.2 Link to “post actualization” requirements

It is recognized that post actualization requirements maintain specific SRIs of a personal information nature require the seller (organization) in the business transaction to retain associated personal information for a longer temporal period than may be the default.

For example, an individual as buyer may or may not decide to purchase a warranty over and above that offered by the seller as the “default” time period warrant. Another example is that of the seller offering a “life time warranty” to the buyer.

Another example is the creation and collection by sellers (or their agents) of “points” programs which involve accumulation and retention of personal information for an indefinite temporal period.

[to be completed as a result of the SC32/WG1 meetings as well a P-member CD ballot comments.]


547

4166

416741684169

417041714172

41734174

4175

4176

4177

CD ISO/IEC 15944-12:2014(E)

Annex E(Informative)

Generic approach to identification of properties and behaviours of personal information as SRI transitory records and their

disposition/expungement


1. The issuance of the draft CD for Part 12 (as well as earlier SC32/WG1 discussions) identified the importance of addressing the issue of “transitory records” in an ILCM perspective and in a privacy protection requirements context.

2. Addressing this issue has been completed to a certain extent within the normative clauses and their rules and associated text. The purpose of this Annex E is to provide added information.

3. P-members are requested to review the text below, provide suggestions & comments, including questions, etc. These will be resolved das part of the Toronto, November, 2014 JTC1/SC32/WG1 CD ballot comment resolution meeting.

E.1 Introduction

The concept of “transitory record”, its definition and application is well-known in the records and information management community basically as a (standard) internal constraint within an organization. It became linked to external constraints of advent of legislation and pursuant regulations with Access to Information (ATI) nature and that pertaining to privacy/data protection legislation.

From an Access to Information (ATI)/freedom of information (FOI) external constraints perspective, the need for a clear and explicitly stated definition of the concept of “transitory record” came from the concern that public administrations subject to such external constraints would delete (expunge) recorded information while an “Access to Information (ATI) Request” for such information was in progress. For a public administration perspective, the concern was that Access to Information Requests would “gum up” or stop the normal records/data management processes for deleting/expunging records.

From a privacy/data protection external constraints perspective the need for a clear and explicit definition of the concept of “transitory record” and associated rules arose from the fact that any and all recorded information pertaining to an individual, especially that used for decision or commitment making are “personal information” and thus need to be available to the individual concerned.

From an IT perspective, is the fact that prior to the advent of the widespread use of IT systems a substantial amount of what are now “transitory records” were dealt with in “face-to-face” meetings, via telephone conversations, etc,, with only the “final” decision being recorded (or at times just agreed to without a written record). The introduction and advent of emails, and later IT systems based teleconferences has as one result that all information of this nature is now “recorded information” and therefore where it pertains to or involves an “individual” subject to privacy protection requirements.

The following Clauses of Annex E address these issues in a Part 12 context.


549

417841794180418141824183

4184

4185

418641874188

41894190

419141924193

4194

4195419641974198

419942004201420242034204

4205420642074208

420942104211421242134214

4215

CD ISO/IEC 15944-12:2014(E)

E.2 Definition of the concept of “SRI transitory record”

The definition of “SRI transitory record” is:

3.161transitory recordSRI that is required only for a very limited and specified (retention period) time to ensure the completion of a routine action or the preparation of a subsequent SRI


The use of the label “transitory record” serves as a bridge to well established and widely used records management standards.

AT the same time use of “SRI” is the label for the concept used to serve as a bridge to the ISO/IEC 15944 family of standards where the concept and definition of an “SRI” serves as an umbrella for what in other ISO and ISO/IEC standards (As well as communities of practice) are known as “records, documents”, “files”, “data elements, even “database”, etc., or in an EDI context, “information bundles”, “semantic components (SCs)”.

As such, a “set of recorded information (SRI) serves as higher level, primitive concept and is linked directly to the degree and level of granularity at which an organization manages and interchanges recorded information.

E.3 Information on examples of “SRI transitory records”


1. The following examples are taken from websites of various governmental public administrations of Australia, Canada, UK, and USA.

2. It may well be that some of the examples “overlap” and can/should be consolidated. CD ballot comments and suggestions are most welcome.

Basically, “transitory records” are those SRIs which are required only for a very limited (Temporary) time to ensure the completion of a routine action or the preparation of a subsequent (final/complete) SRI.

SRI transitory records include:

a) Recorded information of temporary usefulness that are not an integral part of the operational record (for that individual) by the organization);

b) Convenience copies such as extra copies of an SRI which are created and retained for a short period only for the convenience of reference;

c) Working materials or drafts used in the preparation of the final “SRI” (And which are not required to be retained for legal, statutory or evidentiary purposes). This includes drafts and revisions that are not needed to document decisions and associated approvals authorizations or related aspects of the making of commitments (pertaining to a business transaction);

d) (electronic) SRIs entered into an IT system during an update process and not required for operational, audit or legal purposes;

e) (electronic) SRIs containing data that are manipulated, sorted and/or moved from one “run”, i.e., the execution of a computer program to a subsequent “run” in the process of updating a master file or database;


551

4216

4217

421842194220422142224223

42244225

4226422742284229

42304231

4232

4233

4234

42354236

42374238

42394240

4241

42424243

42444245

4246424742484249

42504251

425242534254

CD ISO/IEC 15944-12:2014(E)

f) (electronic) SRIs generated during the creation or use of a master file or database which contain data on the operation of the IT system except where they are required to support the integrity of the master file(s) or database(s);

g) Test records such as SRIs consisting of routine or bench mark data constructed or used for the purpose of testing IT system performance (including text messages and related communication activities).

h) A SRI that is required only for a very short period of time to ensure the completion of a routine action or the preparation of the final SRI itself (e.g. SRIs related to an online e-business in its planning phase which is not utilized in the actualization of a business transaction such as the making of a travel reservation).

i) I) Other?


553

425542564257

425842594260

4261426242634264

4265

4266

CD ISO/IEC 15944-12:2014(E)

Bibliography

Project Co-Editors’ Note:

1. This Bibliography will be updated as required (a) from the draft CD to the CD stage; (b) from the CD to DIS stage; and, (c) from the DIS to FDIS stage.

The bibliography is organized in two parts. The first identifies sources that are ISO and ISO/IEC international standards. The second cites other cited sources which are useful to the understanding of this part of ISO/IEC 15944.

1. ISO and ISO/IEC international standards

ISO/IEC 9798-1:1997(E), Information technology — Security techniques — Entity authentication — Part 1: General

ISO/IEC 10181-2:1996(E), Information technology — Open Systems Interconnection — Security frameworks for open systems: Authentication framework

ISO/IEC 11179-1:2004(E), Information technology — Metadata Registries (MDR) — Part 1: Framework

ISO/IEC 11179-3:2003(E), Information technology — Metadata Registries (MDR) — Part 3: Registry metamodel and basic attributes

ISO/IEC TR 13335-1:1996(E), Information technology — Guidelines for the management of IT Security — Part 1: Concepts and models for IT Security

ISO/IEC TR 15285:1998(E), Information technology — An operational model for characters and glyphs

ISO 15489-1:2001(E/F), Information and documentation — Records management — Part 1: General/ Information et documentation — «Records management» — Partie 1: Principes directeurs

ISO/IEC 15944-6:2009(E), Information technology — Business Operational View — Part 6: Technical introduction to eBusiness modelling

ISO 19115:2003(E), Geographic information — Metadata

ISO 19135:2005(E), Geographic information — Procedures for item registration

ISO/TS 25237:2008(E), Health informatics — Pseudonymization

ISO/IEC 27002:2005(E), Information technology — Security techniques — Code of practice for information security management

2. Other

GS1Global Traceability Standard (GDSN). Issue 1.2.2. (March, 2010). Available from: http://www.gs1.org/docs/gsmp/traceability/Global_Traceability_Standard.pdf (Accessed 2011-10-04)

GS1 Global Data Dictionary: http://gdd.gs1.org/GDD/public/searchableglossary.asp (Accessed 2011-10-04)

Hern, Alex, (21 July, 2014) Personal data removed from Irish Genealogy site over security fears. The Guardian. http://www.theguardian.com/technology/2014/jul/21/ireland-shuts-government-genealogy-personal-data-concerns (Accessed 2014-27-07).

Quittner, Joshua. (Monday, 8 February, 1999). Going private. Time 153(5):62 (8 February, 1999). Available from: http://www.time.com/time/magazine/article/0,9171,990168,00.html (Accessed 2011-10-04)


555

4267

4268

42694270

427142724273

4274

42754276

42774278

4279

42804281

42824283

4284

42854286

42874288

4289

4290

4291

42924293

4294

42954296

4297

429842994300

43014302

http://www.time.com/time/magazine/article/0,9171,990168,00.html



http://gdd.gs1.org/GDD/public/searchableglossary.asp

http://www.gs1.org/docs/gsmp/traceability/Global_Traceability_Standard.pdf

CD ISO/IEC 15944-12:2014(E)

Sun, Wenfeng and Jake V.Th. Knoppers, (12 June, 2014). “Timely, accurate and relevant data only: Privacy protection requirements on Big Data”. Prepared for the JTC1/SC32 Open Forum on Big Data.: ISO/IEC SC32/WG1 N0745.

UN. International Covenant on Economic, Social and Cultural Rights. (1966), Available from: http://www2.ohchr.org/english/law/cescr.htm. (Accessed 2011-10-04)

UN Universal Declaration of Human Rights (1948) Available from http://www.un.org/en/documents/udhr/ (Accessed 2011-10-04)

UN. Universal Declaration of Rights of Persons belonging to National or Ethnic, Religious and Linguistic Minorities. Available from: http://www2.ohchr.org/english/law/minorities.htm (Accessed 2011-10-04)

UNESCO Universal Declaration of Cultural Diversity (Paris, November, 2001). Available from http://unesdoc.unesco.org/images/0012/001271/127160m.pdf (Accessed 2011-10-04)


557

430343044305

43064307

43084309

43104311

43124313

http://unesdoc.unesco.org/images/0012/001271/127160m.pdf

http://www2.ohchr.org/english/law/minorities.htm

http://www.un.org/en/documents/udhr/

http://www2.ohchr.org/english/law/cescr.htm

CD ISO/IEC 15944-12:2014(E)

Abstracts

[Abstracts of the Part 12 standard in the languages in which the abstracts are available. Useful since ISO catalogue provides only the abstract in the language in which the standard is published].


559

4314

43154316

basic template for the development of iso and iso/iec...

Documents