TOTAL: {[ getCartTotalCost() | currencyFilter ]} Update cart for total shopping_basket Checkout

The Privacy Advisor | How to navigate the software development life cycle under the GDPR Related reading: Podcast: Phil Lee on overcoming tribalism and how to get GDPR-ready


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.


If you want to comment on this post, you need to login.

  • comment Dale Smith, Jr. • Jan 24, 2017
    Bravo!  Finally someone who recognizes the enormity of IT's task in implementing GDPR compliance.  Agreed ... the time to get cracking with GDPR IT planning and prototyping is now.   Dale Smith, CIPT, Futurist, PrivacyCheq
  • comment Gregory Reid • Jan 25, 2017
    Dale, thank you for the nice comment. The GDPR has a number of functional and technical systems' requirements hidden in its text. Hopefully, my article has teased out most of those for the CIO group. The 'good news' is that many of the functional requirements that we're helping our client address, vis-a-vis the GDPR, are basic common sense capabilities that support their current and future system's security and reliability.
  • comment Peter Westerhof • Feb 5, 2017
    Yes, nice one! Plan > Do > Check > Act > Repeat
    It's all about requirements. Take a business risks management view, first see to it that all bases are covered and then go into detail. Draft a programme plan to execute into an auditable Governance & Compliance structure.
    Another article points out an additional point of attention : the CJEU adopted a pragmatic approach which might be characterized as 'fix it, move on, pay damages' (
    So, no escaping, and '1st time right' is cheaper by far.
  • comment Sholem Prasow • Feb 6, 2017
    It's even harder.
    Both RTBF and Portable Privacy have inherent Cybersecurity risks built in, In my opinion, it is a flaw in the GDPR. A security layer is just not good enough, especially since both requirements extend to third party interoperable systems.
    A hardened cybersecure design is required to be built at the outset if those 2 requirements are to be implemented safely, including strong authentication and clever data structures so that if an attacker gets in he can't erase all the data on the backs of an individual " forget me" command.
  • comment Vijayalakshmi Kannan • Feb 7, 2017
    Good article. Should the software development life cycle under GDPR be given as input/requirements by client(data controller) or should this be the responsibility of the data processor who develops software?
  • comment Eric Heitzman • Mar 8, 2017
    The technical requirements faced by each application differ based on the privacy laws in the jurisdiction where the application will be used, what kind of data will be handled, the age of the users, the programming language and frameworks utilized, and the architecture of the application. 
    WHICH technical requirements apply to each application?
    COMMUNICATING these requirements from the privacy/security groups to the engineering organizations should be done through engineering systems ("application management lifecycle" solutions).
    VALIDATING these requirements were implemented correctly should be automated to the extent possible.
    There is a class of software application called a "software requirements management platform" that automates these processes. 
    This "software requirements management platform" translates the lawyer-speak of EU-GDPR, but also COPPA, HIPAA, PCI, CalOPPA, GAPP, PIPEDA, and a dozen others into engineering speak (granular technical software requirements) and syncs those into Application Lifecycle Management systems.
    Take a look at SD Elements (
    It's a mature application in use at many companies, both large and small.
  • comment Sumit Chouhan • May 2, 2019
    Thanks for sharing this amazing information.