So what will happen when I release the high level core platform?
It has the implementations of all the Microsoft platforms, every CRM platform (generic, real estate, etc). And all your lovely marketing platforms that you so love dearly (and don’t know do shit that is so not #privacy oriented).
The beans will be spilled if/when the higher level platform is released. California and EU lawyers will rejoice.
The GDPR.Common github is the basis for your privacy journey. Examples of how to use this is defined in the SDK. It gives you the ability to do the push/pull models through encrypted messages to your Event Hubs.
The Controller is the abstract web interface that you would implement to accept request from your core #privacy platform over the PGP secured messages.
You can find the source here : https://github.com/givenscj/GDPR.SDK
Implementing Privacy in your applications is easy. You don’t need to spend a ton of money on outside platforms to do it. I have made the GDPR core public on GitHub. This post will help you understand how to use it (a little bit anyway).
The main core platform I have not release yet to the public, but the lower layer I have and that’s what this post is about.
In order to implement GDPR, you must implement the interface I have defined and when I mean implement, I mean implement every interface for every application you have. This will take 2-3 days as an expert (me), 7-14 days as a great coder, 4 weeks as a good coder FOR EACH APPLICATION YOU HAVE.
The core is based on an application implementing certain interfaces. An abstract class *GDPR.Applications.GDPRApplicationBase* gives you the starting point for this. It implements the GDPRApplicationCore and IGDPRDataSubjectActions. The IGDPRDataSubjectActions (based on my Data Subject Action pattern definition) is the minimal amount of actions you must implement in order for your application to be FULLY GDPR/Privacy compliant.
It has the following methods:
void ProcessRequest(BaseApplicationMessage message, EncryptionContext ctx);
void ValidateSubject(GDPRSubject subject);
void AnonymizeRecord(Record r);
void AnonymizeSubject(GDPRSubject subject);
List GetAllRecords(GDPRSubject subject);
List SubjectSearch(GDPRSubject search);
void SubjectNotify(GDPRSubject subject);
bool SubjectCreateIn(GDPRSubject subject);
bool SubjectCreateOut(GDPRSubject subject);
RecordCollection SubjectDeleteIn(GDPRSubject subject);
bool SubjectDeleteOut(GDPRSubject subject);
bool SubjectUpdateIn(GDPRSubject subject);
bool SubjectUpdateOut(GDPRSubject subject);
bool SubjectHoldIn(GDPRSubject subject);
bool SubjectHoldOut(GDPRSubject subject);
bool RecordCreateIn(Record r);
bool RecordCreateOut(Record r);
bool RecordDeleteIn(Record r);
bool RecordDeleteOut(Record r);
void RecordHold(Record r);
bool RecordUpdateIn(Record old, Record update);
bool RecordUpdateOut(Record r);
List GetAllSubjects(int skip, int count, DateTime? changeDate);
List GetChanges(DateTime changeDate);
ExportInfo ExportData(List records);
ExportInfo ExportData(string applicationSubjectId);
ExportInfo ExportData(string applicationSubjectId, GDPRSubject s);
bool Consent(string applicationSubjectId);
bool Consent(string applicationSubjectId, List types);
bool Consent(GDPRSubject subject);
bool Consent(GDPRSubject subject, List types);
bool Unconsent(string applicationSubjectId);
bool Unconsent(string applicationSubjectId, List types);
bool Unconsent(GDPRSubject subject);
bool Unconsent(GDPRSubject subject, List types);
bool GetSubjectConsents(GDPRSubject subject);
You MUST implement all of those methods for EVERY APPLICATION in order to be privacy compliant.
Many CRMs do NOT allow you to do all of these. Many Microsoft platforms DO NOT allow you to do all of these through “public” apis. Only hidden ones can you get to 100% compliance.
There is NOT A SINGLE COMPANY ON THE PLANET that has implemented this for their corporate-wide organization. Every lawyer on the planet can sue and win if your application developers did not follow the above pattern.