Our GDPR compliance checklist explains seven steps you can take to improve your software security initiative and illustrate GDPR software security compliance.
By now, you’re probably aware that the General Data Protection Regulation (GDPR) is coming. Taking effect on May 25, 2018, GDPR aims to unify the European Union (EU) on common data protection practices. Bringing more control and higher standards, this regulation will affect how firms gather, store, and use data pertaining to EU residents.
Let’s examine seven steps your firm can take to continuously improve its software security initiative, thus illustrating GDPR software security compliance.
Regardless of your organization’s location, whether it operates primarily inside or outside the EU, if it uses data relating to EU residents, then GDPR applies to you. Transactions can include any operations carried out with employees, other organizations, and customers—even those receiving a free service.
Article 35, “Data protection impact assessment,” stipulates that prior to data processing, an assessment of the measures envisaged to address the risks, including security measures and mechanisms, must be performed.
To comply with Article 35, organizations processing personal EU data should do the following:
Organizations are obligated to demonstrate GDPR compliance. But how? That’s the question firms are asking.
Some key obligations
As with previous data laws, GDPR makes clear distinctions between data controllers (i.e., data owners) and data processors. Each holds a different role. Before creating an action plan to propose to senior leadership, you’ll need to figure out whether your organization is a data controller, a data processor, or both.
Is my organization a data controller?
Controllers are responsible for, and must comply with, these principles regarding personal data:
For control issues—that is, what is done with the data (e.g., where it is sent, what kind of processing is done on it)—the buck stops with the controller. Controllers must also be sure data is processed with the correct security controls, whether by their own organizations or by a third-party data processor.
Is my organization a data processor?
Processors must have appropriate technical security measures in place. For example, an ISO 27001 implementation would be a good start. Additionally, as we know, secure software, networks, and environments are essential. The best way to create a culture of software security in an organization is to implement a software security initiative.
Sponsorship and support from your organization’s top decision-makers influence real change. Since GDPR will be enforced globally and is accompanied by sizeable monetary penalties for noncompliance, getting buy-in from senior management is critical. Outlining the potential penalty fines, in addition to proposing an actionable strategy to meet the obligations facing your firm, will aid you in obtaining trust and commitment to a program.
Data protection impact assessments (DPIAs) can be an integral part of carrying out privacy by design. However, in some cases, GDPR mandates that a DPIA be carried out, depending on the sensitivity of your data. You may be thinking, “What is this DPIA you speak of?” Fret not. A DPIA is also known as a privacy impact assessment (PIA). In other words, it’s something that organizations have been using for years as an effective way to comply with other data regulations.
If your firm is a public authority performing large-scale systematic monitoring of individuals (e.g., online behavior tracking) or running large-scale processing of special categories of data, then you need a data protection officer (DPO). The DPO’s role is to inform and advise, monitor compliance, manage internal data protection activities, and be the first point of contact in a breach.
The DPO reports to the board, cannot be penalized for performing their duties, and must have adequate resources for their role. They do not have to be an employee and can be external; in fact, DPO-as-a-service is now a thing.
One focus of the DPO involves securing any piece of software that plays a role in processing personal data. They must also ensure that the organization continuously monitors for new vulnerabilities affecting production applications, per Article 32.
Security must be built into the software and systems that personal data passes through, from the start, with documented standards and practices to minimize the attack surface. Article 25 specifically calls for measures to ensure that personal data is not made accessible without the individual’s consent (including during a breach).
Ultimately, architectural flaws are by their very nature the most impactful security and privacy challenges that can be discovered. Thankfully, finding them before a system is implemented prevents costly rework.
Still, there are limits to finding design flaws before they’ve affected implementation. This can happen only during greenfield development (starting from absolute scratch with all-new code) and during the development of new functionality in an existing system.
The more common scenario is that a flaw is discovered in an existing (implemented and fielded) system component owing to ongoing architecture risk analysis (ARA). In these cases, it’s doubly important to consider your options for flaw mitigation. Often a stop-gap solution can be placed in a deployed system, while architects work to establish more permanent shifts in design to alleviate the risk more fully.
Keep in mind that GDPR isn’t optional. The penalties can potentially devastate an organization. Article 83 sets out a tiered approach to penalties, with a maximum fine for violating GDPR of up to 4% of annual global turnover or €20 million (approximately $24 million), whichever is greater. It’s also important to note that GDPR guidelines and penalties apply to any member of the supply chain that processes an EU resident’s data.