Optimising Guidelines For Personal Information Protection – China Issues Third Draft Amendment To Personal Information Security Specification.

A. 

Distinguished between “authorised consent” and “express consent”

The Specification has mentioned several times that for the processing of PI, in some cases, the express consent of the PI subject should be obtained first, whereas in other cases, only authorised consent need to be obtained. However, the Specification doesn’t state the differences between these two types of consent. Draft III clarifies that authorised consent is used as a general term, whilst express consent refers to a consent meeting specific requirements, that is to say, an express consent refers to, when facing requests raised by a PI controller processing a PI subject’s specific PI, the PI subject’s authorisation of such processing by positive actions (e.g., by written statement). Authorised consent, on the other hand, is defined as including not only the foregoing positive action of authorisation, but also authorisation through passive inactions (e.g., PI subject does not leave that area after being informed of the information collection act).  

Under Draft III, we understand that except for the specified exceptions, for PI controllers’ PI processing activities (including but not limited to collecting, consignment processing (i.e., processing by a third party), sharing, and transferring PI), authorised consent from PI subjects shall be required. However, when such processing may have significant impact on that PI subject (e.g., when collecting, sharing, transferring sensitive PI, or when using PI outside the original purpose of collecting PI, etc.), then it shall be necessary to obtain express consent from the subject.

B. 

Added the requirement of “no compelled acceptance of multiple business functions”

A product or service may have multiple business functions (e.g., a payment application may have several functions such as payment, life services, social networking, etc.), and from a technical perspective, the PI that needed to be collected for each business function can be quite different.

However, in order to collect as much information as possible, some PI controllers would sometimes compel PI subjects to accept multiple business functions and to provide more PI through unreasonable authorisation interface design. In order to prohibit such coercive conduct, Draft III puts forward some special requirements. For example, requiring a PI controller not to compel a PI subject to provide his PI through bundling a product or the service’s multiple business functions which he would not have otherwise applied.

C. 

Added requirements for “use of personalized display”

In the course of providing business functions, e-commerce services, and news information services etc., PI controllers may sometimes provide a PI subject with personalised display based on the individual’s interests, habits, and other characteristics (e.g., some shopping applications may recommend or push specific products to a user based on his browsing history). Currently, relevant display often does not notify PI subjects which pushed information is personalised and which is not. At the same time, PI controllers rarely provide users with the way to withdraw from or manage the extent of personalised display. From the users’ perspective, personalised display does help many people to obtain contents that they are interested in without spending much effort. However, excessive display may also limit users’ convenient access to other type of information. Moreover, since pushed information often reflects the user’s past internet usage behaviour (e.g., browsed content), which may in turn lead to privacy leakage. To address such issues, Draft III added relevant requirements. For example, for e-commerce services, PI controllers are required to provide options to PI subjects to enable them to choose not to display search results on products or services which are based on their personal characteristics.

D. 

Supplemented operational requirements for “PI subject account cancellation”

The amount of users is an important indicator in evaluating the operational status of a network platform. In addition to direct operating revenue, a substantial amount of registered users and registration information can also bring benefits to the platform in respect of in-depth data development and so forth. As such, some platforms deliberately set obstacles to the cancellation of PI subjects’ account, or do not provide cancellation path at all. In order to facilitate protection of account cancellation rights, Draft III supplements the provision on account cancellation in the Specification with several operational requirements. For example, for cancellation requests that needs to be processed manually, a PI controller is required to complete relevant verification and processing within the promised time frame (in principle, no more than 15 days).

E. 

Supplemented several requirements for “consignment processing, sharing, transfer and disclosure of PI”

The current Specification sets out some detailed requirements for the consignment of processing, sharing, transfer, and disclosure of PI. Draft III has, on that basis, made some further supplements. For instance, in terms of “consignment processing” of PI, Draft III supplements that PI controllers shall take remedial measures when finding that a third party who is consigned to process the PI has mishandled such PI. For the “sharing and transfer of PI”, Draft III supplements that PI controllers shall stipulate the responsibilities and obligations of the data receiver by means of contracts, etc. For the “disclosure of PI”, Draft III supplements a requirement that no analysis results of sensitive personal data such as race, nationality, political opinions and religious beliefs of Chinese citizens shall be disclosed; and so on.