Header image alt text


Building a Responsible Cyber Society…Since 1998

Data Portability is one of the contentious issues of the GDPR from the compliance angle. We had discussed the “Theory of Dynamic Personal Data” in one of our previous articles. That concept would be relevant to address the issue of Data Portability as envisaged in GDPR.

Article 20 of GDPR states as follows:

Article 20: Right to data portability

1. The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided, where:

(a) the processing is based on consent pursuant to point (a) of Article 6(1) or point (a) of Article 9(2) or on a contract pursuant to point (b) of Article 6(1); and
(b) the processing is carried out by automated means.

2. In exercising his or her right to data portability pursuant to paragraph 1, the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible.

3. The exercise of the right referred to in paragraph 1 of this Article shall be without prejudice to Article 17. (Ed: Right to Erasure). That right shall not apply to processing necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller.

4. The right referred to in paragraph 1 shall not adversely affect the rights and freedoms of others.

The industry is struggling to understand how it can possibly tune up its processing system so as to keep the “Personal Data of the Data Subject” in one compact identifiable package so that when necessary it can be “Ported” or “Erased”.

If a Data Processor is setting up a new system for processing the data, it would be perhaps easier to design the system to meet this objective. But if he is already processing data and is now trying to implement GDPR over the existing set up which includes past stored data and the processing system, it would be a challenge to comply with the provision.

One of the key aspects of implementing Data Portability and Data Erasure is to ensure that a data subject’s personal data is always identifiable in a package and can be dealt with together when required.

In practice however, the complete set of personal data about a data subject gets acquired over a  period of time and in bits and pieces. In this kind of “Data Aggregation”, there is one part of personal data which the data subject has handed over after an informed consent. This is a “Property” of the data subject and he has every right to deal with it as he likes.

But once this raw data is received by the data processor, it may be mixed with other data, analyzed, filtered, processed using intelligent data mining and analytical algorithms and another set of data which has a link to the raw data supplied by the data subject emerges. In course of time, the data subject also adds further data about himself which is another set of raw data that gets added.

At this point of time, the data with the data processor has two components namely raw data supplied by the data subject from time to time and the value added secondary data  in which the raw data is embedded but there is much more value because of what has happened to the raw data with the processing. It is like the data subject has given the data processor, water, fruit juice concentrate and sugar in separate packets and the data processor has created a bottle full of juice with it.

Now the data subject comes and says, please “Port” my data to another “Data Processor”. Now the problem is for the data processor to separate the water, juice concentrate and sugar from the Bottle of juice and return the “Data of the Data Subject”. Any thing else is a different data and if that has to be transferred to another data processor, it will go along with the technical know how used by the first data processor to add value to the data. Obviously this is not acceptable to the data processor since it would dilute his IPR.

The key to GDPR data portability management is to develop a data processing model which keeps a tag on the “Raw data supplied by the data subject” even when it is being churned into a value added data by the data processor, so that when required, we can pull out the raw data and return it to the data subject.

If the system is designed intelligently, the data processor may still keep the value added data with himself but return the raw data components to the data subject. It will be like having the Cake and eating it too.

In order to design such a magic system, we may have to develop a suitable system on a case to case basis. But as indicated earlier, it is easier to introduce such systems prospectively and not retrospectively.

Hence it is better if GDPR liability is accepted only for the future personal data inflow and existing system which was in place is retained for Data Protection in respect of the past data.

It does not appear that GDPR has been conceived taking this “Prospective” or “Retrospective” implementation since the authorities seem to be oblivious to the practical issues involved in implementing some of the recommendations which appear good to read but impossible to comply.

In this discussion, we have assumed that the Data Subject does not lay claim for the value added part of the processed data and would be satisfied if his own raw data is returned to him. Hence in future we may have to differentiate data as “My Data” and “Your Data” and apply different privacy and security rules for them.

The technical implementation of this concept needs development of a middle ware data processing strategy which is out of scope of this article and also involve IPR in the design.


Definition of Undertaking under GDPR and its impact

Posted by Vijayashankar Na on April 3, 2018
Posted in Cyber Law  | Tagged With: , , , , | 1 Comment

GDPR is liked by some as a good law to protect privacy of individuals and is often looked upon as an “Emerging Standard”.  Many companies are working towards calling themselves “GDPR Compliant” since it makes a good marketing sense though GDPR does not apply to them. Even the Whitepaper on Data Protection Law which the Justice Srikrishna  Committee made references to GDPR frequently giving a perception that Indian Data Protection law will be a reflection of GDPR in some way.

At the same time GDPR is hated by the IT Companies because it increases their cost of Privacy compliance and also holds the Damocles sword on their head with the obnoxious penalty clause of Administrative Fines.

In most privacy laws, the emphasis is to provide direct protection to the data subject by giving him compensation for adverse consequences of data breach. In order to reduce the possibility of privacy breach, the law also provides certain standards of compliance and to goad the companies to take compliance seriously, imposes fines and penalties for non compliance. The fine is meant to act as deterrence against neglect of “Due Diligence” requirements.

GDPR has used Administrative fines as a means of causing a “Chilling Effect” on the industry that they are at the mercy of the “Supervisory Authorities” who have been given powers to impose unreasonably large penalties.

Article 83 (4) and 83 (5) prescribe the penalties.

Under Article 83(4), certain infringements will be subject to administrative fines upto 10 million Euros (1 Euro=Rs 80) or in the case of an undertaking , upto 2% of the total worldwide annual turnover  of the preceding financial year whichever is higher. 

Under Article 83(5) certain infringements will be subject to administrative fines upto 20 million Euros (approx Rs 160 crores) or in the case of an undertaking , upto 4 % of the total worldwide annual turnover  of the preceding financial year whichever is higher. 

The lower fine is in respect of  the following articles

Article 8: Child’s Consent

Article 11: Processing which does not require identification

Article: 25 to 39: Various obligations such as privacy by default, impact assessment, data breach notification failure etc

Article 42 and 43 : Certification related

The Higher fine is in respect of the following articles

Articles 5,6,7 and 9: violation of basic principles for processing including consent

Articles 12 to 22: Infringement of Data Subject’s Rights

Articles 44 to 49: Transfer of personal data to third countries

and non compliance of member state laws and order of a supervisory authority

In the penalty clause what strikes the eye is that in case of an “Undertaking” the penalty may be 2% or 4% of the total worldwide turnover.

To understand the impact of this clause, we need to understand what constitutes an “Undertaking” under the law applicable in this context.

The meaning of “Undertaking” is defined under articles 101 and 102 Treaty On the Functioning of European Union (TFEU).

One obvious way of determining the scope of this word is to consider that where one company exercises “Control” over another company, they form a single economic entity and hence are part of the same undertaking.

This means that if a company is a holding company and the subsidiary company is the one subject to penalty, the holding company may become part of the global undertaking. If the holding company is in EU and the subsidiary companies are in one or more other countries, then all of them will become part of the “Undertaking”.  Beyond this, it would be the specific ruling that any Court may give or which the supervisory authority may imply.

If therefore, Infosys (an example only) is an Indian company and has subsidiaries in EU where it is a Data Controller and is subject to some fine, then the turnover of Infosys becomes part of the turnover of the undertaking. Now if Infosys subsidiaries in other countries also hold cross holdings in the EU entity, then some crazy EU court may add the global turnover of Infosys as the turnover of the undertaking to determine the fine.

This may mean that the revenue generated by the employees of the Company in India out of their operations here which have no relevance to EU operations will be taxed in EU.

The legality of such a measure is considered debatable.

Also, when Infosys-EU signs a Data Controller contract and creates a charge on the earnings in India which are enforceable against the EU subsidiary, the share holder’s of the Indian Company may have reasons to ask if their wealth gets eroded.

At first glance, the addition of “Global Turnover” in the computation of the penalty appears to be an over reach in law and may not sustain a proper scrutiny. But this is some thing which NASSCOM has to address and consult international law experts such as Harish Salve and clarify.

In the meantime, Indian companies having some operations through EU subsidiaries need to ensure that the “Holding Company Turnover” does not become a factor that increases the potential liability of the EU subsidiary. This can be done through shedding the “Holding Company Status” and ensuring that the EU subsidiary and the Indian parent (hitherto) company maintain an arms length relationship without any director level control or shareholder level control.

When companies who donot require to follow GDPR want to adopt GDPR as a “Standard” they should ensure through proper disclosures that “The adoption of GDPR compliance as a business strategy across all the global units of the undertaking” is not treated as a prima facie admission that there exists a global networking relationship across all such companies exposing the aggregate turnover of all such companies to the risk of being considered for fine computation.

I look forward to a response from NASSCOM on this matter.


Currently GDPR and Aadhaar are both hot subjects for discussion amongst professionals whether they are Privacy activists, Information Security professionals or Lawyers.

GDPR is at one end of the spectrum often looked upon by Privacy activists as the ultimate in Privacy Protection legislation. Aadhaar on the other hand is at the other end of the spectrum often looked upon as the greatest villain in Privacy breach in India.

The Supreme Court of India continues to hear the petition of Privacy Activists who are more concerned about the political damage they can create on the Government by attacking Aadhaar than any public good.

There appear to be some foreign technical persons calling themselves “Ethical Hackers” who are camping in India to hack into Aadhaar data and prove that Aadhaar is the epitome of Privacy invasion in India. It is not clear where motivation comes to these persons and whether they are motivated by their commitment to the Privacy of the Indian Citizen or committed to the political advantages that can accrue to Black Money owners in India if the present intentions of the Government to link Aadhaar to Mobile and Bank accounts is frustrated through intervention from the Supreme Court

We the Indians are aware that even Supreme Court is having its own agenda and many times takes decisions which are “TRP oriented”. The Privacy judgement, the Scrapping of Section 66A are examples of decisions where the Court has shown its inclination to come to conclusions based on the public perception that can be created about the “Progressive Views of the Judiciary”.

In this context it is essential for us to examine how does GDPR try to address the issues of Privacy in the context of Public interest, National Security and Journalistic freedom.

Chapter IX of GDPR  refers to “Provisions Related to Specific Data Processing Situations” and sets in the rules regarding processing of personal data in the context of Right to Freedom of Expression and other issues including “Processing of National Identification Number”.

Article 85 of GDPR  leaves it to member states to reconcile by law the right to protection of personal data pursuant to GDPR with the right to freedom of expression and information including processing for journalistic purposes and the purposes of academic, artistic and literary purposes.

Article 86 refers to personal data in official documents held by a public authority or a private body for the purpose of carrying out an activity in the public interest which may be disclosed under a Right to Information kind of law.

As one can appreciate, the canvas to define exclusion under Article 85 and 86 is fairly wide and if we take this as a guide for the Indian context where we are waiting for our own Data Protection law, there is enough scope to consider that our existing laws including the Right to Information Act can be considered as an automatic exclusion to GDPR.

Article 87 is interesting since it directly relates to a situation similar to Aadhaar. It states as under:

Article 87: Processing of the national identification number

Member States may further determine the specific conditions for the processing of a national identification number or any other identifier of general application. In that case the national identification number or any other identifier of general application shall be used only under appropriate safeguards for the rights and freedoms of the data subject pursuant to this Regulation.

This article provides complete rights to member states to over rule GDPR when it comes to processing of national Identification Number or any other identifier of general application. Obviously, “Appropriate safeguards” are prescribed.

This article provides guidelines both to Indian Companies who are often over reacting to the GDPR  by imposing on themselves non existing restrictions on to what extent the local regulations may over ride GDPR and yet it can be considered as “GDPR Compliance”.

If the member states of EU themselves have the freedom to enact laws that may over ride EU, it is obvious that an independent sovereign country like India where in most cases, the GDPR application is through the contracts between the Data Controller in EU and a Data Processor in India, the local laws such as Information Technology Act 2000/8 will have paramount priority over and above GDPR.

I therefore caution Indian Companies that in their eagerness to be GDPR compliant, they should not ignore the need to be ITA 2008 compliant.

We need to build GDPR Compliance within the parameters of ITA 2008 compliance. Fortunately, ITA 2008 is eminently designed for such requirement since Section 43A and definition of “Reasonable Security Practice” accommodates such contracts as defining the security requirements for compliance. The only difference would be that the remedy may have to be sought under ITA 2000/8 read along with international treaties and laws applicable to international contracts. GDPR cannot be super imposed in derogation of these other remedial options.

The second aspect we need to take note from Article 87 is that even the rigorous GDPR regulation on Privacy provides for an exception of National Identification Number in the EU member countries. Hence the Indian Data Protection Act can also exempt the processing of Aadhaar data from the restrictions.

The Supreme Court should therefore take cognizance of this fact and donot make the mistake that they committed in scrapping of Section  66A of ITA 2008 while ruling on Aadhaar.

Linking of Aadhaar to Bank accounts and to Mobile is a requirement of public interest to prevent Black Money, Benami transactions as well as Terrorism and Crimes and the right of the Government to use the National Identification Number such as Aadhaar for such purposes cannot be curtailed by the Court without taking on the blame that the decision is meant to please the silent majority of anti nationals who advocate that Aadhaar has to be scrapped.

The above support for Aadhaar is however not in derogation of the requirement that there has to be adequate safeguards to secure the Aadhaar usage in a manner that it cannot be misused to commit crimes. It is in this context that the “Virtual Aadhaar” becomes most important as a security measure so that at least in the future “Stored Biometric Attacks” through the Aadhaar user agencies does not occur.

My support for Aadhaar above also does not mean that Aadhaar authorities are taking all steps that are necessary for securing the infrastructure of Aadhaar and that they are not arrogant and not dismissive of the risks.

It is however considered that Aadhaar linking to Financial information and identity of individuals to several activities is essential to build a Safe India and no legal hurdle should be placed to prevent this honest effort of the Government. The security concerns are however real but can be addressed if UIDAI makes full efforts in this regard.

The first thing UIDAI needs to check is the progress of the Virtual Aadhaar implementation. The system should be in trial operation by 1st of April and in mandatory operation by 1st of July.

While some data security organizations in India are busy conducting surveys on our GDPR preparedness, UIDAI itself or other data security organizations should focus also on conducting a survey on our preparedness for implementation of Virtual Aadhaar as an identity to replace Aadhaar identity by Banks and Mobile operators.


In the context of huge regulatory fines envisaged under GDPR, there is a renewed interest in Cyber Insurance among Data Processors everywhere. Since liability under GDPR may arise not only for payment of compensation to data owners but also for making payment of fines that may be imposed by the regulatory authorities, the companies do demand that they should be covered by some Cyber Insurance policy for any liability that comes out of processing of EU citizen’s data.

As for as Indian data processors are concerned, their liability will be restricted to what is indicated in the data processing contract. Some of these contracts may be vague and not determine the exact liability or compliance responsibilities. It may make a reference to the liability that may arise on the Data Controller under GDPR and extend the liability in the form of an “Indemnity” to the associate data processor in India. Indian data processors some times assume that they would be liable directly under GDPR and rush to obtain insurance cover for large amounts. This could hurt the profitability of their operations.

If any data is compromised by an Indian data processing company then it would be as a result of a “Cyber Crime”. The cause of action lies with the persons who have lost money. Most of the time however, data compromise is recorded but the actual loss may not fructify or fructify only to a small extent not commensurate with the number of data elements lost.

Hence out of the total loss, the loss arising out of “Compliance” requirements which may include sending of notices, arranging identity theft protections for all the suspected compromised data subjects would be a huge cost even when not a single of the compromised data might result in actual loss. Similarly in such cases the regulator would impose millions of dollars fine depending on the nature of breach, the attitude shown by the data controller before and after the breach to protect the data subjects etc.

When a Cyber Insurance policy is invoked in such cases, an obvious question that would arise is whether the loss occurred more out of the negligence of the Company as a whole in implementing proper policies etc and whether the company should be protected against its own negligence. If Cyber Insurance routinely covers such breaches, then there will be no incentive for companies to improve their security.

Hence it is necessary and natural that the Cyber Insurance Company raises an objection or try to limit its liability citing that the cause of loss was “Not Insurable”.

A question has therefore arisen on “Whether Regulatory Fines are Insurable at law”. In this context, the article “GDPR Fines and Cyber Insurance”

presents some interesting thoughts as may be relevant in the Great Britain. Since India generally follows the English Law and the Insurance law has dependence on the British practices, it is presumed that the English law is also relevant for the Indian Context. Hence the points mentioned in this article are very much relevant to Indian companies both in the GDPR context as well as in other instances of fines arising out of non compliance of HIPAA, Non Compliance of ITA 2008 and even when there is a ransomware attack due to lack of proper security practices in a company.

One of the concepts discussed here is “illegality of defence” which may prevent a claimant from pursuing a civil claim based on the claimant’s own illegal acts.

The dividing line however is whether there was “Illegality” on the part of a company that caused the fine or there was merely “Negligence” in implementing the regulatory precautions.

As long as the negligence is related to “Best practice suggestions” that are made by sectoral regulatory bodies or industry practice, the cause may be contained within the concept of “negligence” unless the level of negligence is “ridiculous”. But if there is a statutory law which has been ignored then such negligence cannot be called anything other than “Illegal”.

To be more specific, if a Bank ignores RBI guideline, it may be “Negligence”. But if it ignores “ITA 2008”, then it would be “Illegal”.

Secondly what distinguishes “Negligence” from “Gross Negligence” or “Recklessness” is the precautions taken by an organization before an event occurs and also its response immediately after the occurrence of an incident.

If an organization has taken reasonable precautions which any other prudent person under similar circumstances would have undertaken but failed in some minor aspects, then the level of negligence is in the lower end. If however, there was no precaution taken or the precaution was ridiculously low, then the breach would be attributed to callous attitude and may be considered as a “Contributory Negligence” or even a “Passive Assistance” to a fraudster.

If we take the recent incident of PNB fraud and another fraud that followed at City Union Bank, it appears that the negligence at City Union Bank which allowed a compromise of its SWIFT system may fall under the category of “Negligence but Not Recklessness”. On the other hand, the PNB negligence which involved allowance of customer’s executives using the passwords of Bank officials to create their own “Sanction letters” and the sharing of passwords between multiple officers of the Bank can be called an abject complicity in the offence itself.

Even if there was no “Mensrea” at least for some of the executives of the Bank, the “Recklessness” was attributable to all employees of PNB who were aware that SWIFT messaging system was not linked to CBS and passwords were being shared.

The Association of employees in PNB has tried to put the blame on the top management. Similarly, the employees of Mehul Chokshi firm has placed their current loss of jobs to the Mehul Chokshi led Board. But if one is honest, we all know that if a fraud of this magnitude had taken place, then several persons within Mehul Chokshi or Nirav Modi companies as well as PNB, Other lending Banks, RBI, and the Ministry of Finance must have smelt that some thing wrong was going on.

What has collectively failed in the system of “Whistle Blowing” that RBI already has in place but has completely failed to work. The complaint that one franchisee Mr Hari Prasad made to PMO is like many complaints that are forwarded to PMO and are directed to appropriate departments for enquiry.

But each of the Banks had their own Whistle blowing systems and RBI  had a Whistle blowing system for the entire Banking system and it appears no body had the courage to report the possibility of such a fraud. The reason could be that the heads of each Bank involved as well as the Governor of RBI themselves were all friend of the then prevalent political system and personally appointed by Mr P.Chidambaram and hence no body trusted them to take action.

If the Whistle blowing system ensures that the whistle blower is protected, then the skeletons would have tumbled as soon as a junior Bank officer acquires a flat costing Rs 3-4 crores or throws up a fancy party in a five star hotel etc.

In all such cases therefore, the negligence is unpardonable and hence there should be no protection from Cyber Insurance.

Cyber Insurance contract being an  uberrimae fidei contract, the Insurance company is unlikely to discuss these issues with the clients at the time the Insurance policy is bought. But if the liability is huge and the client invokes the insurance, then the legal departments in these insurance companies may certainly raise the “Illegal Defence” clause.

The principle in Insurance is always, “Take as much precautions as you would take as if there was no insurance” and there after, if the loss materializes, it is an “Accident” for which the Insurer should gladly assume liability. If one takes decisions recklessly because there is an insurance to back up, then the insurer would definitely feel cheated and raise objections at the first instance.


Corporate Governance and GDPR risk

Posted by Vijayashankar Na on January 30, 2018
Posted in Cyber Law  | Tagged With: , , , | No Comments yet, please leave one

As the D-day  for GDPR (25th May 2018) approaches, many of the Indian companies are busy with their preparation for implementing GDPR in their processing activities. At the same time, there is also a question in the minds of most of the Indian companies about how the GDPR provisions would be made applicable to them by the respective EU authorities and whether the EU authorities are likely to pass any orders against the Indian company any time  in the future and impose liabilities.

GDPR essentially is a Data Protection law and has a penalty clause that if there is non compliance there could be a penalty which we all know is huge. But being a law of the EU it does not have direct enforcement jurisdiction on Indian Companies.

Article 3 of GDPR has created extra territorial jurisdiction as follows.

GDPR is applicable  “regardless of whether the processing takes place in the Union or Not” 

1. Provided the “processing activity” is related to the offering of goods or services to data subjects in the Union

2.Provided the “processing activity” is related to the monitoring of their behaviour as far as the behaviour takes place within the Union

This is similar to the ITA 2000/8 which also has an extra territorial jurisdiction (Section 75 of ITA 2000/8) and many other Cyber crime laws across the world. This provision provides a legal long arm jurisdiction but it is not feasible for EU authorities to extend enforcement jurisdiction or conduct direct audits of Indian Companies unless the Indian entity is a part of a EU Company.

However, the EU based Data Controllers will in their contracts with the Indian Data Processors have “implementation of Privacy and Security provisions as per GDPR” as a necessary condition and also have an “Indemnity Clause” to make the Indian company liable for “Any loss that may arise due to any act attributable to the Indian Company that may result in either a penalty imposed by GDPR or any other Judicial authorities”.

Hence more than the direct impact of the GDPR on Indian processors, it is the contractual liabilities that the Data Controller imposes on the Data Processor that will determine the liability of the Indian processor .

If there is a possibility of any liability arising on the Indian Company, there is a need for the Board of Directors to make an assessment and disclose the risks that may arise in the next Financial year 2018-2019.

GDPR also mandates a Data Protection Impact Assessment (DPIA) which is an obligation of the Data Controller. If there has been a DPIA conducted by the Data Controller, the Data Processor will be presumed to be aware of the DPIA. Hence the management needs to take note of the DPIA results and admit knowledge of the risk associated with the processing.

From the point of view of an Indian Data Processing company therefore, the moment they accept a contract which has a GDPR stake, then the liability risk attached to it needs to be assessed and value assigned. The Company also needs to undertake Risk mitigation measures determine how much of risk has to be absorbed after mitigation, avoidance and insurance.

So far, Indian companies have never made an assessment of financial risks that may arise on account of legal risks.  If this was so, Companies would have estimated the risks even for non compliance of ITA 20008 and made adequate disclosures and provisions. In the case of GDPR however, the risks are high and is documented through the DPAI process. Hence  the potential liability cannot be swept under the carpet.

Whether the Absorbed risk is small or even zero, it would be obligatory from the point of view of Corporate Governance that Indian companies disclose their “GDPR Risk Liability” in their share holder disclosures from the immediate next financial year.

We need to wait and see whether these companies will be compliant to this requirement or not.


[P.S: This is in continuation of the discussion of the proposed Data Protection Act in India and the public comments invited for the  Justice Srikrishna report.]

“Privacy by Design” is a concept which GDPR expects from Data Controllers and Data Processors.  The concept of Privacy by design basically means that measures for Privacy protection should be initiated right from the inception of a project and during the engineering process. It is not an after thought considered over the layer of processing but should be embedded into the basic framework of processing.

The concept of Privacy by design imposes a sense of responsibility on software manufactures who have a tendency to design software solely for functional purpose and expect Privacy to be taken care of manually at the time of implementation.

This concept needs to be extended to complete compliance of all provisions of the Data Protection Act which can be controlled by technical means by making “Compliance By Design” as a mandatory provision under law so that the responsibility for compliance is shared by both the software developers and the users. This could mean that systems and outsourced services should have mandatory encryption, mandatory authentication in the form of non repudiable digital signature system, mandatory compliance of data retention, mandatory archival of log records etc.

If such “Compliance by design” is mandated, then the quality of software products from the point of view of “Data Security” would increase and in the event of any “Data Breach” caused by vulnerabilities in the software systems, some responsibility may be imposed on the software companies also. This would help SMEs in particular who donot have greater dependency on the software suppliers, who donot agree for source code audit or for source code escrowing and also donot guarantee that their software is free from bugs.

Larger companies may have better ability to take their own measures to secure the systems irrespective of the vulnerabilities they come with. They also have the power to extract maintenance contracts and source code audits better than the SMEs and hence the proposal for Compliance by design should help SMEs more than large entities provided the definition of “By design” is extended to software development.

The new data protection act can consider imposition of “Compliance By Design” as one of the responsibilities of system developers (both hardware and software). In order to incorporate this provision, a separate chapter that defines the compliance requirements of the Data Controllers, Data Processors and Data Managers (as proposed in our previous article) along with how the fact of compliance should be disclosed to the public and to the Data Protection Authority. This should obviously be controlled through Registration and penal de-registration of entities who are Data Controllers/Processors/Managers.

Hopefully Compliance requirements donot simply remain on paper but are followed up for strict implementation.

In order to ensure that Compliance is taken seriously, Cyber Insurance should also be made mandatory so that the Cost of Insurance should incentivise the business entities to invest the right resources in achieving compliance.

The SKC has asked the feed back on whether the law should be made retrospective or prospective. If “Compliance” is an honest expectation, it goes without saying that the law has to be enforced prospectively with reasonable time given for compliance.

In the meantime the regulatory authorities need to even provide guidance and assistance to the Data processors and Controllers in the SME sector so that they can achieve compliance in the specified time. The compliance schedule also need to be extended with an additional time for smaller entities taking into account the incidence of cost as well as scarcity of manpower to assist them in the compliance.

The compliance dead line could therefore be about 1 year for large units and about 2 years for smaller units, with exact definition of what is Small and what is not being decided on the basis of turnover.