Naavi.org

Data in a company is an asset which creates value for the company. The business model of many companies is built on the concept of “Data as Raw Material” and “Processed data as finished product”. In between, there is “Data Under Process which is work in progress”, “Data Discarded as process waste or an effluent”.  Hence “Data” is often seen as a valuable industrial asset by itself.

Just as a machine in the machine manufacturing company is a finished good and is a capital asset in the company where it is used for production, Data in a data processing company is a raw material or a finished good and in another company where it is used as a software or production meta data, it is a “tool of production”. In a manufacturing company where data is generated under the automated machine environment, data is a “Catalyst” or an activity record.

Additionally, “Data” is often used as an “Object of Crime” or a “Tool of Crime” when it becomes the subject matter of criminal laws of the jurisdiction in which the victim of a cyber crime may reside.

Data Processing companies and data protection professionals are often confronted with the conflict between two individuals where one is demanding information and another is resisting disclosure because of a possible violation of his privacy. In such cases, there is a conflict between “Right to information” and “Right to Privacy” both of which are individual constitutionally protected rights. In any practical situation, it may not be easy to decide whose right is legally more acceptable.

One way to resolve such conflicts is to create a documentation of a “Harm Audit” where an expert will document the pros and cons of the requested disclosure and give a value judgement on whether the disclosure be permitted or not.

Similar conflicts may also arise between the “Right of the Data Principal/subject” and the “Legitimate interests” of the organization.

Here again there is a need to conduct a “Harm audit” and document the findings. But a harm audit conducted when there is a reported conflict between the organization and a data subject will involve a “Conflict of interest” when the audit is conducted by an employee of the same organization. Such conflict is found in many activities of the Data Protection Officer and often the resolution in favour of the organization would not be acceptable to the data subject and the matter may end up in a grievance redressal muddle including courts.

In the third kind of conflict where there is a conflict between the need for disclosure to a law enforcement authority for investigation and subsequent prosecution of a crime, the organization is in a more difficult situation as any refusal could lead to the organization itself being charged with “with holding of evidence” or “Non Cooperation with a law enforcement authority” which may be offences by themselves.

When an organization is confronted with such requests from the law enforcement authority, it is essential to recognize that non compliance of the demand is not an option under the law of the land.

What is required under these situations is to first examine whether the demand has come from the right authority and after due process. If so, the demand should be honoured. However if the demand could be honoured with the use of disclosure of pseudonymous information (which may not be acceptable when the request is for identification of a potential criminal himself), only pseudonymous information may be disclosed.

Where the personal data to be released is part of the protected Personal Data under a law (eg personal data of a EU citizen protected under GDPR), then there is a possibility that the action of disclosure may come under the scrutiny of the EU regulatory authority.

While all data protection laws recognize the sovereign rights of the country where processing takes place and provides for exemption, there could be a need for the data importer-processor who has received the law enforcement demand to inform the data exporter.

While sending such requests either before or after the disclosure to the law enforcement agency, it would be better for the Data Importer to document a “Disclosure Approval” by recording a legitimate interest  indicating the compelling need for disclosure arising out of the demand from a verified law enforcement agency and documenting also the harm that may be caused if any to one or more data subjects.

It must be remembered that the obligation to be compliant with local laws arises out of the law enforcement jurisdiction while the perceived conflict indicating the violation of GDPR compliance could arise out of a contractual commitment. In order to safeguard the company both ways, it is necessary to incorporate suitable provisions in all data processing agreements that demands from the local law enforcement agencies resulting in disclosure of personal data shall be permitted disclosures under the contract.

The organization shall however ensure that the principle of “Data Minimization” meaning only the data required and justified by the investigating agency shall be disclosed with an undertaking from the recipient that it shall be used only for the purpose for which it is requested and secured while in the custody of the recipient as required under law.

While disclosures under Section 69/69A/69B of ITA 2000 are reasonably protected through a process, the CrPc provisions exercised by the local police often donot have similar safeguards.

There is a need for the police to ensure that any CrPc request for data is issued in accordance with the procedure enumerated in the rules associated with Section 69/69A/69B of ITA 2000.

If the police does not include the ITA sections in the CrPc 91 notice, which is more likely, the organization , releasing the data should not forget to mention this in their data release note.

Where there is any disagreement between the law enforcement and the Police such as when the Police want a “Roving investigation”, the only remedy available for the organization is to get a Court order restraining the “Roving Investigation” but providing all the investigation that may be otherwise required for a specific investigation for which a valid authority is available with an investigating officer.

Any information released by an organization in such cases to Indian police authorities shall be accompanied by an appropriate Section 65B (IEA) certificate. Further, the data as well as the relevant associated data (even if not disclosed immediately) should be archived and held as “Data Related to Evidence and Potential Evidence”.

Naavi

(This is in continuation of the previous article)

The PDPSI works on three different levels. The core of PDPSI is the standards. The operating part is the implementation  specifications and the visible part is the DTS.

The PDPSI Certifying body will evaluate on the basis of adherence to the standards. The implementing organization will use implementation specifications to meet the standards. The evaluating auditor will convert his evaluation into a DTS which will be disclosed.

All the three aspects namely the Standards, the implementation specifications and the DTS are inter related.

The 11 standards of PDPSI are as follows:

The requirements of each of the standards are self explanatory.

By the very nature of “Standards” these are mandatory for the purpose of certification. However the exact manner in which the standards are implemented my differ from organization to organization.

The Implementation specifications associated with PDPSI provide one suggested set of guidelines. It is open to the organization to accept them as they are or modify them.

However the modification has to be logically supported by a documentation which will create the “Implementation Charter” which becomes the operating instructions of the top management to the operational team.

The responsibility for the Charter lies with the top management which alone can decide on the risk appetite of the organization and decide what implementation specifications may be skipped and why.

A measurable mechanism is included in the standard and the DTS is a mechanism for the purpose.

The implementation is always at the enterprise level and PDPSI. It is open to the organization to create an “Enterprise within an Enterprise” to have focussed implementation in a smaller part of the organization provided it can be suitably segregated into a n independent operating zone with its own people, technology and infrastructure.

The Classification concepts are explained in the earlier articles .

The “Distributed Responsibility” concept envisages that the responsibility for implementation within the organization would not stop at the DPO but extend to every member of the workforce.

The technical controls and policy controls refer to the IT controls and policy formulations adopted by the organization. The “Culture” aspect takes care of the need to ensure that compliance is accepted by all the members of the organization and not restricted to the IS or Data Protection department alone.

The PDPSI certification program will be administered in such a manner that there is a proper documentation of the audit. The standard implementation organizations like the FDPPI may use a system of accreditation of the auditors, reporting of the audit findings, verification of audits etc to ensure that the system is reliable.

Naavi

(Continued from the previous article)

At present, PDPSI is built on 11 standards. We shall analyze what are the 11 standards that comprise of the PDPSI and the implementation specifications associated with it and how they relate to the “Certification” process.

PDPSI has adopted the HIPAA model of “Standards” and “Implementation Specifications”.

By including implementation specifications in a statutory law, HIPAA made 7 standards without implementation specifications  and 23 Required implementation specifications as part of the legal prescription. At the same time it left 22 implementation specifications as “Addressable” meaning that the management of a covered entity can take a view on whether thee 22 implementation specifications need to be implemented and if so whether they can be implemented in a manner different from what is suggested in the law.

In other words, HIPAA prescribes 30 statutory prescriptions on how to safeguard the protected health information by the covered entities and 22 other guidance indications that are optional with the condition that if they are replaced with alternatives, sufficient justification has to be provided through documentation.

PDPSI is currently designed on 11 standards and 45 implementation specifications. But under PDPSI, the standards and implementation specifications are used differently from HIPAA. The PDPSI standards are defined for the conduct of PDPSI audit by a lead PDPSI auditor.

However the implementing company is provided with 45 guidance indications which can be used by the Data Fiduciaries and Data Processors. The documentation of whether these 45 implementation specifications are used in toto or some of them replaced with other controls and if so the reasons thereof, is addressed through one of the  documents namely the “Implementation Charter” which is one of the 11 standards recommended. The PDPSI auditor will evaluate the implementation of the 11 standards reflected in the 45 implementation specifications along with the logic presented in the Implementation charter on why one or more of the suggested specifications are ignored or replaced.

The PDPSI auditor’s responsibility is in verifying the implementation of the standards and the implementation specifications adopted in the Implementation Charter and provides his certificate on whether the implementation system is set to work reasonably. The implementation specification includes what may be called “Controls” in other systems .

While the Standards and the Implementation specifications are created by the PDPSI agency (except to the extent the implementation specifications are modified through the implementation charter), the controls are created by the organization themselves.

A few of the key implementation specifications are explained in the PDPSI specification itself to the next level where they become “Control Descriptions”. But most of the other specifications are left without the subordinate “Control Level Description” because it is felt that the industry already has many best practice alternatives for these specifications. The “Control Descriptions” which are provided as part of the PDPSI documentation are those which may not be commonly used by the industry.

To this extent the “Implementation specification with control description” is similar to the “15 Standards with implementation specifications” in HIPAA and the “Implementation specification without Control Specification” is similar to the 7 standards without implementation specifications in HIPAA”.

The structure of PDPSI will therefore look like the following.

Naavi

…. To Be continued

The National Digital Health Mission (NDHM) has issued the Health Data management policy which has been introduced over the previous series of articles. As per the document on the NDHM website, the Health Data Management Policy (HDMP) is the first step in realizing the NDHM’s guiding principle of “Security By Design” for the “protection of the data principal’s personal digital heath data privacy”. This acts as the minimum standard for data protection that should be followed across the board in order to ensure compliance of relevant and applicable laws, rules and regulations.

Participation of an individual or a medical practitioner or a health facility in the scheme is voluntary and the participants when they opt in would be issued a “Health ID” or “Digi-Doctor ID” or a Health Facility ID”. These IDs will be unique as long as the participants are within the system and if they opt out, they will be deactivated and in the case of the individuals may be deleted and erased on request.

 In order that the policy is complied with, it would be necessary for organizations to be compliant with the provisions of the policy along with the applicable laws. Presently, the applicable law is Information Technology Act 2000 as amended in 2008 which under Section 43A addresses the requirements of securing “Health Data”. However, the PDPB 2019 represents the “Due Diligence” and is recognized in the policy itself.

In order to enable organizations to  adopt to the compliance requirements, Naavi suggests the use of the “PDPSI” system which is being developed  in the context of  PDPA of India or PDPAI (Proposed). As we await the PDPB 2019 to become a law, we can apply the PDPSI to the NDHM policy implementation as is briefly explained here.

PDPSI stands for “Personal Data Protection Standard of India” and is meant to assist SME/MSME s to adopt PDPA (proposed) as also to develop a Certifiable standard along with an assessment system for Data Trust Score (DTS) evaluation.

After the undersigned presented the concept of PDPSI and DTS about 2 years back, the two systems have been widely discussed with the professionals associated with the FDPPI movement. (See www.fdppi.in for more information on FDPPI). As a result of these deliberations, the PDPSI has evolved along with the DTS system and these systems would be explained in a series of articles here.

The PDPSI Ecosystem

To start with, we need to recognize that the PDPSI is a complete ecosystem that supports the Organizations that require PDPAI (proposed) to be implemented in their organizations.

PDPSI is developed as a “Unified System” for compliance of multiple Data Protection regimes and is applicable not only for compliance of PDPA of India but also for GDPR or DIFC DPL, Singapore PDPA, CCPA or Brazil LGPD or any other data protection regulation.

Hence PDPSI is also ready as a compliance eco system for the NDHM-HDMP.

The PDPSI Eco system consists of Standards, Implementation Specifications and a DTS system.

The PDPSI serves the requirement of different types of users. The Standards are meant to be used by accredited auditors to Certify an organization. The Implementation Specifications are meant to be used by the implementers as a guideline for compliance. On the other hand, The DTS is meant to be used by Data Auditors who after their audit present their assessment in the form of a DTS.

PDPSI is meant to be used as a unified platform for multiple Data Protection Compliance. The DTS however has to be computed differently for different compliance requirements and therefore, DTS-In will be different from DTS-GDPR for the same organization.

We shall explore the concept of PDPSI further in the follow up articles.

Naavi

(This is a continuation of the previous Article)

The Health Data Protection policy announced by NHD scheme has adopted the Obligations of data fiduciaries and rights of data principles from the Personal Data Protection Bill 2019.

Accordingly the obligations include

1.Accountability,

2.Transparency,  (Including Data Trust Score, Grievance Redressal, Periodical update of changes in the  processing)

3. Privacy by Design . (The system is envisaged to have a decentralized storage of data which could mean multiple data bases at State/UT level introducing the security requirements commensurate with the associated risks. )

4. Choice and Consent driven sharing

5. Purpose limitation

6.Collection, Use and Storage limitation

7. Empowerment of the rights guaranteed

8. Maintenance of Data Quality

9. Reasonable Security Practices and Procedures

As could be expected, the Ministry of Health which is in love with ISO standards has stated that “The data fiduciaries will implement the International Standard IS/ISO/IEC 27001 on “Information Technology – Security Techniques – Information Security Management System – Requirements” as well as any other standard as may be applicable to them”

Naavi.org has extensively discussed the desirability of the regulations not to suggest a particular proprietary standard to be implemented.

To reiterate, this means that every Data Fiduciary is being forced by the regulation to buy an ISO 27001 certificate which has a payment tag.

It is impossible to avoid a perception that this is being suggested for reasons other than the necessity and it is suggested that the Ministry drops this provision.

It must be also pointed out that ISO 27001 does not support the DTS system and is not comprehensive enough for the compliance of the Techno Legal requirement.

The policy suggests a NDHM-CISO and NDHM-DPO to be appointed by the organizations.

Obligations of Data Processors are similar to PDPB 2019 as entities bound by contractual agreements.

The Data Fiduciary needs to conduct a Data Protection Impact Assessment and maintain appropriate records. They should also conduct periodical review audits.

Sharing of Data

Sharing of de-identified and anonymized data may be permitted while sharing within the community of Health Information Users who will have obligations similar to the Data Fiduciary.

Grievance Redressal

The policy envisages that the Data Fiduciaries shall have a Grievance Rederssal mechanism and the DPO will be accountable to redress the grievances.

Data Breach Management

The National health Authority (NHA) is expected to notify the time limits related to the notification of data breaches. The NHA will report the breaches to the Cert-In for the time being.

NDHM Sandbox Environment

It is interesting to note that the Ministry is providing a sand box arrangement for software systems to be tested in a controlled environment. The Sandbox hosts APIs for Health ID service, Consent Manager gateway etc.

Penalties

Any non compliance of the regulations may attract cancellation of the registration and stoppage of contracts.

Summary

While the policy is an attempt to implement the provisions of the PDPB 2019 to the health sector, once the PDPA comes into being, it would be better if this policy is simplified to avoid overlapping with the PDPA provisions.

Further the references to the ISO audit as if it is mandatory must be removed and the security inconsistencies need to be addressed.

We keep our fingers crossed to see how the Ministry would respond.

Naavi

All Articles in the series:

1.National Digital health mission shows the way… Be Ready before PDPA becomes effective

2.NDHM is a trend setter… Get started early on the Privacy Protection journey

3.Consent Management under NDHM

4. NDHM-Health Management policy Objective need not be linked to ISO standard

5.Managing IDs in NHD ecosystem

6. Data Fiduciaries under NDHM

(This is a continuation of the earlier article)

Presently most of the Government’s schemes use the Aadhaar ID as the identity determinant of the citizens. It is the attempt to link Aadhaar ID to property registrations to prevent benami properties which triggered the big Privacy movement in India which lead to the Puttaswamy judgement. At the same time, Aadhaar IDs have been subjected to many security breach incidents to the extent that the dark web may be having the Aadhaar information of a very large number of Indian citizens. Also when the Aadhaar ID were first issued, the security systems were so weak that many fake Aadhaar IDs have been issued because the enrollment was done by agents. There have been instances of enrollment laptops being stolen and probably every enrolling agent kept a copy of his work. As a result Aadhaar information is no longer the secret it is supposed to be. If any privacy leak is possible through a linkage to Aadhaar ID, perhaps it has already occurred.

The Government is therefore under a dilemma on whether they should use the same Aadhaar ID as the identity of the individuals in the NHD system. Under HIPAA US government used the social security number for individuals and tax registration numbers for covered entities to create the HIPAA data base. But NHD has decided to issue new IDs to the stakeholders in the NHD ecosystem.

Accordingly, several unique IDs are being suggested to be created to identify the users of the NHD ecosystem.

The IDs are

1. Health ID to every individual user of the system. All consents would be linked to this Health ID. It is stated that the participation in the system is voluntary so that Health ID will only be unique as long as the individual is using the system and may be cancelled at his option. As a result the person may seek re-allocation of the ID if he opts in at a later time. Aadhaar number may be used for registration but the allocation of Health ID is not excluded for persons not having Aadhaar ID. As a result this data base will be independent of the Aadhaar data base. The ID will be issued by the Data Fiduciary who is registered with the NHA similar to the agents of UIDAI who issued the original Aadhaar IDs and could be a point of security weakness in the days to come.
2. Health Practitioner ID to every doctor to permit him to work under the system. This will also provide an opportunity to opt out . Authorized registrars would be appointed for the purpose of registration.
3. Health Facility ID to every health care facility which could be hospitals, pharmacies, diagnostic centers etc. The procedure for registering the health facility ID would be provided in due course.

Some of the states are also creating “Family IDs” and it may be linked to the Health IDs under this project. These two IDs will soon be added to the Aadhaar ID and PAN card for the individuals besides the Voter ID, Senior Citizen ID etc creating a host of Government IDs which an individual need to maintain.

The registration, de-registration as well as re-registration  will result in submission of personal information, need to delete the same and re-enter the same, maintaining the accuracy of the information, avoiding fake information being uploaded are issues that need to be addressed.

In the scheme now envisaged there is scope for fraudulent double registrations particularly if Aadhaar is not linked to the Health IDs. I hope this would be properly addressed during implementation.

(To Be continued..)

Naavi

All Articles in the series:

1.National Digital health mission shows the way… Be Ready before PDPA becomes effective

2.NDHM is a trend setter… Get started early on the Privacy Protection journey

3.Consent Management under NDHM

4. NDHM-Health Management policy Objective need not be linked to ISO standard

5.Managing IDs in NHD ecosystem

6. Data Fiduciaries under NDHM