GDPR Project Decision: Risk-based Approach to Prioritizing Project Initiatives (Part 3 of 3)

By: Mitchell H. Levine, CISA - Audit Serve, Inc.

This is the second article of a three part article intended to provide a roadmap for GDPR compliance for those areas of GDPR that present the most risk to an organization if these initiatives are not completed

This is the final installment of a three-part article intended to provide a roadmap for GDPR compliance using a risk based approach.  The first two installments focused on those areas of GDPR which presented the most risk to an organization if these initiatives are not completed.  The financial risk entails fines issued by the Supervisory Authority and individual data subject lawsuits as per Article 82.   The basis for these fines and lawsuits are the various types of complaints that would be registered by data subjects which range from Controller not processing SAR (Subject Access Rights) Requests or not having a lawful basis (Article 6) for processing and storing data which is based on not obtaining the data subject’s expressed consent (Article 7 & 8) or not providing the proper disclosures to the data subjects (Article 13 & 14)  The one dependency which links all of these requirements is the mapping of personal data to business processes which also forms the basis of the data inventory of personal data required by Article 30.

GDPR Articles which will less likely to result in fines by the Supervisory Authority or lawsuits from data subjects relates to the security aspects of GDPR.  Article 32, Security of Processing, states “Data Controller and processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk”.  GDPR Article 32 does not define the specific technical and organizational measures and basically leaves it to the discretion of the controller and processor to decide the extent of the control measures which need to be implemented.  When GDPR specifies “appropriate to risk” organizations can use whatever Risk Assessments they deem appropriate to identify the controls and countermeasures required to mitigate the risk to acceptable levels.  The processes used can range from the formal processes included within the ISO 27005 Risk Assessment, informal risk assessment processes or even taking existing SOX 404 ITGC Risk Control Matrices and expanding the scope of the systems to go beyond the systems which impact the financial statements to all systems which store and process personal data.  Regardless of the Risk Assessment processes that are used,  no one outside the organization, especially the Supervisory Authority, will know whether the establishment of processes to meet Article 32 is sufficient or deficient.  For Processors, they may be cited for having deficient Article 32 initiatives by their clients who are the Controllers as part of the Controller’s vendor oversight reviews which is implied to be required as part of Article 28 (only using GDPR compliant Processors).

*****************************************************

Upcoming Audit Serve GDPR Seminar entitled Assessment, Implementation and Auditing Approaches 

June 13 - 14 Phoenix ISACA Chapter  Tempe AZ (near Phoenix)
June 25th  Virginia ISACA Chapter  Norfolk, VA

*****************************************************

This leads us to the next area where there is little risk that deficient approaches for meeting GDPR articles will be identified by the Supervisory Authority which includes the use of GDPR compliant processors (Article 28) and having an effective Data Breach notification (Article 33 & 34).  However, if a data breach does occur which becomes public, having deficient processes for handling the identification and notification of data breaches would then be the basis for large fines by the Supervisory Authority and lawsuits by the data subjects who were impacted.   Fortunately, GDPR follows the path of HIPAA, GLBA and other US state data breach notification requirements in which organizations only  have to report data breaches within a specified timeframe “after they become aware” of the breach.  Obviously, organizations which have deficient audit trails and monitoring controls may never become aware of a breach.  This longstanding approach which is an inherent weakness in all past regulatory requirements has now been correct by DFS NYS Part 500 Cybersecurity Requirements which requires banks in NYS to have the audit trails and monitoring processes which would identify a data breach.  Unfortunately, Part 500 only impacts NYS banks but based on NYS taking this bold new step of upgrading data breach notification processes, it will only be a matter of time before the other regulatory bodies follow the same path.

Being only several weeks from the May 25^th GDPR compliance date, most organizations realize that they will not complete all of the project initiatives required to meet all of the Articles set forth within GDPR and therefore need to take a risk based approach to direct the project resources to the project initiatives that would have the greatest impact to an organization.

 _______________________________________________________________________________

Mitchell Levine, CISA, Founder and President of Audit Serve Inc. and his consulting team  conducts GDPR Impact Analysis and Implementation Services and Project Assessments of organizations and IT Audit Consulting Services.   Contact Mr. Levine Levinemh@auditserve.com for additional information.