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

© ISO 2015 – All rights reserved

Reference number of working document: ISO/IEC JTC 001/SC 32 /WG 01 N 0785Date: 2015-01-30

Reference number of document: ISO/CD 15944-12

Committee identification: ISO/IEC JTC 001/SC 32/WG 01

Secretariat: XXXX

Information technology — Business Operational View — Part 12: Privacy protection requirements on information life cycle management (ILCM) and EDI of personal informationTechnologies 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

Warning

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

/tt/file_convert/5e6e16037a243c71402e54b4/document.doc Basic template BASICEN3 2002-06-01

Document type: International standardDocument subtype: if applicableDocument stage: (20) PreparationDocument language: E

1

1

2

3

4

5

678

91011

12

13

1415

1617

18

23

ISO/IEC CD 15944-12

Copyright notice

This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the reproduction of working drafts or committee drafts in any form for use by participants in the ISO standards development process is permitted without prior permission from ISO, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior written permission from ISO.

Requests for permission to reproduce this document for the purpose of selling it should be addressed as shown below or to ISO’s member body in the country of the requester:

[Indicate :the full addresstelephone numberfax numbertelex numberand electronic mail address

as appropriate, of the Copyright Manager of the ISO member body responsible for the secretariat of the TC or SC within the framework of which the draft has been prepared]

Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.

Violators may be prosecuted.

II © ISO 2015 – All rights reserved

4

19

2021222324

2526

272829303132

3334

35

36

ISO/IEC 15944 CD 15944-12

Contents Page

Foreword............................................................................................................................................... viii0 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...............................................................................xiv0.6 Use of “identifier” (in a business transaction) and roles of an individual...........................xv0.7 Use of "jurisdictional domain" in the context of privacy protection and related ILCM

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

exchange................................................................................................................................... xv0.9 Use of set of recorded information (SRI) and set of personal information (SPI) versus

record, document, message, etc............................................................................................xvi0.10 Organization and description of this document....................................................................xvi1 Scope........................................................................................................................................... 11.1 Statement of scope.....................................................................................................................11.2 Exclusions................................................................................................................................... 21.2.1 Functional Services View (FSV).................................................................................................21.2.2 Internal behaviour of organizations (and public administration)............................................21.2.3 Overlap of and/or conflict among jurisdictional domains as sources of privacy protection

requirements............................................................................................................................... 21.2.4 Changes in jurisdictional domain of parties to a business transaction.................................31.2.5 Publicly available personal information....................................................................................31.3 Aspects currently not addressed..............................................................................................41.4 IT-systems environment neutrality............................................................................................62 Normative references.................................................................................................................72.1 ISO/IEC, ISO and ITU...................................................................................................................72.2 Referenced specifications..........................................................................................................93 Terms and definitions...............................................................................................................114 Symbols and abbreviations.....................................................................................................455 Fundamental privacy protection principles............................................................................495.1 Introduction............................................................................................................................... 505.2 Primary sources of privacy protection principles..................................................................505.3 Key eleven (11) privacy protection principles........................................................................515.4 Link to “consumer protection” and “individual accessibility” requirements......................525.5 Privacy protection principles in the context of ILCM requirements.....................................525.6 Requirement for tagging (or labelling) sets of personal information (SPIs) in support of

privacy protection requirements.............................................................................................536 Integrated set of information life cycle management (ILCM) principles in support of

information law and privacy protection requirements...........................................................556.1 Introduction – Primary purpose of Clause 6...........................................................................55

© ISO 2015 – All rights reserved III

6

37

38

3940414243444546474849505152535455565758

5960616263646566676869

707172

73

74

7576777879808182

838485

7

ISO/IEC CD 15944-12

6.2 Information life cycle management (ILCM) principles in support of privacy protection requirements............................................................................................................................. 57

6.2.1 Compliance with privacy protection (and associated information law) requirements.......576.2.2 Direct relevance, informed consent and openness...............................................................576.2.3 Ensuring that personal information is “under the control of” the organization throughout

its ILCM...................................................................................................................................... 596.2.4 Limiting Use, Disclosure and Retention.................................................................................596.2.5 Timely, accurate, relevant........................................................................................................626.2.6 Data integrity and quality.........................................................................................................636.2.7 Safeguards for non-authorized disclosure requirements.....................................................646.2.8 Back-up, retention and archiving............................................................................................656.2.9 Disposition and expungement.................................................................................................656.2.10 Organizational archiving..........................................................................................................666.2.11 Historical, statistical and/or research value...........................................................................666.3 Requirement for tagging (or labelling) data elements in support of privacy protection

requirements............................................................................................................................. 687 Rules governing ensuring accountability for and control of personal information............697.1 Introduction............................................................................................................................... 697.2 Key aspects of Open-edi requirements...................................................................................697.3 Key aspects of “under the control of”...................................................................................707.4 “under the control of” in support of privacy protection requirements and in an ILCM

context....................................................................................................................................... 707.5 Implementing “under the control of” and accountability......................................................718 Rules governing the specification of ILCM aspects of personal information......................778.1 Introduction............................................................................................................................... 778.2 Rules governing establishing ILCM responsibilities for personal information...................788.3 Rules governing establishing specifications for retention of personal information –

applicable “SRI retention triggers”.........................................................................................808.4 Rules governing identification and specification of state changes of personal information848.4.1 Introduction............................................................................................................................... 848.4.2 Specification of state changes allowed to personal information..........................................858.4.3 Specification of store change type..........................................................................................888.4.4 Rules governing specification of source of state changes...................................................908.5 Rules governing disposition of personal information...........................................................919 Data conversion, data migration, and data synchronization................................................979.1 Introduction............................................................................................................................... 979.2 Rules governing data conversion and data migration of personal information..................979.3 Rules governing requirements for data synchronization of personal information.............9810 Rules governing EDI of personal information between primary ILCM Person, i.e., the

seller, and its “agent”, “third party” and/or “regulator”......................................................10110.1 Introduction............................................................................................................................. 10110.2 ILCM rules pertaining to use of an “agent”..........................................................................10110.3 ILCM rules pertaining to use of a “third party”....................................................................10210.4 ILCM rules pertaining to involvement of a “regulator”........................................................10311 Conformance statement.........................................................................................................10511.1 Introduction............................................................................................................................. 10511.2 Conformance to the ISO/IEC 14662 Open-edi Reference Model and the multipart

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

English and ISO French language equivalency....................................................................107A.1 Introduction............................................................................................................................. 107A.2 ISO English and ISO French..................................................................................................107A.3 Cultural adaptability and quality control...............................................................................107A.4 Organization of Annex A – Consolidated list in matrix form...............................................108

IV © ISO 2015 – All rights reserved

8

8687888990919293949596979899100101

102103104105106107108

109110111112113114115116117118119

120121122123

124125126127128129

130131132133134135

136137138139140141

ISO/IEC 15944 CD 15944-12

A.5 List of added Part 12 terms and definitions with cultural adaptability: ISO English and ISO French...................................................................................................................................... 109

Annex B (informative) 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......119

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

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

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



relevance to supporting privacy protection requirements..................................................134Annex C (informative) 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 (informative) Generic approach to ILCM decisions in a privacy protection requirements

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

“transitory records”................................................................................................................149D.2.2 ILCM link to “post actualization” requirements...................................................................151Annex E (informative) Generic approach to identification of properties and behaviours of

personal information as SRI transitory records and their disposition/expungement.......153E.1 Introduction............................................................................................................................. 153E.2 Definition of the concept of “SRI transitory record”............................................................153E.3 Information on examples of “SRI transitory records”.........................................................154Annex X (informative) “VANs”, “outsourcing, “Clouds” etc., and information life cycle

management (ILCM) and EDI of personal information.........................................................157X.1 Introduction............................................................................................................................. 157X.2 Purpose.................................................................................................................................... 157X.3 Summary of role of “agent” or “third party” by a buyer in executing business

transactions............................................................................................................................. 158X.4 Information life cycle management (ILCM) aspects.............................................................158X.5 Summary of “Cloud computing” in ICT................................................................................158X.6 Conclusions - Cloud computing services and protection of personal information..........159Bibliography......................................................................................................................................... 160Abstracts................................................................................................................................................ 162

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..................................................................51Figure 4 — Illustration of roles and relationships between a “privacy protection officer (PPO)” and a

“personal information controller (PIC)” in an Open-edi business transaction indicating the link between the BOV and FSV.................................................................................................72

© ISO 2015 – All rights reserved V

10

142143

144145146147148149150151152153154155156157158

159160161162163164

165166167168169170171

172173174175176

177178179180181182183184185

186

187188

189190191192193194195

196

11

ISO/IEC CD 15944-12

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

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

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

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

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

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

values of SRIs containing personal information...................................................................87Table 5 — ISO/IEC 15944-12:05 Codes representing store change type for SPIs (and SRIs).............89Table 6 — ISO/IEC 15944-12:06 Codes representing source of state change type ID code for SRIs. 90Table 7 — ISO/IEC 15944-12:07 Codes representing disposition types as actions of personal

information (as SPIs)...............................................................................................................94Table A.1 — Columns in Table A.2..........................................................................................................108Table A.2 — List of added Part 12 terms and definitions with cultural adaptability of: ISO English

and ISO French language equivalency..............................................................................109

VI © ISO 2015 – All rights reserved

12

197198

199

200201202

203204205206207208209210211212213214215216

217218219220

ISO/IEC 15944 CD 15944-12

Project Co-Editors’ Notes:

1. This CD ballot document applies the results of the JTC1/SC32/WG1 Interim Toronto Meeting, 17-19 November, 2014. At the Toronto meeting the WD for this Part 12, i.e., document SC32/WG1 N0759, was reviewed and discussed in detail. The result of this review and decisions taken by SC32/WG1 at its Toronto interim meeting are found in document SC32/WG1/ N0779.

2. 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.

3. Finally, the Project Co-Editors for Part 12 have undertaken a 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)

4. The Project Co-Editors have reviewed these ISO standards as to their applicability to the development of this Part 12. Further, it is important to note that the Canadian expert contribution on “under the control of”, these three ISO TC 46 standards were reviewed and their applicability to Part 12 identified. {See document SC32/WG1 N0786}

5. Reorganization of Clauses 5+ and link to Part 8

P-members are requested to read the “Project Co-Editors Notes” at the start of Clause 5 below in order to understand the reorganization and contents of Clauses 5+.

6. Due to the re-organization and re-numbering of many rules, any internal cross references will be reviewed before the DIS stage and updated and changed accordingly. (Some have already been highlighted in the text for further action. Time and resources did not allow for a thorough review at this time).

© ISO 2015 – All rights reserved VII

14

221

222223224225

226227228229230

231232

233

234

235

236

237238239240

241

242243

244245246247

15

ISO/IEC CD 15944-12

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 2015 – All rights reserved

16

248

249250251252253254255

256

257258259

260261

262263

264265

266

267

268

269270

271

272

273

274

275

276

277

278279

ISO/IEC 15944 CD 15944-12

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.

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 2015 – All rights reserved IX

18

280

281

282283

284285

286

287288289290

291292293294295

296297298299300

301302303304

305306307

308

309

310311

312313

314

19

ISO/IEC CD 15944-12

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

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

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 (3rd ed. E/F) "Information technology — Open-edi Reference Model/Technologies de l'information — Modèle de référence EDI-ouvert" is an ISO “freely available standard ».

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.

X © ISO 2015 – All rights reserved

20

315316

317

318319320

321322323

324

325

326327328329

2122232425

262728

2930

3132

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

ISO/IEC 15944 CD 15944-12

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).

© ISO 2015 – All rights reserved XI

34

330331332

333334

335336337338

339

340

341342

343344345346347

348349350

351352

353354355

35

ISO/IEC CD 15944-12

XII © ISO 2015 – 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

36

356

357

358

359

360

361

ISO/IEC 15944 CD 15944-12

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

© ISO 2015 – All rights reserved XIII

38

362

363

364

39

ISO/IEC CD 15944-12

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:

based on both Part 5 and Part 8;

integrates applicable concepts and definitions, principles, rules, etc., found in both Parts 5 and Part 8; and,

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);

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 2015 – All rights reserved

40

365366367368

369

370371372

373

374375376377378

379

380381382383384385386387

388389390

391

392

393394

395396

397398

399

400401

41

4243

4445

ISO/IEC 15944 CD 15944-12

"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 the ISO/IEC 14662 and ISO/IEC 15944-1 standards. A "party" to a business transaction has the properties and behaviours of a "Person”.

0.4 Importance and role of terms and definitions8

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.

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.9

0.5 Standard based on rules and guidelines10

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."11

[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".

8 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.

9 The designation ISO before a natural language refers to the use of that natural language in ISO standards.

10 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”.

11 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…”

© ISO 2015 – All rights reserved XV

47

402403

404405406

407

408409410

411412413414

415416417418

419420421422

423

424425

426

427428429

430

431432433

48495051525354

55

5657

585960

61

ISO/IEC CD 15944-12

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.

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.12

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

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 instantiation of a business transaction.

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.

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 medium14 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.

12 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.

13 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.

14 “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”}.

XVI © ISO 2015 – All rights reserved

62

434435436

437438

439

440441442443444445

446447

448449450451452453454

455

456457

458459

460461462463464465

466467468469

63646566

676869

7071

ISO/IEC 15944 CD 15944-12

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, prescribed 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 of personal information (SPI) versus record, document, message, etc.

The concepts of “record”, “document”, ‘data”, “message”, etc., are defined and used in ISO standards and in different 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.

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)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

Project Co-Editors’ Note:

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/complete as part of the preparation of the DIS document]

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.

© ISO 2015 – All rights reserved XVII

73

470471472473474475476477

478479

480481482483484

485486487488

489490491492

493494495

496497498499500501

502

503

504505

506507508

509

510

511512513

74

ISO/IEC CD 15944-12

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 as part of the DIS document]]

XVIII © ISO 2015 – All rights reserved

75

514515516

517

518

COMMITTEE DRAFT ISO/IEC CD 15944-12

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 buyers15 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.

15 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 2015 – All rights reserved 1

77

519

520

521

522

523

524525526527528

529

530531532533534535

536537538539540541

542543544545

546547

548549

787980

COMMITTEE DRAFT ISO/IEC CD 15944-12

1.2 Exclusions16

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 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.).

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


82

550

551

552553554555556557558

559

560561562563564

565566

567568569570

571572573

574575

576577578579

580581582583584585

586587588

589590591592

83

ISO/IEC 15944 CD 15944-12

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

1.2.4 Changes in jurisdictional domain of parties to a business transaction

It may be that during the lifetime of all phases of a business transaction that the physical location of the buyer and seller changes. It may also be that the jurisdictional domain of the physical location of the buyer and/or seller changes, and thus possibly also the regulator where applicable.17

This Part 12 of ISO/IEC 15944 like Part 8 is based on the assumption that the external constraints including those of a privacy protection nature of the jurisdictional domain of the buyer apply.18

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


1. 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.

2. 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.

3. 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.

1.2.5 Publicly available personal information19

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).

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

17 Changes of this nature were not uncommon in the early 199s, (e.g., re: East Germany, Soviet Union, Yugoslavia). Changes of this nature are less common at present. At the same time, sources of external constraint of jurisdictional domains may evolve to a higher level of international regulatory regimes. {See further Clause 7 “Rules governing the formation and referencing of jurisdictional domains” and Annex H (Informative) “Levels of international regulatory regimes” in ISO/IEC 5944-8.

18 Add footnote on which rule(s) in Part 8 apply here + Clause number.

19 For more detailed text on this matter, see Clause 1.2.5 in ISO/IEC 15944-8.

20 For example, in July 2014, the Irish Data Protection Commissioner ordered the 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).


85

593594

595

596597598

599600

601602

603

604605606

607608609610611612

613614615

616

617618619

620621

8687888990

919293949596979899

100101

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

ISO/IEC CD 15944-12

1.3 Aspects currently not addressed


1. At the Toronto SC32/WG1 meeting it was decided that “23” entries in Clause 1.3 Aspects not currently addressed should be grouped/consolidated.

2. In doing this, the Project Co-Editors found that some of these “23” issues duplicated those already identified in Clause 1.3 of Part 8. Therefore, the approach taken below is to:

simply reference Clause 1.3 in Part 8 and state that these issues also apply to Part 12; and, list in Part 12 only those “new” or different issues especially those of an ILCM nature.

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

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,

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

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

4. 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.

1) Linkage to ISO/IEC 15944-8:2012

Rule 001:“Aspects not currently addressed” as identified in Clause 1.3 of ISO/IEC 15944-8:2012 also apply to this Part 12.

On the whole ISO/IEC 15944-12 can be considered as focusing on ILCM aspects at a more granular level than ISO/IEC 15944-8, which is more generic in nature. Any “aspects not yet addressed” which are already identified in Part 8 also apply to this Part 12.

2) “organization Person”

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

4 © ISO 2015 – All rights reserved

103

622

623

624625

626627

628629

630631

632633634635636637

638639

640641642

643

644

645646

647

648649

650

651

652

653654655656657658659

660

661662

ISO/IEC 15944 CD 15944-12

“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.

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)”}

3) data mining 21 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 examination22.

4) “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 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

21 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.

22 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. {See also Annex X “VANs”, “outsourcing”, “Clouds”, etc., and information life cycle management (ILCM) and EDI of personal information below}


105

663664665666667668

669670671672673674675

676677678679680681682

683

684685686687688

689

690691692693

694695696697698699700701702

106107108109110

111112113114115116117

ISO/IEC CD 15944-12

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) 23

5) 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

6) 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.

It is anticipated that some or all of these requirements will be addressed in future editions of ISO/IEC 15944-12 (or Part 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.

23 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.


119

703704

705706707

708709

710711712713714715716

717718719

720721722723

724725

726

727728729730731732

120121122123

ISO/IEC 15944 CD 15944-12

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 ITU24

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

24 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.


125

733

734

735

736737738

739740

741742743

744745746

747

748749

750751

752753

754755756

757758759

760

761762

763764765766

767768769770

126127128129

ISO/IEC CD 15944-12

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 13008-12 Information and document - Digital records conversion and migration practice;

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 15489-1:2001 – Information and document management - Part 1: General Concepts and principles (being revised and renamed)

ISO 15489-2:2001 – Information and document management - Part 2: Guidelines (being revised)

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.225

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

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


131

771772

773774

775776

777

778779

780781

782

783784

785786

787

788789

790791

792793

794795

796797

798799

800

801

802

803804

805806

132

ISO/IEC 15944 CD 15944-12

2.2 Referenced specifications26

APEC Privacy Framework. (2005)

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)

26 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.


134

807

808

809

810811812

813

814

815

135136137138

ISO/IEC CD 15944-12

THIS PAGE INTENTIONALLY LEFT BLANK


140

816

817

818

819

820

821

822

823

824

825

826

827

828

829

830

831

832

833

834

835

ISO/IEC 15944 CD 15944-12

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. At the SC32/WG1 Toronto interim meetings Clause 3 Definitions was reviewed especially the new definitions introduced in Part 12. {See further Annex A}

4. It was also agreed that the concept of “under the control of” needed to be added and defined. This is a rather important matter and therefore an informative Annex has been added to explain this concept. Whether this new Annex will stay in Part 12 or become a reference-able document can be decided as part of the CD ballot resolution meeting.

5. The introduction of the concept “under the control of” is to be introduced 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:

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; or,

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.

6. In addition, it was pointed out at the SC32/WG1, Toronto interim meetings that all the definitions in ISO standards are now listed in the ISO Online Browsing Platform (OBP) https://www.iso.org/obp/ui/. As these are stand-alone entries, it is important that where an acronym is used in a definition the full text also appear. This is necessary to make the definition understandable as a “stand-alone” entry. Consequently, this has been applied in the definitions below.

7. 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.

8. 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.


142

836

837

838839

840841842

843844

845846847848

849850851

852853

854855

856857858859860861862

863864865866867

868869870

871872873

874

875876877878

879

https://www.iso.org/obp/ui/

ISO/IEC CD 15944-12

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.5authenticationprovision of assurance of the claimed identity of an entity

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

3.6authenticityproperty 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.7back-up copy of datacopy 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


144

880881

882883

884

885886887

888889890

891

892893894895

896

897

898899900

901

902903904

905

906907908909

910

911

912913914915916917918

ISO/IEC 15944 CD 15944-12

3.8businessseries 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.9business 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.10business 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.11Business Operational ViewBOVperspective 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.12business 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

[ISO/IEC 14662:2010, 3.4]

3.13business transaction audit 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.14business transaction identifierBTIidentifier assigned by a seller or a regulator to an instantiated business transaction among the Persons involved


146

919920921922923

924

925926927

928929930

931932933

934

935936937938

939

940

941942943944945

946

947948949950951

952

953954955956957958959

960961962963964

ISO/IEC CD 15944-12

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.

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

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


148

965966

967968969

970971

972973974

975

976977978979

980

981982983

984

985

986987988

989

990

991992993994995

996997

9989991000

1001

1002

100310041005

ISO/IEC 15944 CD 15944-12

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]

3.22coded Domain Registration SchemacdRSformal 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]


150

10061007

1008

1009101010111012

1013

101410151016101710181019

10201021

1022

10231024

10251026

1027

10281029

10301031

103210331034

103510361037

1038

1039

1040

104110421043104410451046

1047

ISO/IEC CD 15944-12

3.23coded domain Source AuthoritycdSAPerson, 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]

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]


152

1048104910501051

10521053

10541055

10561057

1058

1059106010611062

106310641065

1066

1067106810691070

1071

1072107310741075

1076

1077

1078107910801081

1082

10831084108510861087

10881089

1090

ISO/IEC 15944 CD 15944-12

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.

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

3.31controlled vocabularyCVvocabulary 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.


154

109110921093

10941095

10961097

109810991100

1101

1102110311041105

11061107

110811091110

11111112

1113

111411151116111711181119

112011211122

112311241125

11261127

1128

11291130113111321133

1134

ISO/IEC CD 15944-12

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 of changing data, i.e., as set(s) of recorded information (SRI(s), from one format or representation to another while maintaining the characteristics of the SRIs including the authenticity, integrity, reliability and usability of the sets of recorded information (SRI(s)) as well as relevant information life cycle management (ILCM) requirements, and especially those of an external constraints nature including privacy protection requirements where the data involves personal information

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

EXAMPLE 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 2 A data conversion does not change the content value of the SRI(s).

[SOURCE Adapted from CAN/CGSB-72.34-2005, 3.16 and ISO 13008:2001, 3.5]

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]

3.36data migrationprocess of moving data, i.e., as sets of recorded information (SRIs) including their existing characteristics from one IT System, (e.g., hardware or software configuration) to another, as required by changes in an IT System configuration or as requested by the user, while assuring that the SRI(s) will remain addressable and that data authenticity, integrity, reliability and useability of the SRI(s) will be maintained in the new environment


156

11351136

11371138

1139

1140

1141114211431144

1145

1146114711481149115011511152

11531154

11551156

1157

115811591160116111621163

1164

116511661167

1168

1169

1170

1171117211731174117511761177

ISO/IEC 15944 CD 15944-12

NOTE 1 Data migration does not change the format or the content of the SRIs

EXAMPLE [PEs to provide]

[SOURCE Adapted from ISO 13008:2012, 3.12]

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 (SRI(s)) 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 (SRI(s)) is the same in the IT systems of all the participating parties

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

3.40Decision Making ApplicationDMAmodel 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]


158

1178

1179

1180

118111821183

118411851186

1187

118811891190

1191

11921193119411951196

1197

119811991200120112021203

1204

12051206120712081209

1210

121112121213

1214

121512161217

1218

ISO/IEC CD 15944-12

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 InterchangeEDIautomated 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.


160

121912201221

1222

1223

1224

122512261227

1228

1229123012311232

1233

123412351236

12371238

1239

1240

1241124212431244

1245

12461247124812491250

1251

1252

1253125412551256125712581259

ISO/IEC 15944 CD 15944-12

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]


162

126012611262

1263

1264

1265

126612671268

1269

127012711272

1273

1274

1275127612771278

12791280

12811282

12831284

12851286

1287

1288

1289

12901291

12921293

129412951296

1297

ISO/IEC CD 15944-12

3.53Formal Description TechniqueFDTspecification 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 ViewFSVperspective 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 EquivalentHIErepresentation 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".


164

129812991300130113021303

1304

13051306130713081309

1310

131113121313131413151316

13171318

13191320

13211322

1323

132413251326

1327

132813291330

1331

13321333

13341335

133613371338

133913401341

ISO/IEC 15944 CD 15944-12

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]

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 identityiiPerson 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


166

1342

1343

1344134513461347

1348

1349135013511352

1353

13541355

1356

1357135813591360

1361

13621363136413651366

13671368

136913701371

1372

1373137413751376

1377137813791380

138113821383138413851386

ISO/IEC CD 15944-12

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

3.65individual persona Registration SchemaipRSpersona 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 BundleIBformal 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 life cycle managementILCMseries 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.

3.69Information Processing DomainIPDInformation 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.70Information Technology SystemIT Systemset 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


168

1387

13881389139013911392

139313941395

139613971398

1399

14001401140214031404

1405

1406140714081409141014111412

1413

141414151416141714181419

1420

142114221423142414251426

1427

142814291430143114321433

ISO/IEC 15944 CD 15944-12

[ISO/IEC 14662:2010, 3.13]

3.71internal 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]

3.72IT-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.73IT-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.74jurisdictional 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.


170

1434

1435143614371438

143914401441

1442

14431444144514461447

1448

14491450145114521453

14541455

1456

14571458

1459

1460

1461

1462

14631464146514661467

1468146914701471

14721473

14741475

1476

ISO/IEC CD 15944-12

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]

3.75jurisdictional 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.76languagesystem 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.77language 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.78legally recognized languageLRLnatural 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.79legally recognized nameLRNpersona 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 legally recognized name (LRN) is a member


172

1477147814791480

14811482

1483

1484148514861487

1488

148914901491

14921493

1494

149514961497

1498

1499

1500

1501150215031504150515061507

15081509

15101511

1512

151315141515151615171518

ISO/IEC 15944 CD 15944-12

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]

3.80listordered set of data elements

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

3.81localizationpertaining 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.82locationplace, either physical or electronic, that can be defined as an address

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

3.83mediumphysical 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]


174

151915201521

1522

152315241525

1526

1527

152815291530

1531

1532153315341535153615371538

1539

1540

154115421543

1544

15451546154715481549

1550155115521553

1554

155515561557

1558155915601561

1562

ISO/IEC CD 15944-12

3.84modelabstraction of some aspect of reality

[ISO 19115:2003, 4.9]

3.85multilingualismability 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]

3.86mutually defined - recognized individual identitymd-riirecognized 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.87namedesignation of an object by a linguistic expression

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

3.88natural 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.89objectanything 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.90object 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]


176

156315641565

1566

15671568156915701571

1572

15731574157515761577

15781579

15801581

15821583

1584

158515861587

1588

1589159015911592

1593

159415951596

15971598

1599

1600160116021603

1604

ISO/IEC 15944 CD 15944-12

3.91official 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.

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.92Open-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.93Open-edi Description TechniqueOeDTspecification 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 Business Operational View (BOV) concepts, in a computer processable form

[ISO/IEC 14662:2010, 3.16]


178

160516061607160816091610

16111612

16131614

161516161617

16181619

162016211622

16231624

162516261627

16281629

1630

16311632

16331634

16351636

1637

1638163916401641

1642

164316441645164616471648

1649

ISO/IEC CD 15944-12

3.94Open-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.95Open-edi PartyOePPerson 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]

3.96Open-edi record retention and disposal scheduleOe-RRDSspecification 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.97Open-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.98organizationunique 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.99organization partany department, service or other entity within an organization, which needs to be identified for information interchange

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


180

16501651165216531654

1655

1656

1657165816591660

16611662

1663

166416651666166716681669

1670

1671167216731674

1675

1676167716781679

1680

1681

168216831684

16851686

1687

1688168916901691

1692

ISO/IEC 15944 CD 15944-12

3.100organization 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.101Personentity, 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)

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.102Person 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.103personaset 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.104persona Registration SchemapRSformal 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.105personal informationany information on or about an identifiable individual that is recorded in any form, including electronically or on paper


182

1693169416951696

1697

16981699

1700

1701

1702

1703170417051706

17071708

17091710

17111712

1713

1714171517161717

1718

1719172017211722

1723

17241725172617271728

1729

1730

1731173217331734

ISO/IEC CD 15944-12

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

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


1. The concept and draft definition of “personal information controller” is linked to:

the concept and definition of “under the control of”; and,

the widely used concepts and (legal) definitions of “controller” and “processes” as found in the EU Directives 95/46.

2. The concept and (draft) definition of “personal information controller” (PIC) also serves as a bridge between:

the BOV view as found in the concept and definition of “privacy protection officer” (PPO) whose overall focus is on “governance”, etc.; and,

the FSV and data processing aspects.

3. P-members are encouraged to make comments on this matter.{See also draft Clause 3.106 as well as Clause 7 below}

3.106personal information controllerPICorganization Person authorized and so formally designated by the organization to ensure that personal information remains (fully) under the control of the organization and ensure its integrity in compliance with applicable privacy protection requirements including in any use by the organization of agents and/or third parties in support of a business transaction(s)

NOTE An organization may authorize and designate its privacy protection officer (PPO) to also function in the role of its personal information controller (PIC).

3.107Person identityPicombination of personal information and identifier used by a Person in a business transaction

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

3.108Person 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]

3.109personal 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]


184

17351736

1737

173817391740

1741

17421743

17441745

17461747

1748

17491750

17511752175317541755175617571758175917601761

1762176317641765

1766

1767176817691770

1771

1772177317741775

1776

ISO/IEC 15944 CD 15944-12

3.110physical 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.111pivot 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.112pivot 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.113principlefundamental, 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.114privacy collaboration spacePCSmodelling 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 privacy protection requirements apply to personal information of that individual provided in that business transaction

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


186

17771778177917801781

1782

1783178417851786

17871788

1789

17901791

1792

1793179417951796

179717981799

1800

1801180218031804

1805

1806

1807

1808

1809

1810181118121813181418151816

1817

ISO/IEC CD 15944-12

3.115privacy 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.116privacy protection officerPPOorganization 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.117processseries 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.118processing 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.119propertypeculiarity common to all members of an object class

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

3.120pseudonymuse 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.


188

181818191820182118221823

182418251826

182718281829

18301831

1832

183318341835183618371838183918401841

1842

1843184418451846

1847

184818491850185118521853

1854

185518561857

1858

1859186018611862

1863

ISO/IEC 15944 CD 15944-12

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

3.121pseudonymizationparticular 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.122public 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.123public 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.124publicly available personal informationPAPIpersonal 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]

3.125recognized individual identityriiidentity of an individual, i.e., individual identity, established to the extent necessary for the specific purpose of a business transaction


190

1864

1865186618671868

1869

1870

1871187218731874

1875

187618771878187918801881

188218831884

1885188618871888

188918901891

1892

189318941895189618971898

18991900

19011902

1903

19041905190619071908

ISO/IEC CD 15944-12

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

3.126recognized individual nameRINpersona 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.127recognized Person identityrPiidentity 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.128recorded 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.129registerset of files containing identifiers assigned to items with descriptions of the associated items

[ISO 19135:2005, 4.1.9]

3.130registrationrule-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 Open Edi Registry Item (OeRI)

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

3.131Registration AuthorityRAPerson 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)

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


192

1909

1910191119121913

19141915

1916

19171918

1919

19201921192219231924

1925

1926192719281929

19301931

1932

193319341935

1936

193719381939

1940

1941194219431944

1945

19461947194819491950

1951

ISO/IEC 15944 CD 15944-12

3.132Registration Authority IdentifierRAIidentifier assigned to a Registration Authority (RA)

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

3.133Registration SchemaRSformal 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.134Registration Schema (based) –recognized individual identityRS-riirecognized 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.135registryinformation system on which a register is maintained

[ISO19135:2005, 4.1.13]

3.136regulatorPerson 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.137regulatory business transactionRBTclass 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]


194

1952195319541955

1956

19571958195919601961

1962

196319641965196619671968

1969

197019711972

1973

19741975197619771978

1979

19801981198219831984

19851986

19871988

1989

19901991

1992

19931994

1995

ISO/IEC CD 15944-12

3.138retention periodlength of time for which data on a data medium is to be preserved

[ISO/IEC 2382-12:1988, 12.04.11]

3.139rolespecification which models an external intended behaviour (as allowed within a scenario) of an Open-edi Party

[ISO/IEC 14662:2010, 3.25]

3.140rulestatement 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.141rulebasepre-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.142SC identifierunique, linguistically neutral, unambiguous, referenceable identifier of a Semantic Component

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

3.143scenario 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]


196

199619971998

1999

2000200120022003

2004

200520062007

20082009

2010

2011201220132014

20152016

2017

20182019

2020

202120222023

2024

2025

202620272028

2029

2030203120322033

2034

ISO/IEC 15944 CD 15944-12

3.144scenario componentone of the three fundamental elements of a scenario, namely role, Information Bundle, and Semantic Component

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

3.145scenario contentset of recorded information (SRI) 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.146scenario specification attributeany attribute of a scenario, role, Information Bundle, and/or Semantic Component

[ISO/IEC 15944-2 2014, 3.106]

3.147sellerPerson 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.148Semantic ComponentSCunit 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.149semantic identifierSIIT-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.150set of personal informationSPIset of recorded information (SRI) which is of the nature of or contains personal information


198

2035203620372038

2039

2040204120422043

2044

204520462047

2048

20492050205120522053

2054

20552056205720582059

2060

2061

2062206320642065206620672068

20692070

2071

2072207320742075

ISO/IEC CD 15944-12

3.151set of recorded informationSRIrecorded 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:2014, 3.137]

3.152Source AuthoritySAPerson 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.153special 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.154SRI destruction

process of eliminating or deleting a set of recorded information, beyond any possible reconstruction


200

207620772078207920802081

20822083

20842085

20862087

2088

2089209020912092

20932094

2095

20962097

2098

20992100

21012102

21032104

2105

2106210721082109

21102111

2112

21132114

2115

ISO/IEC 15944 CD 15944-12

3.155SRI 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.156SRI integrity(of records) reliability and trustworthiness of sets of recorded information (SRI(s)) 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 sets of recorded information (SRI(s))

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 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.157SRI life cyclestages in the life cycle of a set of recorded information (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 set of recorded information (SRI); its storage, maintenance and protection; its archival preservation or destruction or expungement

3.158SRI retention periodspecified period of time that sets of recorded information (SRI(s)) are kept by a Person in order to meet operational, legal, regulatory, fiscal or other requirements

3.159standarddocumented 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.160termdesignation 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.161textdata 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]


202

211621172118211921202121212221232124212521262127

2128212921302131

21322133

213421352136213721382139

2140214121422143

21442145214621472148

21492150

2151

215221532154

2155

2156

21572158215921602161

2162

2163

ISO/IEC CD 15944-12

3.162third 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]

3.163transitory recordset of recorded information (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 set of recorded information (SRI)

NOTE A transitory SRI is expunged at the end of a short existence.

3.164treatyinternational 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.165truncated 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.166truncated recognized nameTRNtruncated 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).


204

21642165216621672168

2169

2170

2171217221732174217521762177

2178217921802181

2182

218321842185

218621872188

21892190

219121922193

2194

2195

2196219721982199

2200

2201220222032204

22052206

2207

ISO/IEC 15944 CD 15944-12

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

3.167truncationrule-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]

3.168unambiguouslevel 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]


1. At the Toronto interim meetings November 2014 of SC32/WG1 it was resolved that “under the control of” is a very important and relevant concept in the context of (1) information life cycle management and EDI; and, (2) especially being able to meet privacy protection requirements.

2. While an intuitive concept, developing an ISO definition in an ILCM and EDI context and meeting privacy protection requirements has proved to be somewhat problematic.

3. Therefore, a Canadian expert was asked to undertake research on this issue. The results of this detailed and thorough work are found in the SC32/WG1 N0786 document titled “Background information and literature review of information for the development of an ISO/IEC 15944-12 definition of “under the control of”.

4. Key concepts which are essential elements of the definition of “:under the control” include:

1. set of recorded information (SRI)

2. information life cycle management (ILCM)

information law

5. Comments are invited on the (draft) definition of « under the control of » as part of CD ballot comments. This will allow the definition for this concept to be finalized for the DIS ballot document for Part 12. See also Clause 7 below.

3.169under the control of


1. To be inserted based on P-members review of Clause 7 (below) and the detailed contribution by M. Janice Pereira, Canadian expert on this matter (See JTC1/SC32/WG1 document N0786)

2. P-members are requested to make CD ballot comments on this matter, as part of their comments on Clause 7. These will be addressed and resolved as part of the Glasgow meetings.

3. The draft definition to be discussed is as follows:


206

2208

2209221022112212

22132214

2215

2216221722182219

2220

2221

222222232224

22252226

2227222822292230

2231

2232

2233

2234

223522362237

22382239224022412242

22432244

22452246

2247

ISO/IEC CD 15944-12

set of requirements on an organization, especially those of external constraint nature, i.e., privacy protection and related information law requirements, requiring full and complete information life cycle management (ILCM) of personal information as set(s) of recorded information (SRIs) including state changes to the content values of the SRIs with respect to their creation/collection, recording processing, organization, storage, use, retrieval, disclosure, retrieval, aggregation, dissemination, disposition (including expungement), electronic data interchange (EDI), etc., and in particular that of any and all state changes in the decision making application (DMAs) of the organization and any of its agents and/or third parties (as well as any other parties) to the business transaction

3.170vendorseller 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.171vocabularyterminological 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]


208

22482249225022512252225322542255

2256225722582259

22602261

22622263

2264

226522662267

2268

2269

ISO/IEC 15944 CD 15944-12

4 Symbols and abbreviations


1. The entries in Clause 4 will be reviewed and amended in the preparation of the DIS ballot 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 these 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


210

2270

2271

22722273

227422752276

2277

2278

2279

2280

2281

2282

2283

2284

2285

2286

2287

2288

2289

2290

2291

2292

2293

2294

2295

2296

2297

2298

2299

2300

2301

ISO/IEC CD 15944-12

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


Part 4 ISO/IEC 15944-4Part 5 ISO/IEC 15944-5






PIC personal information controller

PPO privacy protection officer


212

2302

2303

2304

2305

2306

2307

2308

2309

2310

2311

2312

2313

2314

2315

2316

2317

2318

2319

2320

2321

2322

2323

2324

2325

2326

2327

2328

2329

2330

2331

2332

ISO/IEC 15944 CD 15944-12

PCS privacy collaboration space

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


214

2333

2334

2335

2336

2337

2338

2339

2340

2341

2342

2343

2344

2345

2346

2347

2348

2349

2350

ISO/IEC CD 15944-12



216

2351

2352

ISO/IEC 15944 CD 15944-12

5 Fundamental privacy protection principles


1. At the November, 2014 Toronto interim meeting of SC32/WG1, the comments on the WD for Part 12. {See Sc32/WG1 N0759} were reviewed and the comments made discussed and resolved. It was noted that there was an “overlap” between:

(a) proposed normative text in Clause 5 and Clause 6 in the WD for Part 12; and,

(b) proposed text in Clauses 5 through 7 in Part 12 and normative text in Part 5.

As a result, the text in Clause 5 has been shortened and the 13 rules and associated text moved to or integrated into Clause 6+. The approach is that of:

(a) positioning Part 8 being “generic” in nature focusing on the key primitive aspects of privacy protection requirements as external constraints on (modelling) business transactions; and,

(b) positioning Part 12 as focusing on ILCM and EDI aspects of privacy protection requirements.

This includes: 1) addressing Part 8 generic privacy protection requirements at a more granular level; and, 2) incorporating ILCM aspects as and where required.

2. At the same time, it was noted that Part 8 contains normative text, rules and coded domains which were placed in two normative Annexes with the intention that they would serve as the basis for key Clauses in a new Part 12 which focuses on ILCM and EDI aspects of privacy protection requirements. As such, the development of this 1 st edition of Part 12 is based on a migration strategy of normative text found in the 1st edition of Part 8 to 2nd edition of Part 8 which were discussed and agreed to by SC32/WG1 during the past few years in the development of the ISO/IEC 15944-12 standard. This migration strategy is summarized as follows:

A. The development of Part 8 focused on the more primitive and generic aspects of privacy protection requirements. At the same time, it was recognized that added standards development work was needed to specify ILCM and EDI requirements needed for users to be able to facilitate their implementation of privacy protection requirements. However, these user (implementation) needs were at a more granular level than the scope and focus of Part 8. The decision taken by SC32/WG1 via its ballot comments was to place normative text in Part 8 of an ILCM and EDI nature into two normative Annexes in Part 8 as Annexes D and E whose titles are:

Annex D (normative) integrated set of information life cycle management (ILCM) principles in support of information law compliance;

Annex E (normative) Key existing concepts and definitions applicable to the establishment, management and use of identities of a single individual.

B. Planned future development of 2 nd edition of Part 8

B.1 When Part 12 becomes an ISO international standard, then in the 2nd edition of Part 8:

(a) its current normative Annexes D and E can be deleted because their normative text, rules and coded domains pertaining to more granular ILCM and EDI aspects being found in Part 12; and,

(b) the development of the 2nd edition of Part 8 using the minor revision process to amend Part 8 accordingly to reference, i.e., “redirect”, its present 1st edition references to normative Annexes D and E to the appropriate references to Clauses, rules, coded domains, etc., in Part 12.

B.2 Once the 2nd edition of Part 8 passes the FDIS stage, then SC32/WG1 will be in a position to amend the 1st edition of Part 12 accordingly using the minor revision process.


218

2353

2354

235523562357

2358

2359

23602361

23622363

2364

23652366

2367236823692370237123722373

2374237523762377237823792380

238123822383238423852386

2387

23882389

239023912392

23932394

ISO/IEC CD 15944-12

3. The above text represents the understanding of Project Co-Editors of their work in support of the development of Part 8 and Part 12 of ISO/IEC 15944.

4. The matter will be discussed at the Glasgow 19=21 May 2015 SC3/WG1 meeting. CD ballot comments are welcome.

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”.

Rule 002: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.


220

23952396

23972398

2399

2400

2401240224032404

240524062407

2408

24092410

ISO/IEC 15944 CD 15944-12

Figure 3 — Primary sources for privacy protection principles

5.3 Key eleven (11) privacy protection principles

Rule 003:Clause 5.3 “Fundamental privacy protection principles” in Part 8 provides eleven (11) principles, rules and associated normative 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


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

222

2411

2412

2413

241424152416

2417

24182419242024212422242324242425242624272428

ISO/IEC CD 15944-12

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 transaction27.

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 Link to “consumer protection” and “individual accessibility” requirements


1. The Project Co-Editors request P-members and participating experts to provide input as to whether or not Clause 5.4 should be supported by one or more rules referencing applicable international ISO standards as normative references and/or part of guidelines to such a rule.

2. P-members are requested to do so via their CD ballot comments

This Part 12 like Parts 5 and 8 of the multipart ISO/IEC 15944 standard 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.

5.5 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.

Rule 004:An individual , as a buyer in a business transaction, shall be able to challenge the timeliness and accuracy of his or her personal information including ILCM aspects including any state changes to the content value of such a set of personal information (SPI) as part of the ILCM of the organization in accordance with other applicable information law requirements, including retention, and

27 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 (3rd edition) and its Figure 3 Open-edi system relationships.


224

24292430

24312432243324342435243624372438

2439244024412442

2443

2444

244524462447

2448

24492450

245124522453

245424552456

2457

24582459

2460

2461

24622463

24642465246624672468

225226227

ISO/IEC 15944 CD 15944-12

expungement, as well as with respect to any ILCM management of a privacy protection requirements nature, in a use by the seller organization of an agent and/or third party to a business transaction.

5.6 Requirement for tagging (or labelling) sets of personal information (SPIs) in support of privacy protection requirements28

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.

28 The requirements and rules stated in Part 8, Clause 5.4 apply here.


229

24692470

2471

24722473

247424752476247724782479

230

ISO/IEC CD 15944-12



232

2480

2481

2482

2483

2484

2485

2486

2487

2488

2489

2490

2491

2492

2493

2494

2495

2496

2497

2498

2499

2500

2501

2502

2503

ISO/IEC 15944 CD 15944-12

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


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. The primary reason why text in Part 8 was placed in a normative Annex D was so that it could be “moved” to an (eventual) new Part of ISO/IEC 15944 (or serve as the basis for the same).

When Part 12 becomes an IS then in the 2nd edition of Part 8 the Annex D can be deleted and references including footnotes in Part 8 to Annex D will be changed to reference the relevant (sub-) clause in Part 12.

3. One of the decisions of the SC32/WG1 interim November 2014 Toronto meeting was to minimize overlap/duplication between existing normative text, including rules, in Part 8 and this new Part 12. Consequently, P-members in preparing their Part 12 CD ballot comments are encouraged to identify such “overlap/duplication” between existing Part 8 and this Part 12 CD document.

4. 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 CD 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:

29 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.


234

25042505

2506

25072508

25092510

25112512

2513251425152516

251725182519

2520

252125222523252425252526252725282529

2530253125322533

2534253525362537

25382539254025412542

254325442545

25462547

235236

ISO/IEC CD 15944-12

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 information30;

require one to submit or file personal information to a government or regulatory agency;

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

The focus of Clause 6 is that of ILCM principles in support of enabling an organization to be able to comply with privacy protection requirements applicable to personal information. It does so in the context of a business transaction where the (prospective) buyer is an individual and those most, if not all, of the sets of recorded information (SRI(s)) pertaining to that business transaction are sets of personal information (SP1s).31

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 005:Where external constraints (of a relevant jurisdictional domain(s)), with respect to privacy protection requirements to a business transaction apply, the Person as a seller shall ensure that such privacy

30 See further below Clause 7.4 “Rules governing specification of state changes of personal information”.

31 It is up to users and implementers of this standard to decide whether or not to extend privacy protection ILCM requirements to other types of SRIs under the control of their organization and/or in their EDI, (e.g., with respect to SRIs interchanged as IBs and their SCs with respect to business transactions of a “B2B” (business-to-business) or “B2G” (Business-to-government/government-to-business) nature.


238

2548

2549

2550

2551

25522553

2554

2555

2556

2557

2558

2559

2560

2561

2562256325642565256625672568

256925702571

2572257325742575

25762577

2578

257925802581

239

240241242243

ISO/IEC 15944 CD 15944-12

protection requirements are identified and supported. This generic rule also applies to the identification of any and all ILCM related requirements.

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 005G1: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; (b) these need to include any and all applicable ILCM requirements; and, (c) should be in full compliance with such information law requirements.

6.2.2 Direct relevance, informed consent and openness

Rule 006: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, including applicable ILCM requirements.

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.

As to what is personal information of direct relevance to a business transaction is determined by the goal of the business transaction.

Each business transaction pertains to a specific and specified goal which the parties to the transaction have committed themselves.32

Rule 007:In specifying the goal of a business transaction, 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.

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 for the set of personal information (SPI) depends on the type of business 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 are to be dealt with in rules/guidelines which must be linked to RRDS.

Rule 008:

32 This Clause and its rules complement those of Part 8, Clause 5.3.3 which applies here.


245

25822583

25842585258625872588

258925902591

25922593259425952596259725982599

2600260126022603

26042605

26062607

26082609

2610261126122613

261426152616

26172618

26192620262126222623262426252626

2627

246

ISO/IEC CD 15944-12

As part of the identifying purpose, the seller shall state to the potential buyer, when this is 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 009:The default rule, in support of Rule 008 above, is that if the individual does not provide explicit consent that such personal information will be expunged by the seller, or as soon as possible as permitted by applicable information law requirements.

Rule 010:As part of identifying purpose, the organization collecting or creating the personal information in the context of the specified business 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.

Rule 011:The default rule is that if the individual (as the prospective buyer) needs to be formally/explicitly requested to provide his/her informed consent for (a) the seller (organization) to share her/his personal information with other organizations; and, (b) under which explicitly stated ILCM and “under the control of” conditions with any and all other organizations.

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 012:The principle of informed consent applies to any and all ILCM aspects of the personal information created or collected as may be required.

Guideline 012G1: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.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.33

Rule 013: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.6.2.3 Ensuring that personal information is “under the control of” the organization throughout its ILCM


1. Based on the results of the discussion and decisions of the Toronto November 2014 interim SC32/WG1 meeting, it was deemed necessary to make “under the control of” a separate ILCM principle in support of privacy protection requirements.

2. In the WD document the title of the Clause was “Timely, Accurate relevant and “under the control of””. This Clause 6.32 positions “under the control of” as a separate and distinct ILCM principle. This new

33 This Clause and its rules complement those of Part 8, Clause 5.3.9 which apply here.


248

2628262926302631

2632263326342635

26362637263826392640

26412642264326442645

264626472648264926502651265226532654

2655265626572658

26592660266126622663

2664266526662667266826692670

2671

267226732674

26752676

249

ISO/IEC 15944 CD 15944-12

Clause 6.2.3 basically states the ILCM principle and refers to Clause 7 below where mo4re detailed rules, definitions, and normative text is presented.

Rule 014:An organization shall ensure that any personal information pertaining to a business transaction remains completely “under the control of “ that organization (at all times) including any EDI as well as its use of agents and/or third parties in support of any phase of the process component of the business transaction.

Clause 7 below expands on this fundamental ILCM principle of “under the control of” in a privacy protection requirements context, i.e., via its rules, definitions and normative text.

6.2.4 Limiting Use, Disclosure and Retention34


1. It may be that the rules and associated text in this sub-Clause will need some editing.

2. P-members are requested to review and provide comments as part of their CD ballot comments.

.Rule 015: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 016: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 017: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 017G1: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 018: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 019: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.



251

26772678

2679268026812682268326842685268626872688

2689

2690

2691

269226932694269526962697

269826992700270127022703270427052706270727082709271027112712271327142715271627172718

271927202721

27222723272427252726

252

ISO/IEC CD 15944-12

Guideline 019G1: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 years35. This includes the possibility that the individual who made the purchase may not be the “warranty holder”36.

The following rules summarize these requirements from a BOV perspective:

Rule 020: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 021: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 022: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,

35 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”.

36 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.


254

272727282729273027312732273327342735

27362737273827392740

2741

274227432744274527462747274827492750275127522753275427552756

2757275827592760276127622763

276427652766

2767276827692770

27712772

255256257

258259260

ISO/IEC 15944 CD 15944-12

possible associated goods or services, etc., as well as obtaining client feedback, surveys, new product announcements, etc.

Rule 023: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 024: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).

6.2.5 Timely, accurate, relevant

Rule 025:All personal information pertaining to a business transaction shall be timely, accurate and directly relevant to the goal of the business transaction.


1. P-members are asked to consider whether or not an added rule is needed in support of Rule 027 to the effect that an organization needs to justify, have a clear rationale, etc. to be able to demonstrate how and why the personal information that it retains with respect to a business transaction is both (a) “directly relevant”, and (b) “timely and accurate”. Here it is necessary that an organization has in place both (a) an organization-wide formally stated information life cycle management (ILCM) policy as well as a specified role/function in the organization in support of the same. Here the Project Co-Editors request the P-members to consider the following approach, namely,


262

27732774

277527762777

27782779278027812782

278327842785

27862787278827892790

2791279227932794

279527962797

279827992800280128022803280428052806280728082809

2810

2811281228132814281528162817281828192820282128222823

ISO/IEC CD 15944-12

a) from a governance perspective, i.e. the BOV, it is the responsibility of the organization’s “privacy protection officer (PPO) to ensure that the organization has (formally) approved ILCM policy in place which fully support the applicable privacy protection requirements of the jurisdictional domains in which the organizations conducts its business transaction; and,

b) from an instantiation or implementation perspective, i.e. the FSV, it is the responsibility of the organization’s “personal information controller (PIC)” to ensure that these ILCM requirements are implemented in all the organization’s decision-making applications (DMAs) of their IT systems, as well as those of agents or third parties involved in EDI in support of the instantiation of a business transaction, i.e., a commitment exchange of any kind, where and when the “buyer” is an “individual”.

2. P-members are requested to provide advice and recommendations on this proposed approach via their CD ballot comments. The resulting resolution of this issue will impact other normative text in the further development of this standard.

Rule 026: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.

Rule 027:Any personal information which is not accurate, timely, or relevant should not be entered, or if entered, shall be expunged immediately from (all the DMAs in) the IT system of the Open-edi party, and the DMAs in all the IT system of all the Persons with which the Open-edi party shared such personal information.37

Guideline 027G1:Any personal information of the nature identified in Rule 029 should be expunged immediately or at the minimum no later than as part of the ILCM update cycle of the relevant DMA (or IT system) of the seller (and its agents as well as any third parties associated with the instantiation of the business transaction).38

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, and/or relevant to the business transaction.

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 “integrity39” 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. 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 Privacy Protection “Accuracy” principle is closely related to ensuring the “SRI integrity” in an ILCM context, i.e., the trustworthiness of personal information throughout its life cycle.

Rule 028: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.

37 This Clause and its rules complement those of Part 8, Clause 5.3.1 “Preventing harm” principle which apply here.


39 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


264

2824282528262827282828292830283128322833283428352836283728382839284028412842284328442845

284628472848284928502851285228532854285528562857

285828592860

28612862286328642865286628672868

28692870

287128722873

265

266

267268

ISO/IEC 15944 CD 15944-12

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 028G1:In order to support the privacy principle of accuracy, organizations should consider informing their clients, who are individuals, of the state of 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.

Guideline 028G2: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.

6.2.6 Data integrity and quality

Rule 029:Information management policies and practices, including those of an ILCM nature, as well as those of supporting information handling systems for personal information shall ensure that the level of trustworthiness, data integrity, i.e., SRI integrity, quality and dependability for such personal information supports privacy protection requirements.

It is to the mutual interest of the two primary parties to a business transaction, i.e., the seller and the buyer, to ensure and maintain a “100%” level of data integrity and quality with respect to the SRIs pertaining to any instantiated business transaction. Privacy protection requirements serve as a set of external constraints to ensure the data integrity and quality of a SIR pertaining to the business transaction and especially any sets of personal information (SPIs) forming part of the (prospective) business transaction.


1. One assumes that it is the role/function of the organization’s “privacy protection officer (PPO)” to ensure that the organization have in place organization-wide ILCM policies in support of the same; and,

2. Also from an FSV & implementation perspective has policies, procedures, controls & checks, etc., in place to ensure an ISO 9000 equivalent implementation of the same. (Here one notes that the ISO 9000 series of quality standards, do not address “quality” of the ”data” , “metadata”, etc.. Because the multipart ISO/IEC 15944 eBusiness standard focuses on eBusiness transactions, and these by their very nature require 100% data integrity and quality of the content values of the SRIs and full “control” of any state changes to their content values pertaining to the five phases of a business transaction. As such this Part 12 of 15944 needs to address and provide guidance in issue.

3. P-members are requested to provide CD ballot comments on this matter. The proposed approach here is two-fold, namely:

3.1 continue to develop ISO/IEC15944 standards in support of “ISO 9000 quality principles” until such time as the multipart ISO 9000 series of standards starts to include “data quality” and related ILCM aspects.

3.2 also request ISO/TC 176, the Tc responsible for the multipart ISO 9000 quality standard to include “data quality’ in its further development of the multipart ISO 9000 series of standards; and,

3.3 that in the meantime JTC1/SC32/WG1 continue to develop its multipart ISO/IEC 15944 eBusiness standard in support of “100% data quality”, which has been the approach taken in support of external constraints of jurisdictional domains applicable to modelling a business transaction.


270

287428752876

287728782879

28802881288228832884

2885288628872888

2889

28902891289228932894289528962897289828992900290129022903290429052906290729082909291029112912291329142915291629172918291929202921292229232924292529262927

ISO/IEC CD 15944-12

6.2.7 Safeguards for non-authorized disclosure 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.

Rule 030: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).40

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.

Rule 031: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.

Guideline 031G1The organization should have in place the specified role/function of a Privacy Protection Officer (PPO) who is responsible to ensure that organization-wide policies and operation procedures are in place to support the same.

Guideline 031G2:The organization should have in place the specified role/function of Personal Information Controller (PIC) who is responsible to ensure that with respect to any instantiation of a business transaction of the organization all the privacy protection requirements are implemented and in particular all of those of an ILCM nature.

Rule 032:To support the “safeguard” principle, in an ILCM requirements context, an organization shall ensure that no personal information, i.e. including any state change to the content value of a SRI, 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 032G1: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.

6.2.8 Back-up, retention and archiving

It is recognized that prudent administration of data within an organization involves the systematic creation of “back-up copy(ies) of data” in whole or in part of SRIs contained in its IT systems. Back-up copies of data and their retention (including SPIs) are developed and maintained:

In support of ILCM requirements as a whole.



272

2928

29292930293129322933293429352936293729382939294029412942294329442945294629472948294929502951295229532954295529562957295829592960296129622963296429652966296729682969

29702971297229732974297529762977

297829792980

2981

273

ISO/IEC 15944 CD 15944-12

For those specific to a business transaction (including associated applicable external constraints) and/or,

for those required for archival purposes. {See further Clause 6.28 below} for historical, statistical, and/or research purposes [ See further Clause 6.29 below]

Rule 033:Rules found below in Clauses 6.2.8 apply here.

Rule 034:Organizations shall ensure adequate back-up and contingency planning for any and all sets of personal information (SPIs) pertaining to a business transaction.

Rule 035:Organizations shall retain any and all set(s) of personal information (SPIs) at the required level of detail as required by applicable information law and/or post actualization requirements, (e.g., in relation to a warranty) and in particular in support of applicable privacy protection requirements.

Rule 036:Any set of personal information (SPI)) which has long-term value, i.e., forms part of the corporate memory and/or for historical, archival and/or research value should be identified and conserved. This includes SPIs information required for contingency planning, back-up, emergency response and related requirements.

Rule 0387: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.

6.2.9 Disposition and expungement


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.

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, i.e., in accordance with the organization’s ILCM policy and practices, which in turn shall be privacy protection requirements compliant. This includes any personal information whose ILCM properties from part of the business transaction.

Rule 039:The disposition and expungement of any and all sets of personal information (SPIs) shall use and be done in accordance with rule 040 above and associated (more) detailed rules.as provided in this Part 12.

6.2.10 Organizational archiving

Rule 040:


275

29822983298429852986

2987298829892990299129922993299429952996299729982999300030013002300330043005300630073008300930103011

3012

3013

301430153016

30173018

301930203021302230233024302530263027302830293030

3031

3032

ISO/IEC CD 15944-12

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 040G1: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.11 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,

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.41

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

41 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 jurisdictional domains of the parties involved to the particular business transaction.


277

3033303430353036303730383039304030413042304330443045

3047

304830493050305130523053305430553056305730583059

3060306130623063306430653066306730683069307030713072307330743075307630773078307930803081308230833084308530863087

278279280

ISO/IEC 15944 CD 15944-12

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 1st 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 041: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”).

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 042: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 043: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 044: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.


282

3088308930903091

3092309330943095309630973098

309931003101310231033104310531063107310831093110311131123113311431153116

3117311831193120312131223123312431253126312731283129313031313132313331343135313631373138313931403141314231433144

ISO/IEC CD 15944-12

Rule 045:Any personal information which would have been expunged in the normal and ordinary course of the business transaction in compliance with applicable ILCM and privacy protection requirements but which was not for research or historical purposes shall be anonymized in any of its research use until such time as privacy protection ceases to apply to the sets of personal information (SPIs).

6.3 Requirement for tagging (or labelling) data elements in support of privacy protection requirements42

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 0046: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 (e.g., as SPIs), 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. This includes any (or labelling) needed to support implementation of any and all ILCM requirements.

Rule 0047: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.

42 The requirements and rules stated in Part 8, Clause 5.4 apply here.


284

314531463147314831493150315131523153

315431553156315731583159

316031613162316331643165

316631673168

3169

285

ISO/IEC 15944 CD 15944-12

7 Rules governing ensuring accountability for and control of personal information


1. A key result of the November 2014 Toronto SC32/WG1 interim meeting was that the requirement and concept of “under the control of” was crucial to the development of Part 12 in support of ensuring that an organization in its ILCM is compliant with privacy protection requirements.

2. In support of this requirement a Canadian expert prepared a substantial review of this issue resulting in document SC32/WG1 N0786 titled “Background information and literature review of information for the development of an ISO/IEC 15944-12 definition of “under the control of”. The text and rules is this (new) Clause 7 benefit from this research. P-members preparing CD ballot comments are requested to read first and familiarize themselves with this document. It will assist them in making comments on this Clause 7.

3. The rules, definitions and text of this Clause do need some further refinement. This includes extracting from the detailed 57 page “Background and literature review …” document, noted above, those aspects which are deemed to be most pertinent and which should be included as normative text. P-members and experts are requested to contribute to the completion of this Clause via their CD ballot comments.

7.1 Introduction

The purpose of this Clause is three-fold; namely:

a) to support key characteristics of Open-edi;

b) to introduce in summary form, key aspects and requirements of “under the control of”; and,

c) to do so in the context of privacy protection requirements generally and that of associated information life cycle management requirements specifically.

7.2 Key aspects of Open-edi requirements

A key and very relevant characteristic of Open-edi is that “parties control and maintain their states”, as specified in ISO/IEC 15944-1 in its Clause 5.4 “Parties control and maintain their states” is as follows:

An Open-edi Party shall always have, and make available to other parties, a state description. As perceived by another party, a state description includes only the knowledge necessary for a particular Open-edi activity to take place. A state description is the characteristic of a party at a given point in time which allows the prediction of its external behaviour (or possible ranges of behaviour). A state description is defined in terms of those characteristics which must be available to other parties for the purpose of enabling agreed Open-edi scenarios. States must therefore be stable, sustainable and persistent. When a party needs to change its state it must observe the rules by which state changes are allowed. Changes of the state of one party should be available to all other parties for whom this change has an importance.

This Open-edi requirement is very relevant when and wherever the buyer in a business transaction is an individual and therefore requirements of a privacy protection nature apply43. Further as a business transaction involves the making of a commitment(s) among parties to a business transaction, the ISO/IEC 14662 Open-edi reference model introduced the concept and definition of decision-making application (DMA) which is where all set(s) of recorded information and associated state changes of a SRI are managed and controlled,

43 See further in ISO/IEC 15944-1, Clause 5 “Characteristics of Open-edi”, whose six characteristics are defined as following sub-clauses titled:

5.1 Actions based on following clear, predefined rules;5.2 Commitment of parties involved;5.3 Communication among parties are automated;5.4 Parties control and maintain their states;5.5 Parties act autonomously; and,5.6 Multiple simultaneous transactions can be supported.


287

3170

3171

317231733174

31753176317731783179

3180318131823183

3184

3185

3186

3187

318831893190

3191

31923193

31943195319631973198319932003201

32023203320432053206

288289290291292293294295296

ISO/IEC CD 15944-12

including their EDI through information bundles (IBs) and their semantic components (SCs) with all parties to the business transaction. This Open-edi approach is especially relevant and applicable in the context of ILCM aspects in support of privacy protection requirements.

7.3 Key aspects of “under the control of”44

The phrase “under the control of” is used in several international conventions and laws, as well as those of jurisdictional domains of UN member states. Included are related concepts of “held by”, “in possession of”, “controls”, “in the care of”, i.e. “custody”, etc. The concept of “under the control of” with respect to sets of recorded information of an organization is widely used including at all levels of jurisdictional domains, and is found most often within information law (and associated regulatory) requirements. The concept itself is not well-defined.

The legal and regulatory requirements of various levels of jurisdictional domains use other phrases to convey similar and/or parallel intent to include varying degrees of “control” and “custody. These phrases include:

held by

responsibility of

in the possession of

in the custody off

maintained by

maintain and manage

in the care of

7.4 “under the control of” in support of privacy protection requirements and in an ILCM context

Project Co-Editors Notes:

1. The definition for “under the control of” presented below should be considered a draft. P-members need to review and comment on it as part of the P-member ballot comments on this CD document. The CD ballot comments received will be addressed and resolved at the upcoming May, 2015 Glasgow meeting.

2. Concepts and their definitions which are integrated into this definition include:

agent business transaction decision making application (DMA) electronic data interchange (EDI) external constraint information law information life cycle management (ILCM) organization organization Person personal information privacy protection set of recoded information (SRI) third party

44 For a detailed identification and analysis of the concept of “under the control of”, see further Chapter 4 “Legislation and regulations”, as well as Chapter 5 “Summary of Canadian case law and decisions on “under the control of”, in the JTC1/SC32/WG1 N0786 document titled “Background information and literature review of information for the development of ISO/IEC 15944-12 definition of “under control of”…


298

320732083209

3210

321132123213321432153216

32173218

3219

3220

3221

3222

3223

3224

3225

32263227

3228

322932303231

3232

3233323432353236323732383239324032413242324332443245

299300301302

ISO/IEC 15944 CD 15944-12

3. Based on the results of the CD comment resolution meeting, the resulting text for the definition for “under the control of” will be inserted in Clause 3.160 and Annex A respectively. (Currently, only the draft definition is provided there)

Information life cycle management (ILCM) pertains to all stages of a set of recorded information (SRI) from its initial creation/collection, processing, use, to its eventual disposition. What privacy protection requirements add to this is that all parties to a business transaction shall maintain the same high level of “under the control of” and associated state changes with respect to personal information interchanges with both the individual and any other parties to the business transaction, (e.g., via EDI). Consequently, “under the control of” is defined as45:

under the control of


Rule 048:The organization which is the primary party to a business transaction, i.e., the seller, shall ensure that it “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).

7.5 Implementing “under the control of” and accountability46

ISO/IEC 15944-8 introduced the concept and definition of a “privacy protection officer (PPO)”47. In an Open-edi reference model context, the focus of the privacy protection officer (PPO) is primarily one of governance and from a business operational view (BOV) perspective. This is reflected in the ISO definition for the concept of “privacy protection officer” as follows:

privacy protection officerPPOorganization 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]

The information life cycle management (ILCM) of this Part 12 standard is more focussed on implementation aspects as well as serving as a bridge between the BOV and FSV. This is the role and function of a “personal information controller” in an organization. This role and function in an organization is defined as:48

personal information controller

45 This definition integrates key aspects of “under the control of” as found in the APEC Privacy Framework as well as the Directive 95/46/EC on “data protection”.


47 See further in Part 8, Clause 5.3.2 “Privacy Protection Principle 2: Accountability”.

48 This ISO definition draws heavily on and is harmonized with the concept and definition of “data controller” as found in the Directive 95/46/EC on “data protection” of the European Union.


304

3246324732483249

325032513252325332543255

3256

32573258325932603261326232633264

326532663267326832693270

3271327232733274327532763277327832793280328132823283

3284

3285328632873288

3289

305306

307

308

309310

ISO/IEC CD 15944-12

PICOrganization Person authorized and so formally designated by the organization to ensure that personal information remains (fully) under the control of the organization and ensure its integrity in compliance with applicable privacy protection requirements including in any use by the organization of agents and/or third parties in support of a business transaction(s)


Figure 4 below illustrates the relationship and interworking between the roles and functions of a “privacy protection officer” and a “personal information controller”.

Figure 4 - Illustration of roles and relationships between a “privacy protection officer (PPO)” and a “personal information controller (PIC)” in an Open-edi business transaction indicating the link between the BOV and FSV


1. Comments are invite on the (draft) Figure 4. It will be discussed further at the Glasgow meeting. It is likely that some added text is needed to explain the figure.

Rule 049:An organization shall ensure that it has a designated role and function of “personal information controller” (PIC), i.e., an organization Person who is responsible for ensuring that all processing, state changes, EDI, etc., of set(s) of personal information (SRIs) pertaining to a business transaction remains under the control of the organization, i.e., in its role as a seller.

Guideline 049G1:It is also recommended that from a data processing and EDI perspective, that the organization has its “personal information controller” (PIC):

a) review any (prospective) EDI of the (seller) organization of any SPIs, as well as any state changes to the contents (and/or metadata on the same); and,


Business Operational View (BOV)

Organization’s Information Management Policy and Governance

External constraints- Information Law compliance – including privacy protection

requirements

Role/functions of privacy protection

officer |(PPO)

Functional Service View (FSV)Role/functions of personal

information controller (PIC)

Information life cycle management (ILCM)

requirements

312

329032913292329332943295329632973298

32993300

33013302

330333043305330633073308330933103311331233133314331533163317331833193320332133223323

ISO/IEC 15944 CD 15944-12

b) ensure that such SPIs remain under the control of the (seller) organization at all times, and in compliance with the ILCM requirements which apply to the SPIs of the business transaction including those of the IT system(s) of agents and/or third parties who may be involved.

Rule 050: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 and in particular the organization’s personal information controller (PIC).

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 051: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 party(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 051G1: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 11 Conformance 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).

Guideline 051G2: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 sub-sets 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 of an internal constraint nature is that of a “warranty” for “n” number of years49. This includes the possibility that the individual who made the purchase may not be the “warranty holder”50.

49 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, as part of the applicable external constraints of the relevant jurisdictional domain(s). This is especially so where consumers purchase an “extended warranty”.


314

332433253326332733283329333033313332333333343335333633373338

3339334033413342

3343334433453346334733483349335033513352335333543355335633573358335933603361

336233633364336533663367336833693370

33713372337333743375

315316317

ISO/IEC CD 15944-12

The following rules summarize these requirements from a BOV perspective:

Rule 052: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), and be so be specified in execution of the organization’s ILCM.

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 053: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 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:

a) 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,

b) 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, possible associated goods or services, etc., as well as obtaining client feedback, surveys, new product announcements, etc.

Rule 054:Where the buyer in business transaction is an individual, the seller shall inform that individual of the applicable SRI retention and associated ILCM 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 055: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

50 For example, where the good or service is purchased as a gift. 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.


319

3376

3377337833793380338133823383338433853386

3387338833893390339133923393339433953396

3397339833993400

3401340234033404

340534063407

34083409341034113412

341334143415

34163417341834193420

34213422

320321322

ISO/IEC 15944 CD 15944-12

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).


324

34233424

342534263427

342834293430343134323433343434353436343734383439

3440

ISO/IEC CD 15944-12



326

3441

3442

3443

3444

3445

3446

3447

3448

3449

3450

3451

3452

3453

3454

3455

3456

3457

3458

3459

3460

3461

ISO/IEC 15944 CD 15944-12

8 Rules governing the specification of ILCM aspects of personal information

8.1 Introduction

The purpose of this Clause 8 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 personal information in the context 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, i.e., expungement of personal information.

As such, the purpose of Clause 8 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 7 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.)

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.

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 51 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

51 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.


328

3462

3463

3464346534663467

34683469

34703471

34723473347434753476

34773478

34793480

348134823483348434853486

34873488

348934903491

34923493

349434953496

3497

349834993500

329330331332333

ISO/IEC CD 15944-12

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.52

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 056: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.

8.2 Rules governing establishing ILCM responsibilities for personal information


1. The text in this Clause 8.2 will likely be/should be amended in the context of new Clause 7 above.

2. P-member comments and contributions on the CD ballot document are most welcome.

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 057: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 057G1: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 058: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 058G: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.

52 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.


335

3501

35023503

350435053506

35073508

350935103511

351235133514

3515

351635173518351935203521352235233524352535263527352835293530353135323533353435353536353735383539354035413542354335443545354635473548

336337338339

ISO/IEC 15944 CD 15944-12

Guideline 058G2: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 058G3Use 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 059: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.

3. . P-members and experts are requested to review the entries in Table, including .the possible need to add other entries, and do so via their ballot comments.

Table 1 — ISO/IEC 15944-12:01 Codes representing specification of records retention responsibility for personal information53

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 are54. | (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

53143 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.

54 Use of ID Code 2 is a “logical” possibility. Its use should be considered a “rarity”


341

3549355035513552355335543555355635573558355935603561356235633564356535663567

3568

35693570

35713572

35733574

35753576

342343344

345

ISO/IEC CD 15944-12

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


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

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 information55

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.56

15944-12 01 98 not known inconnu

15944-12 01 99 not applicable sans objet

8.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 060: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..

55 An example would be the personal information for a driver’s license, or any other transaction where the regulator is the “authoritative” source.

56 Examples include notarial acts, a regulator assigning a record-keeping registry, etc., function to a third party.


347

3577

35783579

358035813582358335843585

35863587358835893590

348349

350

ISO/IEC 15944 CD 15944-12

Guideline 060G1:In support of Rule nnn, 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”.


1. P-members and experts are requested to review the entries in Table, including .the possible need to add other entries, and do so via their ballot comments.

Table 2 — ISO/IEC 15944-12:02 Codes representing SRI retention triggers for retention of personal information57

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



352

3591359235933594359535963597359835993600

3601360236033604

353354355

ISO/IEC CD 15944-12

ISO/IEC 15944-12:02 Codes representing SRI retention triggers for retention and disposition of personal information


Source Authority ID

Coded Domain

ID

IDCode


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 58 sans objet

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 061: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 061G1: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 062: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 062G1Sellers 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 063: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.

58 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”).


357

3605

3606360736083609

361036113612361336143615

3616361736183619362036213622362336243625362636273628362936303631363236333634363536363637363836393640

358359

ISO/IEC 15944 CD 15944-12

Guideline 063G1Sellers 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 064: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 065: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.


1. P-members and experts are requested to review the entries in Table 3, including .the possible need to add other entries, and do so via their CD ballot comments.

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 requirements59

15944-12 03 02 Maximum retention period as stated in applicable privacy protection requirements. (Seller to provide information to individual as buyer )60

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 requirements61 (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

59 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.

60 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.

61 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.


361

3641364236433644364536463647364836493650365136523653365436553656365736583659

36603661

362363

364365

366367

ISO/IEC CD 15944-12

ISO/IEC 15944-12:03 Codes representing the specification of types of record retention period


Source Authority ID

Coded Domain

ID

IDCode


information.62

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.63

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 specified64

15944-12 03 07 ??

15944-12 03 08 ??

8.4 Rules governing identification and specification of state changes of personal information65

8.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

62 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.

63 On temporal referencing, see further, ISO/IEC 15944-5, Clause 6.6.45 titled “Date/Time referencing”

64 See footnote 60 above. The Clause in Part 5 provides information on other temporal referencing schemas such at the “atomic clock”, the “GPS calendar/clock”, etc.

65 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.


369

3662

366336643665

3666

3667366836693670

367136723673367436753676

36773678

36793680

370371

372

373374

375

ISO/IEC 15944 CD 15944-12

transaction may require a state change to their content value(s). Examples include the address of the buyer as individual may change, the planned delivery date or delivery location may change, 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 066: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.

Rule 067: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.

8.4.2 Specification of state changes allowed to personal information

Rule 068: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 069: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 069G1: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 in Part 8 Clause 11.2 } 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


377

36813682

36833684

36853686

3687368836893690369136923693369436953696369736983699370037013702

3703

37043705370637073708

3709

371037113712371337143715371637173718371937203721372237233724372537263727372837293730

37313732

ISO/IEC CD 15944-12

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 070: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.

Guideline 070G1: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 071:If a state change is required, the seller (and/or regulator) shall specify the number of state changes permitted.

Guideline 071G1: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.




379

37333734

373537363737373837393740

374137423743374437453746374737483749375037513752

37533754375537563757375837593760376137623763376437653766

37673768

ISO/IEC 15944 CD 15944-12

Table 4 — ISO/IEC 15944-12:04 Codes for specifying whether state changes allowed for the content values of SRIs containing personal information66

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 by the buyer

66 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 5944 or in

the next edition of this part of ISO/IEC 15944.


381

376937703771

382383

ISO/IEC CD 15944-12

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 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

8.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 072: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 072G1: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 67Table 5 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)68

67 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.

68 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


385

3772

3773

377437753776

37773778377937803781378237833784378537863787378837893790379137923793379437953796

3797379837993800

3801

386387388

389390

ISO/IEC 15944 CD 15944-12

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 69

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.

69 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.


392

3802

38033804380538063807

3808

393

394395

ISO/IEC CD 15944-12

8.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 073: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 073G1: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 SRIs70

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



397

3809

381038113812

3813381438153816381738183819

38203821382238233824382538263827382838293830

38313832

398399400

ISO/IEC 15944 CD 15944-12

ISO/IEC 15944-12-06 Codes representing source of state change type ID code


Source Authority

Coded Domain

ID

ID Code


the same , i.e., as a result of the negotiation phase, with respect to the business transaction to be actualized

15944-12 06 ??

15944-12 06 ??

15944-12 06 99 Not applicable, i.e., no state change is allowed, (therefore source of state change does not apply)

8.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.

3. 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. 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


402

3833

38343835

3836

3837383838393840

3841384238433844

38453846384738483849

385038513852385338543855

38563857

3858385938603861

ISO/IEC CD 15944-12

ownership and accountability71. In the context of this part of ISO/IEC 15944, “Open-edi disposition” is defined as:

Open-edi disposition

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 controls72;

the transfer of the “disposed” SRI(s) to an archive (IT system) of (a) an agent of the organization 73; (b) an organization which is a third party to the organization74; or, (c) a totally separate, and largely removed, separate organization;

the transfer of personal information by an organization for (officially recognized) research purposes75; 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 incorporate ensure “individual anonymity”

other?

Rule 074:

71 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).

72 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.

73 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.

74 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.

75 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


404

38623863

3864

386538663867

3868

386938703871

3872387338743875

38763877

38783879

388038813882

38833884388538863887

3888

3889

405406

407408409

410411412413414415416417418

419420

421422423

ISO/IEC 15944 CD 15944-12

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

Rule 075: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 075G1: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 076: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 077G1: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.76.

76 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


425

3890389138923893389438953896389738983899390039013902390339043905390639073908390939103911391239133914391539163917391839193920392139223923

3924392539263927

39283929393039313932393339343935393639373938393939403941

426427428429430431

ISO/IEC CD 15944-12

Rule 078: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 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 078G1:Where the condition of Rule 082 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)77

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).

77 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.


433

394239433944394539463947394839493950395139523953395439553956395739583959

434435436

ISO/IEC 15944 CD 15944-12

ISO/IEC 15944-512;007 Codes representing disposition of personal information (as SPIs)


Source Authority ID

Coded Domain

ID

ID Code


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). (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 78 sans objet

78 This would apply to recorded information deemed to be transitory or ephemeral which can be discarded anytime.


438

3960

3961

439

ISO/IEC CD 15944-12



441

3962

3963

3964

3965

3966

3967

3968

3969

3970

3971

3972

3973

3974

3975

3976

3977

3978

3979

3980

3981

3982

3983

3984

3985

3986

3987

ISO/IEC 15944 CD 15944-12

9 Data conversion, data migration, and data synchronization79

Project Co-Editors” Notes:

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 information80

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” which applies at the “format level; and (b) of the nature which involve migrating the SRI(s) from one IT system, data storage medium, etc., to another 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 conversionprocess of changing data, i.e., set(s) of recorded information (SRI(s)) from one format or representation to another while maintaining the characteristics of the SRIs including the authenticity, integrity, reliability and usability of the sets of recorded information (SRI(s)) as well as relevant information life cycle management (ILCM) requirements, and especially those of an external constraints nature including privacy protection requirements where the data involves personal information

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

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.

80 NOTE: The approach taken here is based on that of ISO 13008:2012 “Information and documentation – Digital records conversion and migration process”.


446

3988

3989

39903991

3992399339943995

3996

399739983999400040014002400340044005

4006400740084009

4010

40114012401340144015

40164017

4018401940204021402240234024

40254026

447448449

450451

ISO/IEC CD 15944-12

EXAMPLE 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



data migrationprocess of moving data, i.e., as sets of recorded information (SRIs) including their existing characteristics from one IT System, (e.g., hardware or software configuration) to another, as required by changes in an IT System configuration or as requested by the user, while assuring that the SRI(s) will remain addressable and that data authenticity, integrity, reliability and useability of the SRI(s) will be maintained in the new environment

NOTE 1 Data migration does not change the format or the content of the SRIs



Rule 079: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 080: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 081: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 082: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 083: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.


453

402740284029

4030

40314032

403340344035403640374038

4039

4040

4041

4042404340444045404640474048404940504051

4052405340544055405640574058405940604061406240634064406540664067406840694070

407140724073407440754076

ISO/IEC 15944 CD 15944-12

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.81

Rule 084: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 085:Where Rule 087 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 085G1: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.

81 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.


455

40774078407940804081

408240834084

408540864087408840894090409140924093409440954096409740984099

4100

456457458459

ISO/IEC CD 15944-12



461

4101

4102

4103

4104

4105

4106

4107

4108

4109

ISO/IEC 15944 CD 15944-12

10 Rules governing EDI of personal information between primary ILCM Person, i.e., the seller, and its “agent”, “third party” and/or “regulator”


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.

10.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 10 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.82

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.

10.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 086: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 086G1: Prior to an organization delegating part (or all) of the instantiation of a business transaction to an agent via EDI, 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. This includes the agent having a designated privacy protection officer (PPO) and a personal information controller (PIC).

Rule 087: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.

82 Users and implementers of Parts 12 are urged to familiarize themselves with the text and rules of Part 8, Clause 5.3.2.


463

41104111

4112

4113

411441154116411741184119

4120

412141224123

4124412541264127

412841294130

4131413241334134

4135

413641374138413941404141414241434144414541464147414841494150415141524153415441554156

464

ISO/IEC CD 15944-12

Rule 088: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 089G1: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 090: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.

10.3 ILCM rules pertaining to use of a “third party”

Rule 091: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 092: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 093: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 093G1: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 094: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.


466

4157415841594160416141624163416441654166416741684169

41704171417241734174417541764177

417841794180418141824183418441854186418741884189419041914192419341944195419641974198419942004201420242034204

42054206420742084209421042114212

ISO/IEC 15944 CD 15944-12

10.4 ILCM rules pertaining to involvement of a “regulator”

Rule 095: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 096: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 097: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 097G1: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.


468

4213

42144215421642174218421942204221

4222422342244225422642274228422942304231423242334234423542364237423842394240

424142424243

4244

4245

ISO/IEC CD 15944-12



470

4246

4247

4248

4249

4250

4251

4252

4253

4254

4255

4256

4257

4258

4259

4260

4261

4262

4263

4264

4265

4266

ISO/IEC 15944 CD 15944-12

11 Conformance statement83

11.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 1 st edition or as part of the development of a 2nd edition for this part of ISO/IEC 15944.

Clause 11 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 11.4 below}

11.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.

11.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”.

11.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.

83 Similar to that of Clause 13, Part 8 but with added sub-clauses re: conformance statement for “agent”, “third party”, and “regulator”.


472

4267

4268

4269427042714272

4273

4274

4275

4276

427742784279

42804281

42824283

4284

4285

42864287

42884289

4290

4291

42924293429442954296

4297

42984299

473474

475

ISO/IEC CD 15944-12

This means that such personal information maintained under the control of the organization acting in the role of seller, including as ILCM 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 098: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. This includes organization”XYZ” having a designated role/function of privacy protection officer (PPO) and of personal information controller (PIC).as an organization person(s)”.


477

43004301430243034304

43054306430743084309431043114312431343144315431643174318431943204321

ISO/IEC 15944 CD 15944-12

Annex A(normative)

Consolidated list of terms and definitions with cultural adaptability: ISO English and ISO French language equivalency


1. At the November 2014 Toronto interim meeting the “new” terms and definitions were reviewed and approved with one minor edit. This was to include the full term and not just their acronyms in the text of the definition. It was felt that this made the definitions more understandable to first time users of this standard. Further in the ISO “Open Browsing Platform (OBP), entry for a “term & definition” pair is “standalone”, therefore if the text in a definition contains the acronym only without the actual full text of the term itself, the user will likely not be able to understand (and re-use) that definition.

2. In addition, some minor edits were made to the text of the definitions for “data conversion” and “data migration”. This harmonized them with existing ISO definitions for both with those found in ISO 13008:2012.

3. The ISO French equivalents will be provided during the CD to DIS development of this document.

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


479

4322

4323

4324

4325

4326

4327

432843294330433143324333

433443354336

4337

4338

4339434043414342

434343444345434643474348

4349

435043514352

435343544355

4356

43574358

ISO/IEC CD 15944-12

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.84

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 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 eBusiness Vocabulary ID (as assigned in ISO/IEC 15944-7 eBusiness Vocabulary)85

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

84 Other ISO/IEC member bodies are encouraged to provide bilingual/multilingual equivalencies of terms/definitions for the language(s) in use in their countries.

85 eBusiness Vocabulary IDs are assigned in ISO/IEC 15944-7 based on the next available Dnnn sequential number and once the standard relevant Part of ISO/IEC 15944 document passes the DIS stage.


481

43594360

4361436243634364

43654366

43674368436943704371

4372437343744375

4376

43774378

4379

4380

482483

484485

ISO/IEC 15944 CD 15944-12

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)86.

+ 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.

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 to the 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 found 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 :2015,3.7

back-up copy of data

99 copy of any (combination of) set(s) of recorded information (SRIs) 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

86 See further Part 7 “eBusiness Vocabulary” of ISO/IEC 15944 for an implementation of this approach.


487

438143824383

438443854386

43874388

4389

43904391

43924393

43944395439643974398439944004401

488

ISO/IEC CD 15944-12



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

it contains if the original is not available

DXXX ISO/IEC 15944-12 :2015, 3.13

business transaction 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

ISO/IEC 15944-12 :2015, 3.33

data conversion

99 process of changing data, i.e., set(s) of recorded information (SRI(s) from one format or representation to another while maintaining the characteristics of the SRIs including the authenticity, integrity, reliability and usability of the sets of recorded information (SRI(s)) as well as relevant information life cycle management (ILCM) requirements, and especially those of an external constraints nature including privacy protection requirements where the data involves personal information

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

EXAMPLE Data conversion


490

ISO/IEC 15944 CD 15944-12



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

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 :2015, 3.36

data migration

99 process of moving data, i.e., as sets of recorded information (SRIs), including their existing characteristics from one IT System, (e.g., hardware or software configuration) to another, as required by changes in an IT System configuration or as requested by the user, while assuring that the SRI(s) will remain addressable and that data authenticity, integrity, reliability and useability of the SRI(s) will be maintained in the new environment

NOTE Data migration does not change the format or the content of the SRIs.



DXXX ISO/IEC 15944-12 :2015,

data synchronization (in

99 process of continuous harmonization of a set(s) of recorded information


492

ISO/IEC CD 15944-12



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

3.39 business transaction)

(SRI) 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 (SRI(s))) 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 :2015, 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 :2015, 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

DXXX ISO/IEC 15944-12 :2015, 3.63

individual authentication

99 provision of the assurance of a recognized individual identity (rii) sufficient for the purpose of the business transaction


494

ISO/IEC 15944 CD 15944-12



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

DXXX ISO/IEC 15944-12 :2015, 3.68

Information life cycle management (ILCM)

99 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.

DXXX ISO/IEC 15944-12 :2015, 3.106

personal information controller (PIC)

99 organization Person authorized and so formally designated by the organization to ensure that personal information remains (fully) under the control of that organization in compliance with applicable privacy protection requirements including in any use by the organization of agents and/or third parties in support of a business transaction(s)


DXXX ISO/IEC 15944-12 :2015, 3.150

set of personal information

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


496

ISO/IEC CD 15944-12



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

(SPI) information

DXXX ISO/IEC 15944-12 :2015, 3.154

SRI destruction

99 process of eliminating or deleting sets of recorded information (SRI(s)), beyond any possible reconstruction

DXXX ISO/IEC 15944-12 :2015, 3.155

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 :2015, 3.156

SRI integrity 99 (of records) reliability and trustworthiness of sets of recorded information (SRI(s)) as copies, duplicates or comparable representations of sets of recorded information (SRI(s)); and reliability and trustworthiness of the IT system in which it was recorded or stored to produce reliable and trustworthy copies and duplicates of sets of recorded information (SRI(s))

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 absence of a statutory or judicially created definition, the principles of this standard


498

ISO/IEC 15944 CD 15944-12



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)

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 :2015, 3.157

SRI life cycle 99 stages in the life cycle of a set of recorded information (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 set of recorded information (SRI(s;)) its storage, maintenance and protection; its archival preservation or destruction or expungement

DXXX ISO/IEC 15944-12 :2015, 3.158

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

DXXX ISO/IEC 15944-12 :2015, 3.163

transitory record

99 set of recorded information (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 set of recorded information (SRI)


500

ISO/IEC CD 15944-12



eBus. Vocab.

ID

SourceRef. ID


(1) (2) (3) (4) (5) (6) (7) (8)


DXXX ISO/IEC 15944-12:2015, 3.169

under the control of

99 The draft definition for discussion in Glasgow is as follow:



502

4402

ISO/IEC 15944 CD 15944-12

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)87.

+ 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”.

87 See further ISO/IEC 15944-7 “eBusiness Vocabulary” of ISO/IEC 15944 for an implementation of this approach.


504

440344044405

440644074408

4409

4410

505

ISO/IEC CD 15944-12



507

4411

4412

4413

4414

4415

4416

4417

4418

4419

4420

4421

4422

4423

4424

4425

4426

4427

4428

4429

4430

4431

4432

ISO/IEC 15944 CD 15944-12

Annex B(informative)

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


1. During the development of the DIS version of this document the consolidated set of rules in Annex B will be reviewed and entries deleted (or added) as required based on the contents of the DIS document.

2. CD ballot comments on Annex B will also be integrated at that time.

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.


509

4433

4434

4435

4436

4437

4438

4439

4440

44414442

4443

4444

44454446444744484449

4450445144524453445444554456

445744584459

44604461

4462

44634464

4465

44664467

ISO/IEC CD 15944-12

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:

Col. No Use

1 Number of Rule as per Part of ISO/IEC 15944 referenced in the Annex B sub-clause.

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


511

4468

44694470

4471

4472

4473

4474

44754476

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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.

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


513

ISO/IEC CD 15944-12


(1) (2) (3)

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.

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


515

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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 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.


517

4477

44784479

4480

ISO/IEC CD 15944-12



(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 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


519

44814482

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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.

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


521

ISO/IEC CD 15944-12


(1) (2) (3)

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 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.


523

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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 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.


525

ISO/IEC CD 15944-12


(1) (2) (3)

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 (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.


527

4483

44844485

4486448744884489

449044914492449344944495449644974498

ISO/IEC 15944 CD 15944-12


(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 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.


529

ISO/IEC CD 15944-12


(1) (2) (3)

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 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


531

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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 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.


533

ISO/IEC CD 15944-12


(1) (2) (3)

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 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).


535

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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 “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.


537

4499

4500

4501

4502

4503

4504

ISO/IEC CD 15944-12



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.

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


539

45054506

4507

4508

45094510

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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 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


541

ISO/IEC CD 15944-12


(1) (2) (3)

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).

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


543

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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.

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:


545

ISO/IEC CD 15944-12


(1) (2) (3)

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 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.


547

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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 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


549

ISO/IEC CD 15944-12


(1) (2) (3)

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:

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


551

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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.

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


553

ISO/IEC CD 15944-12


(1) (2) (3)

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 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


555

ISO/IEC 15944 CD 15944-12


(1) (2) (3)

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 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.


557

4511

ISO/IEC CD 15944-12



559

4512

4513

4514

4515

4516

4517

4518

4519

4520

4521

4522

4523

4524

4525

4526

4527

4528

4529

4530

4531

4532

4533

ISO/IEC 15944 CD 15944-12

Annex C(informative)

Linking ILCM to process phases of a business transaction


1. The purpose of this Annex C is to link the five phases of the process component of the business transaction model (BTM) to information life cycle management (ILCM. It is a short Annex.

2. P-members are requested to review this Annex C and make ballot comments

3. It is recognized that decisions taken here may impact other Clauses and Annexes in Part 12.

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 phases88 in the Business Transaction Model (BTM)89.

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.

88 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.

89 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.


561

4534

4535

4536

4537

4538

45394540

4541

4542

4543

45444545

45464547

45484549

4550

4551

4552

4553

4554

4555

45564557455845594560456145624563

562563

564565

ISO/IEC CD 15944-12

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 requirements for personal information.


567

456445654566

456745684569457045714572457345744575457645774578

45794580

4581

45824583

ISO/IEC 15944 CD 15944-12

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


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) business transaction

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).

569

4584

45854586

ISO/IEC CD 15944-12



571

4587

4588

4589

4590

4591

4592

4593

4594

4595

4596

4597

4598

4599

4600

4601

4602

4603

4604

4605

4606

4607

ISO/IEC 15944 CD 15944-12

Annex D(informative)

Generic approach to ILCM decisions in a privacy protection requirements context – ILCM decision template


1. 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.

2. When completed this Annex will contain one (or more) decision charts and accompanying “check-off” templates.

3. P-members are requested to make comments on this draft Annex D and contribute to its further development.

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 an individual.

Rule D01:The rules, definitions and other normative text of ISO/IEC 15944-12 apply to Annex D.

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.


573

4608

4609

4610

4611

4612

4613

46144615

46164617

46184619

4620

4621462246234624

4625462646274628

46294630

46314632

463346344635

46364637

463846394640464146424643

ISO/IEC CD 15944-12

This means that the buyer and seller interchanged as IBs (and their SCs) various SRIs when the prospective buyer is an individual, whose personal information was provided by the individual, as buyer, to the seller, as organization.

Rule D02: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 D03: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.


1. Figure D.1 below is a draft only.

2. P-members are requested to comment on Figure D.1 and make contributions in support of its further development and completion (including any need to develop an additional figure).

3. Additional sub-Clauses may be needed. At present, there is only a draft for a sub-Clause pertaining to the post-actualization requirements.


575

464446454646

46474648464946504651465246534654465546564657465846594660

466146624663

4664

4665

46664667

46684669

4670

ISO/IEC 15944 CD 15944-12

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

D.2.2 ILCM 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.

Rule D04:Where and when a (potential) business transaction involves a buyer who is an individual, then any post-actualization requirements pertaining to personal information of the (prospective) buyer:

a) be made aware to the (prospective) buyer at the negotiation phase;b) is fully compliant with applicable privacy protection requirements.


1. Creation of personal information as one or more SPIs pertaining to a business transaction

2. Transitory Yes/ No

2.1 If Yes, Expunge* SPI

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 apply

577

4671

467346744675

4676

467746784679

468046814682

46834684

468546864687468846894690

ISO/IEC CD 15944-12



579

4691

4692

4693

4694

4695

4696

4697

4698

4699

4700

4701

4702

4703

4704

4705

4706

4707

4708

4709

ISO/IEC 15944 CD 15944-12

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. as part of their CD ballot comments.

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.


581

4710

4711

4712

4713

4714

4715

4716

4717

471847194720

47214722

47234724

4725

4726472747284729

473047314732473347344735

4736473747384739

474047414742474347444745

4746

ISO/IEC CD 15944-12

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;

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);


583

4747

4748

474947504751475247534754

47554756

4757475847594760

47614762

4763

4764

47654766

47674768

47694770

4771

47724773

47744775

4776477747784779

47804781

478247834784

478547864787

ISO/IEC 15944 CD 15944-12

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) Other?


585

478847894790

4791479247934794

4795

4796

4797

ISO/IEC CD 15944-12



587

4798

4799

4800

4801

4802

4803

4804

4805

4806

4807

4808

4809

4810

4811

4812

4813

4814

ISO/IEC 15944 CD 15944-12

Annex X(informative)

“VANs”, “outsourcing, “Clouds” etc., and information life cycle management (ILCM) and EDI of personal information


1. At the Toronto November 2014 interim meeting, SC32/WG1decided to add an informative Annex on VANs, Clouds, etc. A draft of this document was circulated to SC32/WG1 experts as N0784.

2. Comments were requested by 5 January, 2015. These have been integrated into this Annex X.

3. P-members and experts are invited to make comments on this Annex X. At the CD ballot meeting for this Part 12, when accepted as is or as amended , this will become Annex F.

X.1 Introduction

When the ISO/IEC 14662 “Open-edi Reference model” standard was developed (1st edition in 1997), the concepts and use of “Value-Added Networks (VANs)” as well as “outsourcing” were well known and in use by many organizations using EDI to conduct their business transactions.

A key aspect of the Open-edi Reference Model is the introduction and provision for two modelling perspectives of a business transaction; namely:

the Business Operational View (BOV); and, the Functional Services View (FSV). {See further Clause 4 in ISO/IEC 1466290}

The multipart ISO/IEC 15944 eBusiness standard focuses on the Business Operational View (BOV) of business transactions. The development of the 1st edition of ISO/IEC 15944-1 took into account that both the buyer and the seller often engaged another organization to assist in the completion of a business transaction, i.e., as either in the role of an “agent” or the role of a “third party”.

The introduction of legal and regulatory requirements for privacy protection of personal information world-wide also impacts the business operational view (BOV) in that is applies where in a business transaction the buyer is an individual”. The ISO/IEC 15944-8 standard brings forward and integrates global legal and regulatory privacy protection requirements within the business operational view91. This Part 12 of ISO/IEC 15944 focuses information life cycle management (LCM) aspects of privacy protection requirements as they apply to personal information, i.e., where the buyer in a business transaction is an individual.

X.2 Purpose

The purpose of this Annex is to bring forward a number of key constructs and requirements pertaining to the use of an “agent’ and/or a “third party” by a seller and place these in the context of privacy protection requirements (including ILCM), where the buyer is an individual.

90 ISO/IEC 14662 is an “ISO freely available standard. Go to < http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html >

91 See ISO/IEC 15944-8:2012 “Informational technology – Business Operational View – Part 8: Identification of privacy protection requirements as external constraints on business transactions”. It is also an ISO freely available standard.


589

4815

4816

4817

4818

4819

4820482148224823482448254826482748284829

4830

4831483248334834483548364837483848394840484148424843484448454846484748484849485048514852

4853

485448554856

590591592593594595

http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

ISO/IEC CD 15944-12

It needs to be stressed that these are quite independent of whether the use by a seller of an agent or a third party is labelled as the use of a “VAN”, a “Cloud”, “outsourcing”, etc. This is summarized in the sections below.

X.3 Summary of role of “agent” or “third party” by a buyer in executing business transactions92

A seller in conducting (electronic) business transactions is free to decide whether or not it wants to conduct these based solely on the use of its own IT systems or delegate part of its role to an “agent” or a “third party”. These two concepts have been defined as follows:

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

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

third partyPerson besides the two primary parties to a business transaction who is an 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 constraints93

NOTE It is understood that more than two Persons can at times be primary parties in a business transaction.

X.4 Information life cycle management (ILCM) aspects

The seller (organization) in a business transaction is the Person which executes the transaction. As such the seller is also the “records creating organization” in that it creates the sets of recorded information (SRIs) pertaining to that business transaction which in turn are interchanged with the buyer (and possible other parties to the transaction in the form on information bundles (IBs), in turn composed of one or more semantic components (SCs). ILCM aspects are defined management processes and controls pertaining to:

a) the creation, maintenance, access controls, use constraints, state or change management which pertain to the sets of recorded information comprising a business transaction; and,

b) then when the business transaction is actualized determine which of the SRI(s) involved need to be retained (e.g., for post-actualization requirements, if any, and for various legal requirements as applicable to the nature of the good, service and/or right of the business transaction), and if not should be deleted.

Within an Open-edi context and in order for business transactions to be able to be completed among parties using EDI, all parties involved need to maintain and synchronize state changes to SRIs as they occur. This also includes ensuring that such SRIs remain under the control of the seller with respect to any state changes, irrespective of whether or not the seller uses an agent or a third party. Thus, in an eBusiness context, ILCM focuses and works on a state change basis.

X.5 Summary of “Cloud computing” in ICT

“Cloud computing” is the current marketing term used by “cloud service providers” (CSPs) reflecting changes and advances in use ICT from that of VANs a decade ago. It refers to the use of a broad range of ICT infrastructures and services which are distributed across a network (basically the Internet) which is scalable

92 For detailed definitions, rules, detailed figures, etc, see further Clause 6.2.5 “Person and delegation to “agent” and/or “third party” in ISO/IEC 15944-1. This is also an ISO freely available standard.93 Examples of external constraints are legal and regulatory requirements, which are constraints take precedence over other constraints on a business transaction.


597

48574858

48594860

486148624863

48644865486648674868486948704871487248734874487548764877

4878

48794880488148824883488448854886488748884889489048914892489348944895

4896

489748984899

598599600601602

ISO/IEC 15944 CD 15944-12

“on-demand94” and designed to support the storage and management of high volumes of EDI. eBusiness is a major market segment/user of cloud computing.

Essential characteristics of cloud computing include:

on-demand self-service; resource pooling; rapid elasticity; broad network access; measured services; etc.

The most common service models include:

“Software as a Service” (SaaS); “Platform as a Service (PaaS); and, “Infrastructure as a Service (IaaS).

Cloud Service Providers (CSPs) have a number of deployment models including private cloud, public cloud, community cloud, hybrid cloud, etc.

X.6 Conclusions - Cloud computing services and protection of personal information

In conclusion, it is important to note that from an eBusiness perspective, when a seller, decides to make use of a cloud service provider (CSP), the seller is basically doing so in the context of a CSP serving as either its “agent” or as its “third party”. As such, the seller needs to specify that the rights and obligations arising from the commitments in a business transaction are being handled by the CSP. Thus, where the buyer is an individual in a business transaction, privacy protection requirements apply and need to be supported by the CSP.

94 A key factor in sellers using cloud service by a seller is that a cloud service can provide the capacity to provide the ICT support required to deal with surges/peaks in order/sales such as occur in most countries in relation to (national) holidays.


604

4900490149024903490449054906490749084909491049114912491349144915491649174918

4919

492049214922492349244925

605606

ISO/IEC CD 15944-12

Bibliography


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 three parts. The first identifies sources that are ISO and ISO/IEC international standards. The second identifies registered ISO, ISO/IEC, etc, documents that were prepared for this standards development project and have provided input. The third 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 13008:2012 Information and documentation – Digital records conversion and migration process

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: Genera/ 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. ISO and ISO/IEC registered documents pertaining to the development of this international standard

M. Janice Pereira and Knoppers, Jake V. Th. (2015-01-25) Background information and literature review of information for the development of an ISO/IEC 15944-12 definition of “under the control of”. ISO/IEC JTC1/SC32/WG1 N 0786


608

4926

4927

49284929

4930493149324933

4934

49354936

49374938

4939

49404941

4942

49434944

4945

49464947

49484949

4950

4951

4952

49534954

49554956

495749584959

ISO/IEC 15944 CD 15944-12

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.

“VANs”, “outsourcing”, “Clouds”, etc., and information life cycle management (ILCM) and EDI of personal information. (2014-12-16) ISO/IEC JTC1/SC32/WG1 N0784

3. Other documents

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)

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)


610

496049614962

49634964

4965

49664967

4968

496949704971

49724973

49744975

49764977

49784979

49804981

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

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

ISO/IEC CD 15944-12

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].


612

4982

49834984

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

Documents