This is not a lesson in GDPR, but rather a general observation of the framework that outlines an enterprise's effort (at all reporting levels) for full, EU Compliance to the General Data Protection REGULATIONS.
There are four fundamental steps to follow to achieve compliancy. These are well detailed (in French) by the French Authority (CNIL) and can be found here.
The Data Processing Register (DPR) is the keystone to GDPR as those are the records
Establishing a DPR is fairly straight forward for Small and Medium Business (SMB's) and single-person-enterprises. It can, however, get quite complicated (as seen below) with larger companies.
GDPR is in it's nascent state of architecting a common solution/system globally. It is a system that requires that all cross-functional departments (or enterprises) work in harmony without divisionally siloed objectives/targets and rewards. Analogies of such evolution are everywhere with the advent of the information revolution:
The siloed evolution of ERP in the 90s
The evolution of Point-2-point-to-LANS-to-WANS-to SD-WANS
all programme & project practices (Prince2, PMI/PMP, ITIL, Agile, etc.)
What the organisational structure should look like to accommodate GDPR compliancy is just as confusing. There are a ton of questions on Linkedin about CISO's and DPO's as to whether they can be mutually inclusive. The key to remember is that:
The CISO is responsible for the appropriate management & direction of the Corporations INTERNAL business information & integrity.
DPO is an independent advocate (could be internal, could be outsourced) who is responsible for the proper care & use of the CUSTOMERS information (particularly nominative in nature).
A final and very important point: The last bullet point indicates that the DPO role could be "outsourced". By this it is meant that third-party services (Software-as-a-Service or SaaS), could be used to "manage nominative data" on your behalf. This does NOT absolve anyone from maintaining "audit-able DPR's" as seen below.
It actually eases your management of nominative data, but you/enterprise are still responsible for your own DPR integrity. A non-compliant SaaS will render your own DPR non-compliant! Here are some questions to ask (yourself and your SaaS) to insure your DPR integrity.
And finally, be aware of what I call SaaS-Piggybacking. This is when one SaaS is using other SaaS for various sub-elements of it's solution. As one example (I am not suggesting non-compliance here!) The event-management SaaS called Eventbrite uses a number of sub-elements in it's excellent solution for it's non-core-activity processes such as Business Infrastructure, Payment Services, Communication Tools, or worse, Analytics. I am actually quite impressed by this level of detail that Eventbrite provides towards GDPR compliancy.
GDPR compliancy requires cross-functional, Agile participation
and considerable planning and architecting