GDPR requires organizations to ensure that user data is well protected, not abused, to obtain informed consent, and violations are subject to substantial fines.

The EU’s General Data Protection Regulation (GDPR) came into force on 25 May 2018. Until now, however, many people have no idea about GDPR, let alone a clear understanding of its impact on organizations or individuals. So what is GDPR and who does it apply to? What are the consequences if you break its rules?

You can read the official rules and try to understand what they mean, but it’s all pretty magical because it’s full of little nuggets like this:

“A group of enterprises shall comprise a controlling enterprise and its controlled enterprises, among which the controlling enterprise shall be the enterprise which can have a major influence on other enterprises” (GDPR article 37)

… I don’t think you can do anything about these big concepts!

So I think it helps to break it down, at least from a software perspective, and look at the key issues you need to know. If you find that it affects you, then you will definitely go deeper. GDPR will eventually touch many parts of your organization, and you want to get it right.

GDPR requires organizations to ensure that user data is well protected, not abused, to obtain informed consent, and violations are subject to substantial fines. Read on for more information.

What is GDPR?

GDPR is designed to protect citizens’ data. This means protecting access to data, not storing unwanted data, encrypting personal data, and anonymizing data when possible. In other words, all steps can be taken to limit the possibility of a data breach and the impact if one occurs. In addition, privacy includes unauthorized use of data, such as tracking users without their consent, and any other use of data without express consent.

GDPR from its website itself “aims to harmonize data privacy laws across Europe to protect and empower data privacy for all EU citizens and reshape the way organizations across the region approach data privacy.”

The GDPR also takes into account the EU’s universal “right to be forgotten,” meaning that in this case, if someone wishes to remove their data from the system, it must be done within a reasonable time. In addition, reporting requirements are strict.

Let’s take a look at the following five major issues.

1. Who needs to comply with GDPR regulations?

Of course, companies in the EU are required to follow the GDPR, but it turns out that even if you’re located elsewhere, if you have customers in the EU, then you’re also required to follow the GDPR.

If you don’t store any personal information, you’re not bound, but anyone with EU personal data must comply with the guidelines. The same is true if you have employees in the EU.

If you share user data or get user data from somewhere else, it can sometimes be tricky. If someone exercises the right to be forgotten, you have to chase all those shares and erase the data here and there. So even if you get data from other people who are handing over personal data in the EU, you are subject to the guidelines.

2. Consent and transparency

The GDPR notes that users must consent to any data being collected about them, and that consent is based on “clear affirmative action.” Explicit and affirmative means that the user must perform an action to opt in, rather than the usual “opt out, you’re in” approach.

“In order to obtain informed consent, the data subject should at least know the identity of the controller and the processing purpose for which the personal data is intended to be used.” (Article 42 of GDPR)

On the web, a good example is a signup form that informs you that data will be collected, what data it is, how it will be used, how to opt out (or be forgotten) later, and then the user must do something to agree, such as clicking a check box. The date of the pre-selected box no longer applies — GDPR specifically prohibits this type of currently typical method:

“Therefore, default, pre-box or abstention does not constitute consent.” (GDPR Article 32).

The use of data must have some purpose related to the reason for which it was collected and must be explained to the user:

“Natural persons should be transparent about the collection, use, consultation or other processing of personal data relating to them and the extent to which such personal data will or will be processed” (GDPR section 39)

3. Control personal data

Eu citizens are granted full control over their personal data, including the right to access, transfer, correct and be forgotten, including “requesting and obtaining free of charge, in particular mechanisms for obtaining, correcting and erasing or deleting personal data and exercising the right of objection.” (Article 59 of GDPR)

The right to data access is based on section 63 of the GDPR, “A data subject shall have access to personal data,” while the right to data correction is based on Section 65 of the GDPR, “a data subject shall have the right to make corrections regarding his or her personal data.” The next time you compete with a credit reporting agency, think about it and want to apply it to your own data.

GDPR further ensures that no vendor locks user data. It also lists the rights to transmit data:

“The data subject should also be allowed to receive the personal data about him or her that he or she provides to a controller and transmit it to another controller in a structured, common, machine-readable and interoperable format.” (Article 68 of GDPR)

This means you can get data from a vendor in reasonable digital form so you can move it to another provider.

The right to be forgotten extends to organizations with which data is shared:

“The right to delete shall also be extended in such a way that the controller who has disclosed personal data shall be obliged to inform the controller who is processing such personal data in order to eliminate any link or copying or duplication with such personal data.” (Section 66 of GDPR)

In other words, erasure must cascade.

If you obtain data about a person from another organisation and intend to use and/or store that data, that person must be notified — so that they can give informed consent (see GDPR sections 60,61). The same is true if you decide to use the data in a way not included in the original consent form.

“If the controller intends to process personal data for purposes other than collection purposes, the controller shall provide the data subject with information for that purpose and other necessary information prior to further processing.” (Section 61 of GDPR)

And watch out for automatic algorithms such as loan applications:

“The data subject shall have the right not to be subject to any decision, which may include a measure to assess aspects of the individual relating to him or her, which is based entirely on automated processing and which would have a significant impact on his or her legal validity or similar. He or she, for example, automatically rejects online credit applications or e-recruitment practices without any human intervention “(GDPR section 71)

If you’re using automatic algorithms to make decisions, this can give you the chills.

4. Data protection – Management and defense

Once you have someone’s data, you need to manage and protect it appropriately. The real key is something called “personally identifiable information” (PII). PII has very broad definitions, such as Cookie IE, which can directly or indirectly identify individuals including IP addresses. If you are going to do any kind of network analysis, you are collecting PII and need to make sure that what you are doing is compliant with the GDPR.

One of the key aspects of dealing with PII in GDPR is the concept of design security. The regulation states that:

“Controllers should adopt internal policies and implement measures that are in particular consistent with the principles of protecting data by design and by default.” (Article 78 of GDPR)

Designing a security approach is a way of saying that you can’t simply test security and data protection in your application. You need to design your application to be secure first, rather than building some code and trying to red-team it, so things like encryption are things that are turned off by default only in approved exceptions. Ensuring security by design also means taking static code analysis seriously, with an emphasis on software engineering standards and rules for “preventive” static analysis.

Also, if you are collecting health-related data, extra care needs to be taken to ensure it is safe (see GDPR section 53), although certain types of research are regulations about health rather than marketing opportunities (see GDPR Section 54).

Data retention is another important issue when collecting and storing PIIS. The main principle here is to retain data that is no longer needed:

“… To have the right to delete personal data whose personal data is no longer needed “(GDPR Article 65).

In other words, data that is used only for temporary purposes (such as completing a transaction) should exist only for the amount of time required. After that, you should erase the data, not store it for convenience or future analysis.

It’s important to show that you actually need to collect data as well:

“Within the time and scope of collection of personal data, the data subject can reasonably expect that processing for that purpose is likely” (Section 47 of GDPR)

After that, you cannot use the data only for other purposes, unless the other content is related to the original use of the data and/or processing (analysis) of the data.

“Processing of personal data for purposes other than those for which it was originally collected should be permitted only if the processing is compatible with the purpose for which it was originally collected.” (Article 50 of GDPR)

5. What should I do if I violate?

Violations will result in fines. The EU can impose daily fines for persistent violations. Fines can be based on the income of the parent organization, so they may be larger than you think. Fines vary depending on the violation and can be as high as 20 million euros. Make sure you can prove compliance.

“In order to demonstrate compliance with this regulation, the controller or processor shall keep records of processing activities under its responsibility.” (Section 82 of GDPR)

So what do you do?

I’d love to tell you that there’s a simple tool or set of tools you can use to simply comply with GDPR, but that’s not the case. Even so, Parasoft has a lot to offer. First, you can combine Java, C/C++ and. NET static code analysis engine is used in conjunction with good security and privacy configuration to ensure that your code is as secure as possible. You can even configure them to enforce strict encoding policies, such as encryption by default.

Second, you can use service virtualization to drive full end-to-end testing even in the early stages of the developer desktop. Being able to fully test what’s going on with the data without expensive test LABS makes compliance much easier, and by allowing developers to perform more in-depth testing, you can find problems much easier and cheaper.

conclusion

Given the potential financial penalties, this is a bit frightening, and in a sense it should be. But in general, unless your business model is based on tracking users and selling their data, it’s actually not that scary. If you have a typical business model with customer data and sales, you will find that compliance is less of a headache and can make the entire system more secure as the frequency of data breaches increases. All you need is the right strategy, comprehensive, comprehensive testing, and robust static code analysis to keep your data private.