Micro Focus is now part of OpenText. Learn more >

You are here

You are here

3 ways your software team can get GDPR-compliant

public://pictures/Robert-Lemos-Technology-Journalist-Lemos-Associates.jpg
Rob Lemos Writer and analyst
 

The deadline for the European Union's General Data Protection Regulation (GDPR) has come and gone, yet most companies still aren't in compliance with its privacy rules.

Estimates vary as to just how well companies are succeeding in their efforts. Just 15% of companies in the European, Middle Eastern, and African markets were expected to be fully compliant with the regulations by the deadline, according to a survey conducted by Deloitte. Among global organizations, 7% were fully compliant in April, but nearly 40% expected to be compliant by the deadline, according to Crowd Research Partners.

Developers are a key partner in helping companies adhere to the GDPR's stronger privacy regulations, but businesses often put other considerations before security and privacy, said Stan Engelbrecht, director of cybersecurity practice at D3 Security.

Developing secure code is something that should have been going on for the past 20-plus years, and even that gets overlooked by companies, Engelbrecht said.

"Coding securely is difficult and takes time and takes effort, and developers are on deadline, so security and thinking about issues such as GDPR are not necessarily the first thought."
Stan Engelbrecht

Making data privacy a priority is no longer an option. Here are three key ways developers can get GDPR-compliant right away.

1. Take care when removing interlinked data

The increasing distributed nature of databases can cause problems for GDPR compliance. When a former customer asks to be removed from your systems, finding every record related to the person may not be easy, and making sure that deleting one record does not undermine the integrity of the database may be difficult.

D3 Security, for example, has seen clients remove the primary key—such as an associate ID or an employee number—from a database, only to break functionality elsewhere.

"From the software development side, that has been a difficult piece to deal with. You have to be very careful, because removing a primary key can cause a lot of problems."
—Stan Engelbrecht

Developers should take care to design and test the functions or methods that perform record deletions in a GDPR-compliant way, he said. A more difficult question, however, is how a company can prove that it has deleted the requested data.

2. Use fine-grained controls for developers

Many development environments allow coders access to all data and every resource. That violates GDPR's requirement that business processes and software have a privacy-forward design, especially in the final application.

GDPR and modern web application development don't go together, said Ron Gula, president and co-founder of Gula Tech Adventures, a cyber investment firm.

"A poorly designed application gives equal access to data and code such that your developers and admins all have access to customer data and makes them subject to GDPR."
Ron Gula

Instead, developers should be restricted to much finer access controls and privileges, allowing development to continue to be agile, while access to sensitive data is limited, he said.

3. Beware identifying combinations

Businesses often reveal a subset of their data after anonymizing it—taking out names, addresses, and other personal information. But under GDPR, other data—such as a person's Internet addresses—is also considered to be identifying. Even companies that do not store such information could run the risk of having personal information lost, because creating truly anonymous datasets when you have large amounts of data is truly difficult.

In 2008, for example, researchers at the University of Texas at Austin found that, given a set of movie ratings publicly posted on the IMdb movie database, they could identify the reviewers in a much larger—and purportedly anonymized—database published by Netflix for research purposes. A variety of other examples of de-anonymization exists as well, such as medical records and America Online searches.

"Developers need to look at any anonymized data [with an attacker's eye]," said D3 Security's Engelbrecht.

"You cannot have combinations of data that allow you to build a full picture. So you have to ask: What can be seen when you go into the system? Can I pull out enough pieces to build a full profile, and if that is the case, how do I stop that?"
—Stan Engelbrecht

Data gathering: Less is more

The requirements of GDPR run counter to the prevailing direction of programmers in the industry which is to collect and store ever greater amounts of data.

"It creates a serious conflict with business models," said Dan Cornell, chief technology officer and co-founder of software-security consultancy Denim Group.

"The raw market forces are saying, 'Collect more data, so we can do cooler stuff,' but GDPR is diametrically opposed—counter to where those industry and market forces are going to go."
Dan Cornell

The impact of GDPR on data collection can be seen in early email notification efforts. Companies must now allow consumers to opt into email marketing lists, and that led to a massive notification effort in May. When contacted by companies about opting in, about half of consumers elected not to keep the email subscription.

Under GDPR, every choice to retain data must be justified, if there is a potential for an EU citizen to be affected. To be safe, 70% of companies are getting rid of data that is not core to their business, according to one survey.

Take a pro-privacy approach to everything

The steps above are just the start of a more privacy-forward approach to software development. Applications should not collect data without a specific purpose and should be clear on what data is being collected and for what reason.

With a pro-privacy approach, including active and informed consent, developers should not have issues complying with GDPR.

Keep learning

Read more articles about: SecurityInformation Security