ISO/IEC 27701:2019 Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management — Requirements and guidelines

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.

The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).

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. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent declarations received (see http://patents.iec.ch).

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.

This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 27, Security techniques.

Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at www.iso.org/members.html.

Introduction

0.1   General

Almost every organization processes Personally Identifiable Information (PII). Further, the quantity and types of PII processed is increasing, as is the number of situations where an organization needs to cooperate with other organizations regarding the processing of PII. Protection of privacy in the context of the processing of PII is a societal need, as well as the topic of dedicated legislation and/or regulation all over the world.

The Information Security Management System (ISMS) defined in ISO/IEC 27001 is designed to permit the addition of sector specific requirements, without the need to develop a new Management System. ISO Management System standards, including the sector specific ones, are designed to be able to be implemented either separately or as a combined Management System.

Requirements and guidance for PII protection vary depending on the context of the organization, in particular where national legislation and/or regulation exist. ISO/IEC 27001 requires that this context be understood and taken into account. This document includes mapping to:

However, these can need to be interpreted to take into account local legislation and/or regulation.

This document can be used by PII controllers (including those that are joint PII controllers) and PII processors (including those using subcontracted PII processors and those processing PII as subcontractors to PII processors).

An organization complying with the requirements in this document will generate documentary evidence of how it handles the processing of PII. Such evidence can be used to facilitate agreements with business partners where the processing of PII is mutually relevant. This can also assist in relationships with other stakeholders. The use of this document in conjunction with ISO/IEC 27001 can, if desired, provide independent verification of this evidence.

This document was initially developed as ISO/IEC 27552.

0.2   Compatibility with other management system standards

This document applies the framework developed by ISO to improve alignment among its Management System Standards.

This document enables an organization to align or integrate its PIMS with the requirements of other Management System standards.

1 Scope

This document specifies requirements and provides guidance for establishing, implementing, maintaining and continually improving a Privacy Information Management System (PIMS) in the form of an extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy management within the context of the organization.

This document specifies PIMS-related requirements and provides guidance for PII controllers and PII processors holding responsibility and accountability for PII processing.

This document is applicable to all types and sizes of organizations, including public and private companies, government entities and not-for-profit organizations, which are PII controllers and/or PII processors processing PII within an ISMS.

2 Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements 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.

• ISO/IEC 27000 Information technology — Security techniques — Information security management systems — Overview and vocabulary
• ISO/IEC 27001:2013 Information technology — Security techniques — Information security management systems — Requirements
• ISO/IEC 27002:2013 Information technology — Security techniques — Code of practice for information security controls
• ISO/IEC 29100 Information technology — Security techniques — Privacy framework

3 Terms, definitions and abbreviations

For the purposes of this document, the terms and definitions given in ISO/IEC 27000 and ISO/IEC 29100 and the following apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

3.1 joint PII controller

3.2 privacy information management system

4.1 Structure of this document

This is a sector-specific document related to ISO/IEC 27001:2013 and to ISO/IEC 27002:2013.

This document focuses on PIMS-specific requirements. Compliance with this document is based on adherence to these requirements and with the requirements in ISO/IEC 27001:2013. This document extends the requirements of ISO/IEC 27001:2013 to take into account the protection of privacy of PII principals as potentially affected by the processing of PII, in addition to information security. For a better understanding, implementation guidance and other information regarding the requirements is included.

Clause 5 gives PIMS-specific requirements and other information regarding the information security requirements in ISO/IEC 27001 appropriate to an organization acting as either a PII controller or a PII processor.

NOTE 1

For completeness, Clause 5 contains a subclause for each of the clauses containing requirements in ISO/IEC 27001:2013, even in cases where there are no PIMS-specific requirements or other information.

Clause 6 gives PIMS-specific guidance and other information regarding the information security controls in ISO/IEC 27002 and PIMS-specific guidance for an organization acting as either a PII controller or a PII processor.

NOTE 2

For completeness, Clause 6 contains a subclause for each of the clauses containing objectives or controls in ISO/IEC 27002:2013, even in cases where there is no PIMS-specific guidance or other information.

ISO/IEC 27002 guidance for PII controllers, and ISO/IEC 27002 guidance for PII processors.

Annex A lists the PIMS-specific control objectives and controls for an organization acting as a PII controller, (whether it employs a PII processor or not, and whether acting jointly with another PII controller or not).

Annex B lists the PIMS-specific control objectives and controls for an organization acting as a PII processor (whether it subcontracts the processing of PII to a separate PII processor or not, and including those processing PII as subcontractors to PII processors).

Annex C contains a mapping to ISO/IEC 29100.

Annex D contains a mapping of the controls in this document to the European Union General Data Protection Regulation.

Annex E contains a mapping to ISO/IEC 27018 and ISO/IEC 29151.

ISO IEC 27001 and ISO/IEC 27002 are extended to the protection of privacy when processing PII.

4.2 Application of ISO/IEC 27001:2013 requirements

Table 1 gives the location of PIMS-specific requirements in this document in relation to ISO/IEC 27001.

NOTE

The extended interpretation of “information security” according to 5.1 always applies even when there are no PIMS-specific requirements.

4.3 Application of ISO/IEC 27002:2013 guidelines

Table 2 gives the location of PIMS-specific guidance in this document in relation to ISO/IEC 27002.

NOTE

The extended interpretation of “information security” according to 6.1 always applies even when there is no PIMS-specific guidance.

4.4 Customer

Depending on the role of the organization (see 5.2.1), "customer" can be understood as either:

1. a) an organization who has a contract with a PII controller (e.g. the customer of the PII controller);

   NOTE 1

   This can be the case of an organization which is a joint controller.

   NOTE 2

   An individual person in a business to consumer relationship with an organization is referred to as a "PII principal" in this document.

2. b) a PII controller who has a contract with a PII processor (e.g. the customer of the PII processor); or
3. c) a PII processor who has a contract with a subcontractor for PII processing (e.g. the customer of the subcontracted PII sub-processor).

NOTE 3

Where “customer” is referred to in Clause 6, the related provisions can be applicable in contexts a), b), or c).

NOTE 4

Where “customer” is referred to in Clause 7 and Annex A, the relation provisions are applicable in context a).

NOTE 5

Where “customer” is referred to in Clause 8 and Annex B, the relation provisions can be applicable in contexts b) and/or c).

5.1 General

The requirements of ISO/IEC 27001:2013 mentioning "information security" shall be extended to the protection of privacy as potentially affected by the processing of PII.

NOTE

In practice, where "information security" is used in ISO/IEC 27001:2013, "information security and privacy” applies instead (see Annex F).

5.2.1 Understanding the organization and its context

A requirement additional to ISO/IEC 27001:2013, 4.1 is:

The organization shall determine its role as a PII controller (including as a joint PII controller) and/or a PII processor.

The organization shall determine external and internal factors that are relevant to its context and that affect its ability to achieve the intended outcome(s) of its PIMS. For example, these can include:

Where the organization acts in both roles (e.g. a PII controller and a PII processor), separate roles shall be determined, each of which is the subject of a separate set of controls.

NOTE

The role of the organization can be different for each instance of the processing of PII, since it depends on who determines the purposes and means of the processing.

5.2.2 Understanding the needs and expectations of interested parties

A requirement additional to ISO/IEC 27001:2013, 4.2 is:

The organization shall include among its interested parties (see ISO/IEC 27001:2013), those parties having interests or responsibilities associated with the processing of PII, including the PII principals.

NOTE 1

Other interested parties can include customers (see 4.4), supervisory authorities, other PII controllers, PII processors and their subcontractors.

NOTE 2

Requirements relevant to the processing of PII can be determined by legal and regulatory requirements, by contractual obligations and by self-imposed organizational objectives. The privacy principles set out in ISO/IEC 29100 provide guidance concerning the processing of PII.

NOTE 3

As an element to demonstrate compliance to the organization's obligations, some interested parties can expect that the organization be in conformity with specific standards, such as the Management System specified in this document, and/or any relevant set of specifications. These parties can call for independently audited compliance to these standards.

5.2.3 Determining the scope of the information security management system

A requirement additional to ISO/IEC 27001:2013, 4.3 is:

When determining the scope of the PIMS, the organization shall include the processing of PII.

NOTE

The determination of the scope of the PIMS can require revising the scope of the information security management system, because of the extended interpretation of “information security” according to 5.1.

5.2.4 Information security management system

A requirement additional to ISO/IEC 27001:2013, 4.4 is:

The organization shall establish, implement, maintain and continually improve a PIMS in accordance with the requirements of ISO/IEC 27001:2013, extended by the requirements in Clause 5.

5.3.1 Leadership and commitment

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.3.2 Policy

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.3.3 Organizational roles, responsibilities and authorities

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.4.1.1 General

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.4.1.2 Information security risk assessment

The requirements stated in ISO/IEC 27001:2013 apply with the following refinements:

ISO/IEC 27001:2013, 6.1.2 c) 1) is refined as follows:

The organization shall apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability, within the scope of the PIMS.

The organization shall apply privacy risk assessment process to identify risks related to the processing of PII, within the scope of the PIMS.

The organization shall ensure throughout the risk assessment processes that the relationship between information security and PII protection is appropriately managed.

NOTE

The organization can either apply an integrated information security and privacy risk assessment process or two separate ones for information security and the risks related to the processing of PII.

ISO/IEC 27001:2013, 6.1.2 d) 1) is refined as follows:

The organization shall assess the potential consequences for both the organization and PII principals that would result if the risks identified in ISO/IEC 27001:2013 c) as refined above, were to materialize.

5.4.1.3 Information security risk treatment

The requirements stated in ISO/IEC 27001:2013 apply with the following additions:

ISO/IEC 27001:2013, 6.1.3 c) is refined as follows:

The controls determined in ISO/IEC 27001:2013 b) shall be compared with the controls in Annex A and/or Annex B and ISO/IEC 27001:2013 to verify that no necessary controls have been omitted.

When assessing the applicability of control objectives and controls from ISO/IEC 27001:2013 for the treatment of risks, the control objectives and controls shall be considered in the context of both risks to information security as well as risks related to the processing of PII, including risks to PII principals.

ISO/IEC 27001:2013, 6.1.3 d) is refined as follows:

Produce a Statement of Applicability that contains:

Not all the control objectives and controls listed in the annexes need to be included in a PIMS implementation. Justification for exclusion can include where the controls are not deemed necessary by the risk assessment, and where they are not required by (or are subject to exceptions under) the legislation and/or regulation including those applicable to the PII principal.

5.4.2 Information security objectives and planning to achieve them

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.5.1 Resources

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.5.2 Competence

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.5.3 Awareness

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.5.4 Communication

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.5.5.1 General

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.5.5.2 Creating and updating

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.5.5.3 Control of documented information

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.6.1 Operational planning and control

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.6.2 Information security risk assessment

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.6.3 Information security risk treatment

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.7.1 Monitoring, measurement, analysis and evaluation

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.7.2 Internal audit

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.7.3 Management review

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.8.1 Nonconformity and corrective action

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

5.8.2 Continual improvement

The requirements stated in ISO/IEC 27001:2013 along with the interpretation specified in 5.1, apply.

6.1 General

The guidelines in ISO/IEC 27002:2013 mentioning "information security" should be extended to the protection of privacy as potentially affected by the processing of PII.

NOTE 1

In practice, where "information security" is used in ISO/IEC 27002:2013, "information security and privacy” applies instead (see Annex F).

All control objectives and controls should be considered in the context of both risks to information security as well as risks to privacy related to the processing of PII.

NOTE 2

Unless otherwise stated by specific provisions in Clause 6, or determined by the organization according to applicable jurisdictions, the same guidance applies for PII controllers and PII processors.

6.2.1.1 Policies for information security

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 5.1.1, Policies for information security, of ISO/IEC 27002:2013 is:

Either by the development of separate privacy policies, or by the augmentation of information security policies, the organization should produce a statement concerning support for and commitment to achieving compliance with applicable PII protection legislation and/or regulation and with the contractual terms agreed between the organization and its partners, its subcontractors and its applicable third parties (customers, suppliers etc.), which should clearly allocate responsibilities between them.

Additional other information for 5.1.1, Policies for information security, of ISO/IEC 27002:2013 is:

Any organization that processes PII, whether a PII controller or a PII processor, should consider applicable PII protection legislation and/or regulation during the development and maintenance of information security policies.

6.2.1.2 Review of the policies for information security

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies:

6.3.1.1 Information security roles and responsibilities

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 6.1.1, Information security roles and responsibilities, of ISO/IEC 27002:2013 is:

The organization should designate a point of contact for use by the customer regarding the processing of PII. When the organization is a PII controller, designate a point of contact for PII principals regarding the processing of their PII (see 7.3.2).

The organization should appoint one or more persons responsible for developing, implementing, maintaining and monitoring an organization-wide governance and privacy program, to ensure compliance with all applicable laws and regulations regarding the processing of PII.

The responsible person should, where appropriate:

NOTE

Such a person is called a data protection officer in some jurisdictions, which define when such a position is required, along with their position and role. This position can be fulfilled by a staff member or outsourced.

6.3.1.2 Segregation of duties

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.3.1.3 Contact with authorities

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.3.1.4 Contact with special interest groups

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.3.1.5 Information security in project management

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.3.2.1 Mobile device policy

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies.

Additional implementation guidance for 6.2.1, Mobile device policy, of ISO/IEC 27002:2013 is:

The organization should ensure that the use of mobile devices does not lead to a compromise of PII.

6.3.2.2 Teleworking

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.4.1.1 Screening

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.4.1.2 Terms and conditions of employment

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.4.2.1 Management responsibilities

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.4.2.2 Information security awareness, education and training

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 7.2.2, Information security awareness, education and training, of ISO/IEC 27002:2013 is:

Measures should be put in place, including awareness of incident reporting, to ensure that relevant staff are aware of the possible consequences to the organization (e.g. legal consequences, loss of business and brand or reputational damage), to the staff member (e.g. disciplinary consequences) and to the PII principal (e.g. physical, material and emotional consequences) of breaching privacy or security rules and procedures, especially those addressing the handling of PII.

NOTE

Such measures can include the use of appropriate periodic training for personnel having access to PII.

6.4.2.3 Disciplinary procedures

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.4.3.1 Termination or change of employment responsibilities

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.5.1.1 Inventory of assets

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.5.1.2 Ownership of assets

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.5.1.3 Acceptable use of assets

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.5.1.4 Return of assets

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.5.2.1 Classification of information

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 8.2.1, Classification of Information, of ISO/IEC 27002:2013 is:

The organization's information classification system should explicitly consider PII as part of the scheme it implements. Considering PII within the overall classification system is integral to understanding what PII the organization processes (e.g. type, special categories), where such PII is stored and the systems through which it can flow.

6.5.2.2 Labelling of information

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies.

Additional implementation guidance for 8.2.2, labelling of information, of ISO/IEC 27002:2013 is:

The organization should ensure that people under its control are made aware of the definition of PII and how to recognize information that is PII.

6.5.2.3 Handling of assets

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.5.3.1 Management of removable media

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 8.3.1, Management of removable media, of ISO/IEC 27002:2013 is:

The organization should document any use of removable media and/or devices for the storage of PII. Wherever feasible, the organization should use removable physical media and/or devices that permit encryption when storing PII. Unencrypted media should only be used where unavoidable, and in instances where unencrypted media and/or devices are used, the organization should implement procedures and compensating controls (e.g. tamper-evident packaging) to mitigate risks to the PII.

Additional other information for 8.3.1, Management of removable media, of ISO/IEC 27002:2013 is:

Removable media which is taken outside the physical confines of the organization is prone to loss, damage and inappropriate access. Encrypting removable media adds a level of protection for PII which reduces security and privacy risks should the removable media be compromised.

6.5.3.2 Disposal of media

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies.

Additional implementation guidance for 8.3.2, Disposal of media, of ISO/IEC 27002:2013 is:

Where removable media on which PII is stored is disposed of, secure disposal procedures should be included in the documented information and implemented to ensure that previously stored PII will not be accessible.

6.5.3.3 Physical media transfer

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 8.3.3, Physical media transfer, of ISO/IEC 27002:2013 is:

If physical media is used for information transfer, a system should be put in place to record incoming and outgoing physical media containing PII, including the type of physical media, the authorized sender/recipients, the date and time, and the number of physical media. Where possible, additional measures such as encryption should be implemented to ensure that the data can only be accessed at the point of destination and not in transit.

The organization should subject physical media containing PII before leaving its premises to an authorization procedure and ensure the PII is not accessible to anyone other than authorized personnel.

NOTE

One possible measure to ensure PII on physical media leaving the organization’s premises is not generally accessible is to encrypt the PII concerned and restrict decryption capabilities to authorized personnel.

6.6.1.1 Access control policy

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.6.1.2 Access to networks and network services

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.6.2.1 User registration and de-registration

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 9.2.1, User registration and de-registration, of ISO/IEC 27002:2013 is:

Procedures for registration and de-registration of users who administer or operate systems and services that process PII should address the situation where user access control for those users is compromised, such as the corruption or compromise of passwords or other user registration data (e.g. as a result of inadvertent disclosure).

The organization should not reissue to users any de-activated or expired user IDs for systems and services that process PII.

In the case where the organization is providing PII processing as a service, the customer can be responsible for some or all aspects of user ID management. Such cases should be included in the documented information.

Some jurisdictions impose specific requirements regarding the frequency of checks for unused authentication credentials related to systems that process PII. Organizations operating in these jurisdictions should take compliance with these requirements into account.

6.6.2.2 User access provisioning

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 9.2.2, User access provisioning, of ISO/IEC 27002:2013 is:

The organization should maintain an accurate, up-to-date record of the user profiles created for users who have been authorized access to the information system and the PII contained therein. This profile comprises the set of data about that user, including user ID, necessary to implement the identified technical controls providing authorized access.

Implementing individual user access IDs enables appropriately configured systems to identify who accessed PII and what additions, deletions or changes they made. As well as protecting the organization, users are also protected as they can identify what they have processed and what they have not processed.

In the case where the organization is providing PII processing as a service, the customer can be responsible for some or all aspects of access management. Where appropriate, the organization should provide the customer the means to perform access management, such as by providing administrative rights to manage or terminate access. Such cases should be included in the documented information.

6.6.2.3 Management of privileged access rights

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies:

6.6.2.4 Management of secret authentication information of users

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.6.2.5 Review of user access rights

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.6.2.6 Removal or adjustment of access rights

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.6.3.1 Use of secret authentication information

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.6.4.1 Information access restriction

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.6.4.2 Secure log-on procedures

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 9.4.2, Secure log-on procedures, of ISO/IEC 27002:2013 is:

Where required by the customer, the organization should provide the capability for secure log-on procedures for any user accounts under the customer's control.

6.6.4.3 Password management system

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.6.4.4 Use of privileged utility programs

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.6.4.5 Access control to program source code

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.7.1.1 Policy on the use of cryptographic controls

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 10.1.1, Policy on the use of cryptographic controls, of ISO/IEC 27002:2013 is:

Some jurisdictions can require the use of cryptography to protect particular kinds of PII, such as health data, resident registration numbers, passport numbers and driver's licence numbers.

The organization should provide information to the customer regarding the circumstances in which it uses cryptography to protect the PII it processes. The organization should also provide information to the customer about any capabilities it provides that can assist the customer in applying their own cryptographic protection.

6.7.1.2 Key management

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.1.1 Physical security perimeter

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.1.2 Physical entry controls

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.1.3 Securing offices, rooms and facilities

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.1.4 Protecting against external and environmental threats

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.1.5 Working in secure areas

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.1.6 Delivery and loading areas

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.2.1 Equipment siting and protection

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.2.2 Supporting utilities

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.2.3 Cabling security

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.2.4 Equipment maintenance

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.2.5 Removal of assets

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.2.6 Security of equipment and assets off-premises

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.2.7 Secure disposal or re-use of equipment

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 11.2.7, Secure disposal or re-use of equipment, of ISO/IEC 27002:2013 is:

The organization should ensure that, whenever storage space is re-assigned, any PII previously residing on that storage space is not accessible.

On deletion of PII held in an information system, performance issues can mean that explicit erasure of that PII is impractical. This creates the risk that another user can access the PII. Such risk should be avoided by specific technical measures.

For secure disposal or re-use, equipment containing storage media that can possibly contain PII should be treated as though it does contain PII.

6.8.2.8 Unattended user equipment

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.8.2.9 Clear desk and clear screen policy

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 11.2.9, Clear desk and clear screen policy, of ISO/IEC 27002:2013 is:

The organization should restrict the creation of hardcopy material including PII to the minimum needed to fulfil the identified processing purpose.

6.9.1.1 Documenting operating procedures

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.9.1.2 Change management

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.9.1.3 Capacity management

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.9.1.4 Separation of development, testing and operational environments

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.9.2.1 Controls against malware

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.9.3.1 Information backup

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 12.3.1, Information backup, of ISO/IEC 27002:2013 is:

The organization should have a policy which addresses the requirements for backup, recovery and restoration of PII (which can be part of an overall information backup policy) and any further requirements (e.g. contractual and/or legal requirements) for the erasure of PII contained in information held for backup requirements.

PII-specific responsibilities in this respect can depend on the customer. The organization should ensure that the customer has been informed of the limits of the service regarding backup.

Where the organization explicitly provides backup and restore services to customers, the organization should provide them with clear information about their capabilities with respect to backup and restoration of PII.

Some jurisdictions impose specific requirements regarding the frequency of backups of PII, the frequency of reviews and tests of backup, or regarding the recovery procedures for PII. Organizations operating in these jurisdictions should demonstrate compliance with these requirements.

There can be occasions where PII needs to be restored, perhaps due to a system malfunction, attack or disaster. When PII is restored (typically from backup media), processes need to be in place to ensure that the PII is restored into a state where the integrity of PII can be assured, and/or where PII inaccuracy and/or incompleteness is identified and processes put in place to resolve them (which can involve the PII principal).

The organization should have a procedure for, and a log of, PII restoration efforts. At a minimum, the log of the PII restoration efforts should contain:

Some jurisdictions prescribe the content of the logs of PII restoration efforts. Organizations should be able to document compliance with any applicable jurisdiction-specific requirements for restoration log content. The conclusions of such deliberations should be included in documented information.

The use of subcontractors to store replicated or backup copies of PII processed is covered by the controls in this document applying to subcontracted PII processing (see 6.5.3.3, 6.12.1.2). Where physical media transfers take place related to backups and restoration, this is also covered by controls in this document (6.10.2.1).

6.9.4.1 Event logging

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 12.4.1, Event logging, of ISO/IEC 27002:2013 is:

A process should be put in place to review event logs using continuous, automated monitoring and alerting processes, or else manually where such review should be performed with a specified, documented periodicity, to identify irregularities and propose remediation efforts.

Where possible, event logs should record access to PII, including by whom, when, which PII principal's PII was accessed, and what (if any) changes were made (additions, modifications or deletions) as a result of the event.

Where multiple service providers are involved in providing services, there can be varied or shared roles in implementing this guidance. These roles should be clearly defined and included in the documented information, and agreement on any log access between providers should be addressed.

Implementation guidance for PII processors:

The organization should define criteria regarding if, when and how log information can be made available to or usable by the customer. These criteria should be made available to the customer.

Where the organization permits its customers to access log records controlled by the organization, the organization should implement appropriate controls to ensure that the customer can only access records that relate to that customer’s activities, cannot access any log records which relate to the activities of other customers, and cannot amend the logs in any way.

6.9.4.2 Protection of log information

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 12.4.2, Protection of log information, of ISO/IEC 27002:2013 is:

Log information recorded for, for example, security monitoring and operational diagnostics, can contain PII. Measures such as controlling access (see ISO/IEC 27002:2013) should be put in place to ensure that logged information is only used as intended.

A procedure, preferably automatic, should be put in place to ensure that logged information is either deleted or de-identified as specified in the retention schedule (see 7.4.7).

6.9.4.3 Administrator and operator logs

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.9.4.4 Clock synchronization

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.9.5.1 Installation of software on operational systems

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.9.6.1 Management of technical vulnerabilities

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.9.6.2 Restriction on software installation

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.9.7.1 Information systems audit controls

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.10.1.1 Network controls

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.10.1.2 Security in network services

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.10.1.3 Segregation in networks

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.10.2.1 Information transfer policies and procedures

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 13.2.1, Information transfer policies and procedures, of ISO/IEC 27002:2013 is:

The organization should consider procedures for ensuring that rules related to the processing of PII are enforced throughout and outside of the system, where applicable.

6.10.2.2 Agreements for information transfer

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.10.2.3 Electronic messaging

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.10.2.4 Confidentiality or non-disclosure agreements

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 13.2.4, Confidentiality or non-disclosure agreements, of ISO/IEC 27002:2013 is:

The organization should ensure that individuals operating under its control with access to PII are subject to a confidentiality obligation. The confidentiality agreement, whether part of a contract or separate, should specify the length of time the obligations should be adhered to.

When the organization is a PII processor, a confidentiality agreement, in whatever form, between the organization, its employees and its agents should ensure that employees and agents comply with the policy and procedures concerning data handling and protection.

6.11.1.1 Information security requirements analysis and specification

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.11.1.2 Securing application services on public networks

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 14.1.2, Securing application services on public networks, of ISO/IEC 27002:2013 is:

The organization should ensure that PII that is transmitted over untrusted data transmission networks is encrypted for transmission.

Untrusted networks can include the public internet and other facilities outside of the operational control of the organization.

NOTE

In some cases (e.g. the exchange of e-mail) the inherent characteristics of untrusted data transmission network systems can require that some header or traffic data be exposed for effective transmission.

6.11.1.3 Protecting application services transactions

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.11.2.1 Secure development policy

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies.

Additional implementation guidance for 14.2.1, Secure development policy, of ISO/IEC 27002:2013 is:

Policies for system development and design should include guidance for the organization’s processing of PII needs, based on obligations to PII principals and/or any applicable legislation and/or regulation and the types of processing performed by the organization. Clauses 7 and 8 provide control considerations for processing of PII, which can be useful in developing policies for privacy in systems design.

Policies that contribute to privacy by design and privacy by default should consider the following aspects:

1. a) guidance on PII protection and the implementation of the privacy principles (see ISO/IEC 29100) in the software development lifecycle;
2. b) privacy and PII protection requirements in the design phase, which can be based on the output from a privacy risk assessment and/or a privacy impact assessment (see 7.2.5);
3. c) PII protection checkpoints within project milestones;
4. d) required privacy and PII protection knowledge;
5. e) by default minimize processing of PII.

6.11.2.2 System change control procedures

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.11.2.3 Technical review of applications after operating platform changes

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.11.2.4 Restrictions of changes to software packages

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.11.2.5 Secure systems engineering principles

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 14.2.5, Secure systems engineering principles, of ISO/IEC 27002:2013 is:

Systems and/or components related to the processing of PII should be designed following the principles of privacy by design and privacy by default, and to anticipate and facilitate the implementation of relevant controls (as described in Clauses 7 and 8, for PII controllers and PII processors, respectively), in particular such that the collection and processing of PII in those systems is limited to what is necessary for the identified purposes of the processing of PII (see 7.2).

For example, an organization that processes PII should ensure that, based on the relevant jurisdiction, it disposes of PII after a specified period. The system that processes that PII should be designed in a way to facilitate this deletion requirement.

6.11.2.6 Secure development environment

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.11.2.7 Outsourced development

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies.

Additional implementation guidance for 14.2.7, Outsourced development, of ISO/IEC 27002:2013 is:

The same principles (see 6.11.2.5) of privacy by design and privacy by default should be applied, if applicable, to outsourced information systems.

6.11.2.8 System security testing

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.11.2.9 System acceptance testing

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.11.3.1 Protection of test data

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 14.3.1, Protection of test data, of ISO/IEC 27002:2013 is:

PII should not be used for testing purposes; false or synthetic PII should be used. Where the use of PII for testing purposes cannot be avoided, technical and organizational measures equivalent to those used in the production environment should be implemented to minimize the risks. Where such equivalent measures are not feasible, a risk-assessment should be undertaken and used to inform the selection of appropriate mitigating controls.

6.12.1.1 Information security policy for supplier relationships

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.12.1.2 Addressing security within supplier agreements

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 15.1.2, Addressing security within supplier agreements, of ISO/IEC 27002:2013 is:

The organization should specify in agreements with suppliers whether PII is processed and the minimum technical and organizational measures that the supplier needs to meet in order for the organization to meet its information security and PII protection obligations (see 7.2.6 and 8.2.1).

Supplier agreements should clearly allocate responsibilities between the organization, its partners, its suppliers and its applicable third parties (customers, suppliers, etc.) taking into account the type of PII processed.

The agreements between the organization and its suppliers should provide a mechanism for ensuring the organization supports and manages compliance with all applicable legislation and/or regulation. The agreements should call for independently audited compliance, acceptable to the customer.

NOTE

For such audit purposes, compliance with relevant and applicable security and privacy standards such as ISO/IEC 27001 or this document can be considered.

Implementation guidance for PII processors

The organization should specify in contracts with any suppliers that PII is only processed on its instructions.

6.12.1.3 Information and communication technology supply chain

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.12.2.1 Monitoring and review of supplier services

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.12.2.2 Managing changes to supplier services

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.13.1.1 Responsibilities and procedures

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 16.1.1, Responsibilities and procedures, of ISO/IEC 27002:2013 is:

As part of the overall information security incident management process, the organization should establish responsibilities and procedures for the identification and recording of breaches of PII. Additionally, the organization should establish responsibilities and procedures related to notification to required parties of PII breaches (including the timing of such notifications) and the disclosure to authorities, taking into account the applicable legislation and/or regulation.

Some jurisdictions impose specific regulations regarding breach responses, including notification. Organizations operating in these jurisdictions should ensure that they can demonstrate compliance with these regulations.

6.13.1.2 Reporting information security events

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.13.1.3 Reporting information security weaknesses

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.13.1.4 Assessment of and decisions on information security events

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.13.1.5 Response to information security incidents

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 16.1.5, Response to information security incidents, of ISO/IEC 27002:2013 is:

Implementation guidance for PII controllers

An incident that involves PII should trigger a review by the organization, as part of its information security incident management process, to determine if a breach involving PII that requires a response has taken place.

An event does not necessarily trigger such a review.

NOTE 1

An information security event does not necessarily result in actual, or the significant probability of, unauthorized access to PII or to any of the organization’s equipment or facilities storing PII. These can include, but are not limited to, pings and other broadcast attacks on firewalls or edge servers, port scans, unsuccessful log-on attempts, denial of service attacks and packet sniffing.

When a breach of PII has occurred, response procedures should include relevant notifications and records.

Some jurisdictions define cases when the breach should be notified to the supervisory authority, and when it should be notified to PII principals.

Notifications should be clear and can be required.

NOTE 2

Notification can contain details such as:

NOTE 3

Information on the management of security incidents can be found in the ISO/IEC 27035 series.

Where a breach involving PII has occurred, a record should be maintained with sufficient information to provide a report for regulatory and/or forensic purposes, such as:

In the event that a breach involving PII has occurred, the record should also include a description of the PII compromised, if known; and if notifications were performed, the steps taken to notify PII principals, regulatory agencies or customers.

Implementation guidance for PII processors

Provisions covering the notification of a breach involving PII should form part of the contract between the organization and the customer. The contract should specify how the organization will provide the information necessary for the customer to fulfil their obligation to notify relevant authorities. This notification obligation does not extend to a breach caused by the customer or PII principal or within system components for which they are responsible. The contract should also define expected and externally mandated limits for notification response times.

In some jurisdictions, the PII processor should notify the PII controller of the existence of a breach without undue delay (i.e. as soon as possible), preferably, as soon as it is discovered so that the PII controller can take the appropriate actions.

Where a breach involving PII has occurred, a record should be maintained with sufficient information to provide a report for regulatory and/or forensic purposes, such as:

In the event that a breach involving PII has occurred, the record should also include a description of the PII compromised, if known; and if notifications were performed, the steps taken to notify the customer and/or the regulatory agencies.

In some jurisdictions, applicable legislation and/or regulation can require the organization to directly notify appropriate regulatory authorities (e.g. a PII protection authority) of a breach involving PII.

6.13.1.6 Learning from information security incidents

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.13.1.7 Collection of evidence

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies:

6.14.1.1 Planning information security continuity

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.14.1.2 Implementing information security continuity

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.14.1.3 Verify, renew and evaluate information security continuity

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.14.2.1 Availability of information processing facilities

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.15.1.1 Identification of applicable legislation and contractual requirements

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional other information for 18.1.1, Identification of applicable legislation and contractual requirements, of ISO/IEC 27002:2013 is:

The organization should identify any potential legal sanctions (which can result from some obligations being missed) related to the processing of PII, including substantial fines directly from the local supervisory authority. In some jurisdictions, International Standards such as this document can be used to form the basis for a contract between the organization and the customer, outlining their respective security, privacy and PII protection responsibilities. The terms of the contract can provide a basis for contractual sanctions in the event of a breach of those responsibilities.

6.15.1.2 Intellectual property rights

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.15.1.3 Protection of records

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 18.1.3, Protection of records, of ISO/IEC 27002:2013 is:

Review of current and historical policies and procedures can be required (e.g. in the cases of customer dispute resolution and investigation by a supervisory authority).

The organization should retain copies of its privacy policies and associated procedures for a period as specified in its retention schedule (see 7.4.7). This includes retention of previous versions of these documents when they are updated.

6.15.1.4 Privacy and protection of personally identifiable information

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.15.1.5 Regulation of cryptographic controls

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.15.2.1 Independent review of information security

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 18.2.1, Independent review of information security, of ISO/IEC 27002:2013 is:

Where an organization is acting as a PII processor, and where individual customer audits are impractical or can increase risks to security, the organization should make available to customers, prior to entering into, and for the duration of, a contract, independent evidence that information security is implemented and operated in accordance with the organization’s policies and procedures. A relevant independent audit, as selected by the organization, should normally be an acceptable method for fulfilling the customer's interest in reviewing the organization’s processing operations, if it covers the needs of anticipated users and if results are provided in a sufficient transparent manner.

6.15.2.2 Compliance with security policies and standards

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 applies.

6.15.2.3 Technical compliance review

The control, implementation guidance and other information stated in ISO/IEC 27002:2013 and the following additional guidance applies:

Additional implementation guidance for 18.2.3, Technical compliance review, of ISO/IEC 27002:2013 is:

As part of technical reviews of compliance with security policies and standards, the organization should include methods of reviewing those tools and components related to processing PII. This can include:

7.1 General

The guidance in Clause 6 and the additions in this clause create the PIMS-specific guidance for PII controllers. The implementation guidance documented in this clause relate to the controls listed in Annex A.

7.2 Conditions for collection and processing

7.2.1 Identify and document purpose

Control

The organization should identify and document the specific purposes for which the PII will be processed.

Implementation guidance

The organization should ensure that PII principals understand the purpose for which their PII is processed. It is the responsibility of the organization to clearly document and communicate this to PII principals. Without a clear statement of the purpose for processing, consent and choice cannot be adequately given.

Documentation of the purpose(s) for processing PII should be sufficiently clear and detailed to be usable in the required information to be provided to PII principals (see 7.3.2). This includes information necessary to obtain consent (see 7.2.3), as well as records of policies and procedures (see 7.2.8).

Other information

In the deployment of cloud computing services, the taxonomy and definitions in ISO/IEC 19944 can be helpful in providing terms for describing the purpose of the processing of PII.

7.2.2 Identify lawful basis

Control

The organization should determine, document and comply with the relevant lawful basis for the processing of PII for the identified purposes.

Implementation guidance

Some jurisdictions require the organization to be able to demonstrate that the lawfulness of processing was duly established before the processing.

The legal basis for the processing of PII can include:

The organization should document this basis for each PII processing activity (see 7.2.8).

The legitimate interests of the organization can include, for instance, information security objectives, which should be balanced against the obligations to PII principals with regards to privacy protection.

Whenever special categories of PII are defined, either by the nature of the PII (e.g. health information) or by the PII principals concerned (e.g. PII relating to children) the organization should include those categories of PII in its classification schemes.

The classification of PII that falls into these categories can vary from one jurisdiction to another and can vary between different regulatory regimes that apply to different kinds of business, so the organization needs to be aware of the classification(s) that apply to the PII processing being performed.

The use of special categories of PII can also be subject to more stringent controls.

Changing or extending the purposes for the processing of PII can require updating and/or revision of the legal basis. It can also require additional consent to be obtained from the PII principal.

7.2.3 Determine when and how consent is to be obtained

Control

The organization should determine and document a process by which it can demonstrate if, when and how consent for the processing of PII was obtained from PII principals.

Implementation guidance

Consent can be required for processing of PII unless other lawful grounds apply. The organization should clearly document when consent needs to be obtained and the requirements for obtaining consent. It can be useful to correlate the purpose(s) for processing with information about if and how consent is obtained.

Some jurisdictions have specific requirements for how consent is collected and recorded (e.g. not bundled with other agreements). Additionally, certain types of data collection (for scientific research for example) and certain types of PII principals, such as children, can be subject to additional requirements. The organization should take into account such requirements and document how mechanisms for consent meet those requirements.

7.2.4 Obtain and record consent

Control

The organization should obtain and record consent from PII principals according to the documented processes.

Implementation guidance

The organization should obtain and record consent from PII principals in such a way that it can provide on request details of the consent provided (for example the time that consent was provided, the identification of the PII principal, and the consent statement).

The information delivered to the PII principal before the consent process should follow the guidance in 7.3.3.

The consent should be:

7.2.5 Privacy impact assessment

Control

The organization should assess the need for, and implement where appropriate, a privacy impact assessment whenever new processing of PII or changes to existing processing of PII is planned.

Implementation guidance

PII processing generates risks for PII principals. These risks should be assessed through a privacy impact assessment. Some jurisdictions define cases for which a privacy impact assessment is mandated. Criteria can include automated decision making which produces legal effects on PII principals, large scale processing of special categories of PII (e.g. health-related information, racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data or biometric data), or systematic monitoring of a publicly accessible area on a large scale.

The organization should determine the elements that are necessary for the completion of a privacy impact assessment. These can include a list of the types of PII processed, where the PII is stored and where it can be transferred. Data flow diagrams and data maps can also be helpful in this context (see 7.2.8 for details of records of the processing of PII that can inform a privacy impact or other risk assessment).

Other information

Guidance on privacy impact assessments related to the processing of PII can be found in ISO/IEC 29134.

7.2.6 Contracts with PII processors

Control

The organization should have a written contract with any PII processor that it uses, and should ensure that their contracts with PII processors address the implementation of the appropriate controls in Annex B.

Implementation guidance

The contract between the organization and any PII processor processing PII on its behalf should require the PII processor to implement the appropriate controls specified in Annex B, taking account of the information security risk assessment process (see 5.4.1.2) and the scope of the processing of PII performed by the PII processor (see 6.12). By default, all controls specified in Annex B should be assumed as relevant. If the organization decides to not require the PII processor to implement a control from Annex B, it should justify its exclusion (see 5.4.1.3).

A contract can define the responsibilities of each party differently but, to be consistent with this document, all controls should be considered and included in the documented information.

7.2.7 Joint PII controller

Control

The organization should determine respective roles and responsibilities for the processing of PII (including PII protection and security requirements) with any joint PII controller.

Implementation guidance

Roles and responsibilities for the processing of PII should be determined in a transparent manner.

These roles and responsibilities should be documented in a contract or any similar binding document that contains the terms and conditions for the joint processing of PII. In some jurisdictions, such an agreement is called a data sharing agreement.

A joint PII controller agreement can include (this list is neither definitive nor exhaustive):

7.2.8 Records related to processing PII

Control

The organization should determine and securely maintain the necessary records in support of its obligations for the processing of PII.

Implementation guidance

A way to maintain records of the processing of PII is to have an inventory or list of the PII processing activities that the organization performs. Such an inventory can include:

Such an inventory should have an owner who is responsible for its accuracy and completeness.

7.3 Obligations to PII principals

7.3.1 Determining and fulfilling obligations to PII principals

Control

The organization should determine and document their legal, regulatory and business obligations to PII principals related to the processing of their PII and provide the means to meet these obligations.

Implementation guidance

Obligations to PII principals and the means to support them vary from one jurisdiction to another.

The organization should ensure that they provide the appropriate means to meet the obligations to PII principals in an accessible and timely manner. Clear documentation should be provided to the PII principal describing the extent to which the obligations to them are fulfilled and how, along with an up-to-date contact point where they can address their requests.

The contact point should be provided in a similar way to that used to collect PII and consent (e.g. if PII are collected by email or a website, the contact point should be by email or the website, not an alternative such as phone or fax).

7.3.2 Determining information for PII principals

Control

The organization should determine and document the information to be provided to PII principals regarding the processing of their PII and the timing of such a provision.

Implementation guidance

The organization should determine the legal, regulatory and/or business requirements for when information is to be provided to the PII principal (e.g. prior to processing, within a certain time from when it is requested, etc.) and for the type of information to be provided.

Depending on the requirements, the information can take the form of a notice. Examples of types of information that can be provided to PII principals are:

The organization should provide updated information if the purposes for the processing of PII are changed or extended.

7.3.3 Providing information to PII principals

Control

The organization should provide PII principals with clear and easily accessible information identifying the PII controller and describing the processing of their PII.

Implementation guidance

The organization should provide the information detailed in 7.3.2 to PII principals in a timely, concise, complete, transparent, intelligible and easily accessible form, using clear and plain language, as appropriate to the target audience.

Where appropriate, the information should be given at the time of PII collection. It should also be permanently accessible.

NOTE

Icons and images can be helpful to the PII principal by giving a visual overview of the intended processing.

7.3.4 Providing mechanism to modify or withdraw consent

Control

The organization should provide a mechanism for PII principals to modify or withdraw their consent.

Implementation guidance

The organization should inform PII principals of their rights related to withdrawing consent (which may vary by jurisdiction) at any time, and provide the mechanism to do so. The mechanism used for withdrawal depends on the system; it should be consistent with the mechanisms used for obtaining consent when possible. For example, if the consent is collected by email or a website, the mechanism for withdrawing it should be the same, not an alternative solution such as phone or fax.

Modifying consent can include placing restrictions on the processing of PII, which can include restricting the PII controller from deleting the PII in some cases.

Some jurisdictions impose restrictions on when and how a PII principal can modify or withdraw their consent.

The organization should record any request to withdraw or change consent in a similar way to the recording of the consent itself.

Any change of consent should be disseminated, through appropriate systems, to authorized users and to relevant third parties.

The organization should define a response time and requests should be handled according to it.

Additional information

When consent for particular processing of PII is withdrawn, all the processing of PII performed before withdrawal should normally be considered as appropriate, but the results of such processing should not be used for new processing. For example, if a PII principal withdraws their consent for profiling, their profile should not be further used or consulted.

7.3.5 Providing mechanism to object to PII processing

Control

The organization should provide a mechanism for PII principals to object to the processing of their PII.

Implementation guidance

Some jurisdictions provide PII principals with a right to object to the processing of their PII. Organizations subject to the legislation and/or regulation of such jurisdictions should ensure that they implement appropriate measures to enable PII principals to exercize this right.

The organization should document the legal and regulatory requirements related to objections by the PII principals to processing (e.g. objection relating to the processing of PII for direct marketing purposes). The organization should provide information to principals regarding the ability to object in these situations. Mechanisms to object can vary, but should be consistent with the type of service provided (e.g. online services should provide this capability online).

7.3.6 Access, correction and/or erasure

Control

The organization should implement policies, procedures and/or mechanisms to meet their obligations to PII principals to access, correct and/or erase their PII.

Implementation guidance

The organization should implement policies, procedures and/or mechanisms for enabling PII principals to obtain access to, correct and erase of their PII, if requested and without undue delay.

The organization should define a response time and requests should be handled according to it.

Any corrections or erasures should be disseminated through the system and/or to authorized users, and should be passed to third parties (see 7.3.7) to whom the PII has been transferred.

NOTE

Records generated by the control specified in 7.5.3 can help in this regard.

The organization should implement policies, procedures and/or mechanisms for use when there can be a dispute about the accuracy or correction of the data by the PII principal. These policies, procedures and/or mechanisms should include informing the PII principal of what changes were made, and of reasons why corrections cannot be made (where this is the case).

Some jurisdictions impose restrictions on when and how a PII principal can request correction or erasure of their PII. The organization should determine these restrictions as applicable and keep itself up-to-date about them.

7.3.7 PII controllers' obligations to inform third parties

Control

The organization should inform third parties with whom PII has been shared of any modification, withdrawal or objections pertaining to the shared PII, and implement appropriate policies, procedures and/or mechanisms to do so.

Implementation guidance

The organization should take appropriate steps, bearing in mind the available technology, to inform third parties of any modification or withdrawal of consent, or objections pertaining to the shared PII. Some jurisdictions impose a legal requirement to inform these third parties of these actions.

The organization should determine and maintain active communication channels with third parties. Related responsibilities can be assigned to individuals in charge of their operations and maintenance. When informing third parties, the organization should monitor their acknowledgement of receipt of the information.

NOTE

Changes resulting from the obligations to PII principals can include modification or withdrawal of consent, requests for correction, erasure, or restrictions on processing, or objections to the processing of PII as requested by the PII principal.

7.3.8 Providing copy of PII processed

Control

The organization should be able to provide a copy of the PII that is processed when requested by the PII principal.

Implementation guidance

The organization should provide a copy of the PII that is processed in a structured, commonly used, format accessible by the PII principal.

Some jurisdictions define cases where the organization should provide a copy of the PII processed in a format allowing portability to the PII principals or to recipient PII controllers (typically structured, commonly used and machine readable).

The organization should ensure that any copies of PII provided to a PII principal relate specifically to that PII principal.

Where the requested PII has already been deleted subject to the retention and disposal policy (as described in 7.4.7), the PII controller should inform the PII principal that the requested PII has been deleted.

In cases where the organization is no longer able to identify the PII principal (e.g. as a result of a de-identification process), the organization should not seek to (re-)identify the PII principals for the sole reason of implementing this control. However, in some jurisdictions, legitimate requests can require that additional information should be requested from the PII principal to enable re-identification and subsequent disclosure.

Where technically feasible, it should be possible to transfer a copy of the PII from one organization directly to another organization, at the request of the PII principal.

7.3.9 Handling requests

Control

The organization should define and document policies and procedures for handling and responding to legitimate requests from PII principals.

Implementation guidance

Legitimate requests can include requests for a copy of PII processed, or requests to lodge a complaint.

Some jurisdictions allow the organization to charge a fee in certain cases (e.g. excessive or repetitive requests).

Requests should be handled within the appropriate defined response times.

Some jurisdictions define response times, depending on the complexity and number of the requests, as well as requirements to inform PII principals of any delay. The appropriate response times should be defined in the privacy policy.

7.3.10 Automated decision making

Control

The organization should identify and address obligations, including legal obligations, to the PII principals resulting from decisions made by the organization which are related to the PII principal based solely on automated processing of PII.

Implementation guidance

Some jurisdictions define specific obligations to PII principals when a decision based solely on automated processing of PII significantly affects them, such as notifying the existence of automated decision making, allowing for the PII principals to object to such decision making, and/or obtaining human intervention.

NOTE

In some jurisdictions, some processing of PII cannot be fully automated.

Organizations operating in these jurisdictions should take compliance with these obligations into account.

7.4 Privacy by design and privacy by default

7.4.1 Limit collection

Control

The organization should limit the collection of PII to the minimum that is relevant, proportional and necessary for the identified purposes.

Implementation guidance

The organization should limit the collection of PII to what is adequate, relevant and necessary in relation to the identified purposes. This includes limiting the amount of PII that the organization collects indirectly (e.g. through web logs, system logs, etc.).

Privacy by default implies that, where any optionality in the collection and processing of PII exists, each option should be disabled by default and only enabled by explicit choice of the PII principal.

7.4.2 Limit processing

Control

The organization should limit the processing of PII to that which is adequate, relevant and necessary for the identified purposes.

Implementation guidance

Limiting the processing of PII should be managed through information security and privacy policies (see 6.2) along with documented procedures for their adoption and compliance.

Processing of PII, including:

should be limited by default to the minimum necessary relative to the identified purposes.

7.4.3 Accuracy and quality

Control

The organization should ensure and document that PII is as accurate, complete and up-to-date as is necessary for the purposes for which it is processed, throughout the life-cycle of the PII.

Implementation guidance

The organization should implement policies, procedures and/or mechanisms to minimize inaccuracies in the PII it processes. There should also be policies, procedures and/or mechanisms to respond to instances of inaccurate PII. These policies, procedures and/or mechanisms should be included in the documented information (e.g. through technical system configurations, etc.) and should apply throughout the PII lifecycle.

Additional information

For further information on the PII processing life-cycle, see ISO/IEC 29101:2018.

7.4.4 PII minimization objectives

Control

The organization should define and document data minimization objectives and what mechanisms (such as de-identification) are used to meet those objectives.

Implementation guidance

Organizations should identify how the specific PII and amount of PII collected and processed is limited relative to the identified purposes. This can include the use of de-identification or other data minimization techniques.

The identified purpose (see 7.2.1) can require the processing of PII that has not been de-identified, in which case the organization should be able to describe such processing.

In other cases, the identified purpose does not require the processing of the original PII, and the processing of PII which has been de-identified can suffice to achieve the identified purpose. In these cases, the organization should define and document the extent to which the PII needs to be associated with the PII principal, as well as the mechanisms and techniques designed to process PII, such that the de-identification and/or PII minimization objectives are achieved.

Mechanisms used to minimize PII vary depending on the type of processing and the systems used for the processing. The organization should document any mechanisms (technical system configurations, etc.) used to implement data minimization.

In cases where processing of de-identified data is sufficient for the purposes, the organization should document any mechanisms (technical system configurations, etc.) designed to implement de-identification objectives set by the organization in a timely manner. For instance, the removal of attributes associated with PII principals can be sufficient to allow the organization to achieve its identified purpose. In other cases, other de-identification techniques, such as generalization (e.g. rounding) or randomization techniques (e.g. noise addition) can be used to achieve an adequate level of de-identification.

NOTE 1

For further information on de-identification techniques, refer to ISO/IEC 20889.

NOTE 2

For Cloud computing, ISO/IEC 19944 provides a definition of data identification qualifiers that can be used to classify the degree to which the data can identify a PII principal or associate a PII principal with a set of characteristics in the PII.

7.4.5 PII de-identification and deletion at the end of processing

Control

The organization should either delete PII or render it in a form which does not permit identification or re-identification of PII principals, as soon as the original PII is no longer necessary for the identified purpose(s).

Implementation guidance

The organization should have mechanisms to erase the PII when no further processing is anticipated. Alternatively, some de-identification techniques can be used as long as the resulting de-identified data cannot reasonably permit re-identification of PII principals.

7.4.6 Temporary files

Control

The organization should ensure that temporary files created as a result of the processing of PII are disposed of (e.g. erased or destroyed) following documented procedures within a specified, documented period.

Implementation guidance

The organization should perform periodic checks that unused temporary files are deleted within the identified time period.

Other information

Information systems can create temporary files in the normal course of their operation. Such files are specific to the system or application, but can include file system roll-back journals and temporary files associated with the updating of databases and the operation of other application software. Temporary files are not needed after the related information processing task has completed but there are circumstances in which they cannot be deleted. The length of time for which these files remain in use is not always deterministic but a “garbage collection” procedure should identify the relevant files and determine how long it has been since they were last used.

7.4.7 Retention

Control

The organization should not retain PII for longer than is necessary for the purposes for which the PII is processed.

Implementation guidance

The organization should develop and maintain retention schedules for information it retains, taking into account the requirement to retain PII for no longer than is necessary. Such schedules should take into account legal, regulatory and business requirements. Where such requirements conflict, a business decision needs to be taken (based on a risk assessment) and documented in the appropriate schedule.

7.4.8 Disposal

Control

The organization should have documented policies, procedures and/or mechanisms for the disposal of PII.

Implementation guidance

The choice of PII disposal techniques depends on a number of factors, as disposal techniques differ in their properties and outcomes (for example in the granularity of the resultant physical media, or the ability to recover deleted information on electronic media). Factors to consider when choosing an appropriate disposal technique include, but are not limited to, the nature and extent of the PII to be disposed of, whether or not there is metadata associated with the PII, and the physical characteristics of the media on which the PII is stored.

7.4.9 PII transmission controls

Control

The organization should subject PII transmitted (e.g. sent to another organization) over a data-transmission network to appropriate controls designed to ensure that the data reaches its intended destination.

Implementation guidance

Transmission of PII needs to be controlled, typically by ensuring that only authorized individuals have access to transmission systems, and by following the appropriate processes (including the retention of audit logs) to ensure that PII is transmitted without compromise to the correct recipients.

7.5 PII sharing, transfer, and disclosure

7.5.1 Identify basis for PII transfer between jurisdictions

Control

The organization should identify and document the relevant basis for transfers of PII between jurisdictions.

Implementation guidance

PII transfer can be subject to legislation and/or regulation depending on the jurisdiction or international organization to which data is to be transferred (and from where it originates). The organization should document compliance to such requirements as the basis for transfer.

Some jurisdictions can require that information transfer agreements be reviewed by a designated supervisory authority. Organizations operating in such jurisdictions should be aware of any such requirements.

NOTE

Where transfers take place within a specific jurisdiction, the applicable legislation and/or regulation are the same for the sender and recipient.

7.5.2 Countries and international organizations to which PII can be transferred

Control

The organization should specify and document the countries and international organizations to which PII can possibly be transferred.

Implementation guidance

The identities of the countries and international organizations to which PII can possibly be transferred in normal operations should be made available to customers. The identities of the countries arising from the use of subcontracted PII processing should be included. The countries included should be considered in relation to 7.5.1.

Outside of normal operations, there can be cases of transfer made at the request of a law enforcement authority, for which the identity of the countries cannot be specified in advance, or is prohibited by applicable jurisdictions to preserve the confidentiality of a law enforcement investigation (see 7.5.1, 8.5.4 and 8.5.5).

7.5.3 Records of transfer of PII

Control

The organization should record transfers of PII to or from third parties and ensure cooperation with those parties to support future requests related to obligations to the PII principals.

Implementation guidance

Recording can include transfers from third parties of PII which has been modified as a result of PII controllers' managing their obligations, or transfers to third parties to implement legitimate requests from PII principals, including requests to erase PII (e.g. after consent withdrawal).

The organization should have a policy defining the retention period of these records.

The organization should apply the data minimization principle to the records of transfers by retaining only the strictly needed information.

7.5.4 Records of PII disclosure to third parties

Control

The organization should record disclosures of PII to third parties, including what PII has been disclosed, to whom and at what time.

Implementation guidance

PII can be disclosed during the course of normal operations. These disclosures should be recorded. Any additional disclosures to third parties, such as those arising from lawful investigations or external audits, should also be recorded. The records should include the source of the disclosure and the source of the authority to make the disclosure.

8.1 General

The guidance in Clause 6 and the additions of this clause create the PIMS-specific guidance for PII processors. The implementation guidance documented in this clause relate to the controls listed in Annex B.

8.2 Conditions for collection and processing

8.2.1 Customer agreement

Control

The organization should ensure, where relevant, that the contract to process PII addresses the organization’s role in providing assistance with the customer’s obligations (taking into account the nature of processing and the information available to the organization).

Implementation guidance

The contract between the organization and the customer should include the following wherever relevant, and depending on the customer's role (PII controller or PII processor) (this list is neither definitive nor exhaustive):

Some jurisdictions require that the contract include the subject matter and duration of the processing, the nature and purpose of the processing, the type of PII and categories of PII principals.

8.2.2 Organization’s purposes

Control

The organization should ensure that PII processed on behalf of a customer are only processed for the purposes expressed in the documented instructions of the customer.

Implementation guidance

The contract between the organization and the customer should include, but not be limited to, the objective and time frame to be achieved by the service.

In order to achieve the customer’s purpose, there can be technical reasons why it is appropriate for the organization to determine the method for processing PII, consistent with the general instructions of the customer but without the customer’s express instruction. For example, in order to efficiently utilize network or processing capacity it can be necessary to allocate specific processing resources depending on certain characteristics of the PII principal.

The organization should allow the customer to verify their compliance with the purpose specification and limitation principles. This also ensures that no PII is processed by the organization or any of its subcontractors for other purposes than those expressed in the documented instructions of the customer.

8.2.3 Marketing and advertising use

Control

The organization should not use PII processed under a contract for the purposes of marketing and advertising without establishing that prior consent was obtained from the appropriate PII principal. The organization should not make providing such consent a condition for receiving the service.

Implementation guidance

Compliance of PII processors with the customer's contractual requirements should be documented, especially where marketing and/or advertising is planned.

Organizations should not insist on the inclusion of marketing and/or advertising uses where express consent has not been fairly obtained from PII principals.

NOTE

This control is in addition to the more general control in 8.2.2 and does not replace or otherwise supersede it.

8.2.4 Infringing instruction

Control

The organization should inform the customer if, in its opinion, a processing instruction infringes applicable legislation and/or regulation.

Implementation guidance

The organization’s ability to verify if the instruction infringes legislation and/or regulation can depend on the technological context, on the instruction itself, and on the contract between the organization and the customer.

8.2.5 Customer obligations

Control

The organization should provide the customer with the appropriate information such that the customer can demonstrate compliance with their obligations.

Implementation guidance

The information needed by the customer can include whether the organization allows for and contributes to audits conducted by the customer or another auditor mandated or otherwise agreed by the customer.

8.2.6 Records related to processing PII

Control

The organization should determine and maintain the necessary records in support of demonstrating compliance with its obligations (as specified in the applicable contract) for the processing of PII carried out on behalf of a customer.

Implementation guidance

Some jurisdictions can require the organization to record information such as:

— categories of processing carried out on behalf of each customer;

— transfers to third countries or international organizations; and

— a general description of the technical and organizational security measures.

8.3 Obligations to PII principals

8.3.1 Obligations to PII principals

Control

The organization should provide the customer with the means to comply with its obligations related to PII principals.

Implementation guidance

A PII controller's obligations can be defined by legislation, by regulation and/or by contract. These obligations can include matters where the customer uses the services of the organization for implementation of these obligations. For example, this can include the correction or deletion of PII in a timely fashion.

Where a customer depends on the organization for information or technical measures to facilitate meeting the obligations to PII principals, the relevant information or technical measures should be specified in a contract.

8.4 Privacy by design and privacy by default

8.4.1 Temporary files

Control

The organization should ensure that temporary files created as a result of the processing of PII are disposed of (e.g. erased or destroyed) following documented procedures within a specified, documented period.

Implementation guidance

The organization should conduct periodic verification that unused temporary files are deleted within the identified time period.

Other information

Information systems can create temporary files in the normal course of their operation. Such files are specific to the system or application, but can include file system roll-back journals and temporary files associated with the updating of databases and the operation of other application software. Temporary files are not needed after the related information processing task has completed but there are circumstances in which they cannot be deleted. The length of time for which these files remain in use is not always deterministic but a “garbage collection” procedure should identify the relevant files and determine how long it has been since they were last used.

8.4.2 Return, transfer or disposal of PII

Control

The organization should provide the ability to return, transfer and/or disposal of PII in a secure manner. It should also make its policy available to the customer.

Implementation guidance

At some point in time, PII can need to be disposed of in some manner. This can involve returning the PII to the customer, transferring it to another organization or to a PII controller (e.g. as a result of a merger), deleting or otherwise destroying it, de-identifying it or archiving it. The capability for the return, transfer and/or disposal of PII should be managed in a secure manner.

The organization should provide the assurance necessary to allow the customer to ensure that PII processed under a contract is erased (by the organization and any of its subcontractors) from wherever they are stored, including for the purposes of backup and business continuity, as soon as they are no longer necessary for the identified purposes of the customer.

The organization should develop and implement a policy in respect to the disposal of PII and should make this policy available to customer when requested.

The policy should cover the retention period for PII before its disposal after termination of a contract, to protect the customer from losing PII through an accidental lapse of the contract.

NOTE

This control and guidance is also relevant under the retention principle (see 7.4.7).

8.4.3 PII transmission controls

Control

The organization should subject PII transmitted over a data-transmission network to appropriate controls designed to ensure that the data reaches its intended destination.

Implementation guidance

Transmission of PII needs to be controlled, typically by ensuring that only authorized individuals have access to transmission systems, and by following the appropriate processes (including the retention of audit data) to ensure that PII is transmitted without compromise to the correct recipients. Requirements for transmission controls can be included in the PII processor — customer contract.

Where no contractual requirements related to transmission are in place, it can be appropriate to take advice from the customer prior to transmission.

8.5 PII sharing, transfer, and disclosure

8.5.1 Basis for PII transfer between jurisdictions

Control

The organization should inform the customer in a timely manner of the basis for PII transfers between jurisdictions and of any intended changes in this regard, so that the customer has the ability to object to such changes or to terminate the contract.

Implementation guidance

PII transfer between jurisdictions can be subject to legislation and/or regulation depending on the jurisdiction or organization to which PII is to be transferred (and from where it originates). The organization should document compliance with such requirements as the basis for transfer.

The organization should inform the customer of any transfer of PII, including transfers to:

In case of changes, the organization should inform the customer in advance, according to an agreed timeframe, so that the customer has the ability to object to such changes or to terminate the contract.

The agreement between the organization and the customer can have clauses where the organization can implement changes without informing the customer. In these cases, the limits of this allowance should be set (e.g. the organization can change suppliers without informing the customer, but cannot transfer PII to other countries).

In case of international transfer of PII, agreements such as Model Contract Clauses, Binding Corporate Rules or Cross Border Privacy Rules, the countries involved and the circumstances in which such agreements apply, should be identified.

8.5.2 Countries and international organizations to which PII can be transferred

Control

The organization should specify and document the countries and international organizations to which PII can possibly be transferred.

Implementation guidance

The identities of the countries and international organizations to which PII can possibly be transferred in normal operations should be made available to customers. The identities of the countries arising from the use of subcontracted PII processing should be included. The countries included should be considered in relation to 8.5.1.

Outside of normal operations, there can be cases of transfer made at the request of a law enforcement authority, for which the identity of the countries cannot be specified in advance, or is prohibited by applicable jurisdictions to preserve the confidentiality of a law enforcement investigation (see 7.5.1, 8.5.4 and 8.5.5).

8.5.3 Records of PII disclosure to third parties

Control

The organization should record disclosures of PII to third parties, including what PII has been disclosed, to whom and when.

Implementation guidance

PII can be disclosed during the course of normal operations. These disclosures should be recorded. Any additional disclosures to third parties, such as those arising from lawful investigations or external audits, should also be recorded. The records should include the source of the disclosure and the source of the authority to make the disclosure.

8.5.4 Notification of PII disclosure requests

Control

The organization should notify the customer of any legally binding requests for disclosure of PII.

Implementation guidance

The organization can receive legally binding requests for disclosure of PII (e.g. from law enforcement authorities). In these cases, the organization should notify the customer of any such request within agreed timeframes and according to an agreed procedure (which can be included in the customer contract).

In some cases, the legally binding requests include the requirement for the organization not to notify anyone about the event (an example of a possible prohibition on disclosure would be a prohibition under criminal law to preserve the confidentiality of a law enforcement investigation).

8.5.5 Legally binding PII disclosures

Control

The organization should reject any requests for PII disclosures that are not legally binding, consult the corresponding customer before making any PII disclosures and accepting any contractually agreed requests for PII disclosures that are authorized by the corresponding customer.

Implementation guidance

Details relevant to the implementation of the control can be included in the customer contract.

Such requests can originate from several sources, including courts, tribunals and administrative authorities. They can arise from any jurisdiction.

8.5.6 Disclosure of subcontractors used to process PII

Control

The organization should disclose any use of subcontractors to process PII to the customer before use.

Implementation guidance

Provisions for the use of subcontractors to process PII should be included in the customer contract.

Information disclosed should cover the fact that subcontracting is used and the names of relevant subcontractors. The information disclosed should also include the countries and international organizations to which subcontractors can transfer data (see 8.5.2) and the means by which subcontractors are obliged to meet or exceed the obligations of the organization (see 8.5.7).

Where public disclosure of subcontractor information is assessed to increase security risk beyond acceptable limits, disclosure should be made under a non-disclosure agreement and/or on the request of the customer. The customer should be made aware that the information is available.

This does not concern the list of countries where the PII can be transferred. This list should be disclosed to the customer in all cases in a way that allows them to inform the appropriate PII principals.

8.5.7 Engagement of a subcontractor to process PII

Control

The organization should only engage a subcontractor to process PII according to the customer contract.

Implementation guidance

Where the organization subcontracts some or all of the processing of that PII to another organization, a written authorization from the customer is required prior to the PII processed by the subcontractor. This can be in the form of appropriate clauses in the customer contract, or can be a specific "one-off" agreement.

The organization should have a written contract with any subcontractors that it uses for PII processing on its behalf, and should ensure that their contracts with subcontractors address the implementation of the appropriate controls in Annex B.

The contract between the organization and any subcontractor processing PII on its behalf should require the subcontractor to implement the appropriate controls specified in Annex B, taking account of the information security risk assessment process (see 5.4.1.2) and the scope of the processing of PII performed by the PII processor (see 6.12). By default, all controls specified in Annex B should be assumed as relevant. If the organization decides to not require the subcontractor to implement a control from Annex B, it should justify its exclusion.

A contract can define the responsibilities of each party differently but, to be consistent with this document, all controls should be considered and included in the documented information.

8.5.8 Change of subcontractor to process PII

Control

The organization should, in the case of having general written authorization, inform the customer of any intended changes concerning the addition or replacement of subcontractors to process PII, thereby giving the customer the opportunity to object to such changes.

Implementation guidance

Where the organization changes the organization with which it subcontracts some or all of the processing of that PII, then written authorization from the customer is required for the change, prior to the PII processed by the new subcontractor. This can be in the form of appropriate clauses in the customer contract, or can be a specific "one-off" agreement.

Annex A PIMS-specific reference control objectives and controls (PII Controllers)

This annex is for use by organizations acting as PII controllers, with or without the use of PII processors. It extends ISO/IEC 27001:2013.

The additional or modified control objectives and controls listed in Table A.1 are directly derived from and aligned with those defined in this document and are to be used in context with ISO/IEC 27001:2013 as refined by 5.4.1.3.

Not all the control objectives and controls listed in this annex need to be included in the PIMS implementation. A justification for excluding any control objectives shall be included in the Statement of Applicability (see 5.4.1.3). Justification for exclusion can include where the controls are not deemed necessary by the risk assessment, and where they are not required by (or are subject to exceptions under) the applicable legislation and/or regulation.

NOTE

Clause numbers in this annex relate to the subclause numbers in Clause 7.

Annex B PIMS-specific reference control objectives and controls (PII Processors)

This annex is for use by organizations acting as PII processors, with or without the use of PII subcontractors. It extends ISO/IEC 27001:2013.

The additional or modified control objectives and controls listed in Table B.1 are directly derived from and aligned with those defined in this document and are to be used in context with ISO/IEC 27001:2013 as refined by 5.4.1.3.

Not all the control objectives and controls listed in this annex need to be included in the PIMS implementation. A justification for excluding any control objectives shall be included in the Statement of Applicability (see 5.4.1.3). Justification for exclusion can include where the controls are not deemed necessary by the risk assessment, and where they are not required by (or are subject to exceptions under) the applicable legislation and/or regulation.

NOTE

Clause numbers in this annex relate to the subclause numbers in Clause 8.

Annex C Mapping to ISO/IEC 29100

Table C.1 and C.2 give an indicative mapping between provisions of this document and the privacy principles from ISO/IEC 29100. It shows in a purely indicative manner how compliance to requirements and controls of this document relates to the general privacy principles specified in ISO/IEC 29100.

Annex D Mapping to the General Data Protection Regulation

This annex gives an indicative mapping between provisions of this document and Articles 5 to 49 except 43 of the General Data Protection Regulation of the European Union. It shows how compliance to requirements and controls of this document can be relevant to fulfil obligations of GDPR.

However, it is purely indicative and as per this document, it is the organizations responsibility to assess its legal obligations and decide how to comply with them.

Annex E Mapping to ISO/IEC 27018 and ISO/IEC 29151

ISO/IEC 27018 gives further information for organizations acting as PII processors and providing public cloud services. ISO/IEC 29151 gives additional controls and guidance for the processing of PII by PII controllers.

Table E.1 gives an indicative mapping between provisions of this document and provisions from ISO/IEC 27018 and ISO/IEC 29151. It shows how requirements and controls of this document can have some correspondence with provisions from ISO/IEC 27018 and/or ISO/IEC 29151.

It is purely indicative and it should not be assumed that a given link between provisions means equivalence.

F.1 How to apply this document

This document is based on ISO/IEC 27001:2013 and ISO/IEC 27002:2013 and extends their requirements and guidance to take into account, in addition to information security, the protection of privacy of PII principals as potentially affected by the processing of PII. That means, where the term "information security" is used in ISO/IEC 27001 or ISO/IEC 27002 "information security and privacy” applies instead.

Table F.1 gives the mapping of the extension of the term information security in order to apply it to this document.

Basically, there are three cases for applying this document to protection of privacy of PII principals when processing PII:

1. 1) Application of security standards as is: The referring standards apply as it is with the extension of terms as listed above. Therefore, the referring standard is not repeated, but only referred to in respective clauses.
2. 2) Additions to security standards: The referring standards apply with additional privacy-specific requirements or implementation guidance.
3. 3) Refinement of security standards: The referring standards are refined by privacy-specific requirements or implementation guidance.

F.2 Example of refinement of security standards

This clause describes how 5.4.1.2 is applied to ISO/IEC 27001:2013.

When taking into account the protection of privacy of PII principals when processing PII, ISO/IEC 27001:2013, 6.1.2, would be amended with the underlined text below:

6.1.2 Information security risk assessment

The organization shall define and apply an information security and privacy risk assessment process that:

1. a) establishes and maintains information security and privacy risk criteria that include:
   1. 1) the risk acceptance criteria; and
   2. 2) criteria for performing information security and privacy risk assessments;
2. b) ensures that repeated information security and privacy risk assessments produce consistent, valid and comparable results;
3. c) identifies the information security and privacy risks:
   1. 1) apply the information security and privacy risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability for information within the scope of the information security and privacy information management system; and
   2. 2) identify the risk owners;
4. d) analyses the information security and privacy risks;
   1. 1) assess the potential consequences that would result if the risks identified in 6.1.2 c) were to materialize;
   2. 2) assess the realistic likelihood of the occurrence of the risks identified in 6.1.2 c) 1); and
   3. 3) determine the levels of risk;
5. e) evaluates the information security and privacy risks:
   1. 1) compare the results of risk analysis with the risk criteria established in 6.1.2 a); and
   2. 2) prioritize the analysed risks for risk treatment.

The organization shall retain documented information about the information security and privacy risk assessment process.

Bibliography