GDPR – Do not Architect or start your project without these considerations to significantly increase your likelihood of success. Many you rely on, miss these key points for GDPR Success.
Has your legacy software vendors kept up with the market? Are they GDPR API Friendly? If not, this may be why many of the 80% of companies are non-compliant. And, If they have kept up, have you kept up your maintenance? Has your vendor allowed for strategic user exit points to call todays API’s to apply the needed Point-of-Sale Decryption and Re-Encryption processes that would allow for successful coexistence with GDPR? If not, you may need to upgrade your software, switch to a new vendor or even build your own. If you believe changes are necessary, you should also consider upgrades or new products that utilize a Big Data platform as they naturally support large scale data manipulation support for BI, AI (AI said to be one of the most vulnerable places for exposed Personal Data) and other analytics.
After fielding numerous calls and attending face to face meeting with companies that are initiating Big Data and GDPR compliance projects, a topic that is most overlooked is how will Point-Of-Sale and other customer support or interaction systems remain functioning after their customer’s personal data is encrypted? How will or well do these applications co-exist with encrypted data?
A solution is necessary that allows a company to be largely GDPR compliant without stifling its ability to process customer’s orders and handle customer’s concerns. Sure, feel free to create a simple cross reference table; the hackers will love you for making it so easy to find the personal data they are seeking, so forget that idea. What next? BigDataRevealed has several Spark/Kafka Spring accessible API’s (out of its library of 200) that are designed specifically for the purpose of decrypting a single customer’s data found in the encrypted database and returning the decrypted data to the Point of Sale or Other application(s). Other APIs and techniques can then be used to update the database with encrypted results of the customers interaction. AI repositories are said to be some of the easiest and information rich targets for hackers. These applications can become more secure by keeping the data encrypted and using APIs that access the proper decryption keys for the files being processed. The APIs return a single group of related records for a customer that is needed by the legacy analytic application, one group at a time. These API’s only Decrypt Records or rows as needed, leaving the remainder of the data securely encrypted, limiting at any one time the exposure of your customers Personal Data to hackers.
I personally feel this is an area that even top rated and best of the breed auditing and consulting firms have been missing in their planning and architecting phases and overlooking during delivery. If these issues aren’t part of your initial design efforts you may be opening the door to panic Re-Architecting and Re-Engineering efforts when you realize you can’t process customer’s orders or develop analytics and remain GDPR compliant.
These are just some of many scenarios that derail GDPR projects and might be the predominant reasons that 80% of C levels have admitted their companies are just not GDPR ready. More thorough thought and expertise is needed to design a successful GDPR Architecture, especially when integrating older existing legacy systems from mainframes, database servers like Oracle, SQL Server, DB2, Teradata, and including Office documents, spreadsheets, PDF files etc. Big Data environments like Hadoop, Cassandra, Mongo dB, and others, plus Clouds such as Amazon AWS S3 and Hadoop, MS Azure, Google, and IBM also supply information that must be controlled and kept clean of exposed personal data.
Begin with knowledgeable advisers, a tool box filled with the proper APIs and applications and you have the beginnings of a successful GDPR project.
A future article will touch on the next group of GDPR requirements that will require insights, tools and API’s of their own to master. Just how do Indirect Identifiers work and what processes are needed to discover them. Is a central repository required to complete discovery and how can so many different sources of data, that most companies maintain, be included in such a repository?
Other future articles will discuss the inherent difficulties of processing streaming data, such as IoT and social media feeds; how to provide customers with their ‘Right of Erasure’; and what really constitutes ‘Consent’.
The good news for those companies struggling with GDPR compliancy is that BigDataRevealed (BDR) has a complete Application that includes numerous APIs designed for GDPR compliancy projects. BDR was developed using only open source technologies and has a data scientist and data steward front end for easy use by non-technical individuals. BDR has over 200 Spark / Kafka callable API’s that can be purchased separately for inclusion in other programs and processes of new or existing GDPR projects.
Just like customers who have experienced the risks associated with data breaches, such as identity theft or financial loss, it is now companies that will experience real risk when Regulators investigate a company’s ability to protect their customer’s personal data. Regulations are becoming more prevalent in enforcement and are increasing fines and consequences in severity so there is only potential harm in delaying your company’s efforts to become compliant. BigDataRevealed’s annual subscription price is scaled to provide the SME/SMB an opportunity to reasonably utilize our products while also being attractive for larger firms to include BDR as a complete application solution or the utilization of just the API’s the need in their GDPR projects.