Many of the information technology articles written about the EU's General Data Protection Regulation center around specific business and legal obligations regarding personal data. Such articles often focus on where data is physically processed and the obligations of the data controller to manage its processing. This is a major consideration for global organizations operating in the EU. However, in addition to the location of data, the GDPR deeply and significantly impacts the software development life cycle and corresponding IT-development processes for organizations that plan to rollout information systems’ projects within the EU.

An organization’s IT department may use one of the many different types of SDLC’s in the marketplace, such as Agile, DevOPS, Waterfall, Iterative, and so on. Despite the different names and the different approaches, these various types of SDLC’s have several areas in common: All SDLC’s have some form of 1) plan, 2) design, 3) build, 4) test, 5) rollout, and 6) maintain phases that cover the entire lifecycle of an information system.

SDLC’s are used to build computer systems by successfully managing and controlling the IT project while leveraging the fact that most computer systems have common modules or layers. Not all systems are the same, of course, especially in today’s world. But generally, we find the following common IT systems’ modules in most technologies that we use today

• The data transport and security layers
• The database and data architecture layers
• The application and logic layers; and
• The presentation and portal layers.

While there are more layers, modules, and complexity in many systems, this list simplifies greatly for the discussion purposes of this article.

The SDLC, whichever type is used, manages and controls the information technology project, from planning to rollout, across these different layers or modules.

There are a significant number of business, process, policy and procedure requirements and changes under the GDPR. But the GDPR is incredibly impactful on the SDLC process for companies rolling out systems in the EU, and it increases significantly the complexity of the functional and technical designs associated with the various technical layers outlined above (e.g. the database layer) for IT systems.

The net/net is that the IT systems’ functional and technical requirements introduced by the GDPR are both substantial and nontrivial. Indeed, they influence almost every aspect of systems’ designs and builds across each of these technology layers. And these GDPR system influences need to be addressed in the planning stage of the SDLC, upfront, to avoid significant cost overruns and rework later in the IT process.

Here is an inventory of 16 areas of pertinent GDPR Recitals and Articles that influence the SDLC’s Functional and Technical Planning and Requirements for IT departments. This list will be helpful to general counsels, CIOs and leaders of IT as they compile their system’s requirements for their EU groups:

1.) Implementing data protection in the system and the organization, by design and by default, is a legal requirement:

• Recital 78 and Article 25

2.) Data is secured, and integrity and confidentiality are maintained, using technical and organizational means under the management of the controller: 

• Recital 49 and Articles 5-1(f), 32-1(b-d)

3.) Data encryption shall be used, when possible:

• Recitals 83 and Articles 6-4(e), 32-1(a)

4.) Data pseudonymization shall be used, when possible: 

• Recitals 26, 28, 29, 78 and Articles 6-4(e), 25-1, 32-1(a)

5.) Data shall be anonymized, when possible:

• Recital 26

6.) Processing attributes and (the processing) steps shall be provided to the data subject in an easy to understand form at the time of data collection, electronically or in writing:

• Recitals 39, 58 and Articles 12-1, 13-2(a-f)

7.) Data subjects shall have the right to access and review the processing of their data at any time:

• Recitals 58, 61, 63 and Articles 12, 15-1(a, d)

8.) Disparate data elements that could be considered personal data or considred personal profiling if processed or combined separately or together resulting in illegal activities:

• Recital 30

9.) Data regarding a data subject shall be portable to another provider (or perhaps even your competitor):

• Recital 68 and Articles 13-2(b), 14-2(c), 20

10.) The data subject shall have a right to a copy of their data in a commonly used format:

• Article 15-3

11.) The data subject shall have the right to have their data updated, free of charge, if there is an error:

• Recitals 59, 65 and Article 16, and, the data subject shall have the right to request this update electronically, Recital 59

12.) The data subject shall have the right to have their data erased without undue delay:

• Recitals 59, 65 and Articles 13-2(b), 14-2(b), 17, and, the data subject shall have the right to request this deletion electronically, Recital 59 (Note: There are special exceptions to this right provided in the GDPR.)

13.) The data controller must notify other IT organiazations that hold the data subject’s data that the data subject has requested data erasure:

• Recital 66 and Article 19 (Therefore, the IT department must know where all the data subjects’ data is being stored by third parties so that these third parties can be notified of erasure request. Up-to-date internal and external data inventories are critical.)

14.) The data subject shall have the right to object to processing, withdraw consent to processing and opt-out of processing. And the data subject can object to or withdraw their consent is these processing matters electronically:

• Recitals 59, 63 and Articles 7-3, 18, 21 (And with technical recommendation from the EU Council: Recital 67)

15.) Data is stored only for the time necessary to meet the objectives of the data subject. Out-of-date personal data shall not be stored. (Part of an Electronic Records Management strategy). And the data subject shall be notified of this time period or its calculation approach at the time of the data capture:

• Recitals 39, 45 and Articles 13-2(a), 14-2(a), 25-2

16.) A determination must be made, almost immediately, whether a data breach is likely to have been a “high risk to the rights and freedoms of the natural person” as such a technical environment must be in place to identify, track and assess such breaches:

• Recitals 85, 86 (regarding notification obligations), 87 (Note: Many articles, e.g. 33, 34) in the GDPR addressing the reporting obligations to the data subject and the authorities on this matter.

In addition, many of the above points, for example #11, require contact center updates and ongoing interactions and confirmations with the data subject. One thing is certain; each of the above 16 points will have a place in the SDLC’s functional and technical design documentation for systems, and each will add some complexity to the overall system’s planning and design phases. In addition, many will impact the company’s overall customer support processes, as well, as the GDPR not only demands certain "pure" technical requirements but also business-functional requirements that are supported by both technology and business process.

In summary, the GDPR’s text contains both explicit and implicit systems’ functional and technical requirements that both affect and influence the SDLC of organizations that plan on rolling out systems into the EU. The impact of the GDPR on the software development begins at the data architecture and data transport layers and progresses well up into the portal and presentation layers. The underlying key to IT development success is planning for these requirements during the initial SDLC phases; while they may add some complexity during the SDLC initial planning and design phases, the overall development costs will be greatly minimized if considered as early as possible in IT systems’ build process.