Privacy frameworks provide a structured approach to defining and achieving privacy objectives but as organisations become more digitised and adopt cloud focused strategies the fact that personal data and processing activities are increasingly distributed across multiple environments, applications, services and suppliers creates significant compliance challenges.
The use of eDiscovery tools to locate personal data in these complex scenarios is growing and this does help to deal with the difficulty of understanding what personal data is being processed and where it resides but documenting the processing activities that use the data in a way that is complete, accurate and easily consumed is getting harder. In practice this tends to be a manual process requiring analysts to review systems, applications and services in order to determine what processing activities have been implemented and where they are running.
Regulators are prescriptive in terms of the mandatory content that needs to be captured so there is clear direction as to how reporting standards can be met. Over time this has encouraged the use of templates such as those provided by the UK Information Commissioners Office (ICO) and France’s Commission nationale de l'informatique et des libertés (`CNIL). Organisations using templates such as these do not have to reinvent the wheel.
Even so, the process is generally regarded as quite painstaking and only those organisations that have a few processing activities running in a limited number of environments and who work with a small range of data subject categories could make this approach work efficiently. This is not the reality for most organisations. Furthermore, agile product delivery methods increase the pace at which products and services are created putting additional pressure on privacy teams as they need to continuously review and update relevant records.
Data Interoperability Reduces Compliance Challenges
Many of these challenges could be reduced if key stakeholders including: business analysts, developers, application / service vendors and privacy regulators embraced data standards and interoperability in a way that other sectors have.
In healthcare for example, HL7 was created as both a framework and as a set of standards to enable sharing and integration of health information between a wide range of software applications and scenarios. This enabled inefficient manual processes used to convert and move data between applications to be replaced by processing engines that could automate the process.
In software development, engineers use an Interface Description Language (IDL) to document APIs that they build. When the IDL is embedded within application code APIs are automatically documented and published when the code is updated. The level of detail available allows other analysts, developers or even applications to understand and use the APIs in the correct manner. This replaces older approaches whereby the documentation of APIs was carried out as a separate process.
In both of these scenarios data standards provide prescribed formats for describing and representing records and the data interoperability component provides an agreed mechanism for electronically exchanging those records.
Applied to records of processing, a simple data standard, or set of tags, could be defined to describe the format for encoding the mandatory and optional information required. Application vendors and developers could embed this record of processing data standard into their products. A busines analyst using a busines processing modelling tool would be able to embed a description of that process in the model which could then be published in a standard way. Technical designers using an architecture modelling tool with the same data standard embedded would be able to use and extend the description to include technical information required as part of the records of processing.
Commonly used enterprise application packages, CRM solutions and marketing automation solutions that typically provide process templates could embed the standard to provide support automatic for publication of the processes implemented.
Automating records of processing management
In taking this approach, the key points are as follows
at the application level metadata is added to describe its type, operating environment in which it is executed and the jurisdiction in which it runs
where processing is subject to sector specific regulations or mandates additional tags can be added at the application level to identify the sector
at the application function level metadata is added to describe the purpose for which the processing activity is performed
where functions consume or create data tags are added to identify the type of data involved
where functions reference a data subject then a category of data subject tag is added
where functions send data outside of the application this can be indicated by the addition of a data sharing tag
Once applications and function are tagged as described above a ‘publish records of processing’ function collates all of the metadata and publishes this to a central repository using an open interchange format such as XML or JSON. In time, the repository provides the set of all processing activities taking place within an organisation. It also acts as a data exchange and can be easily used to populate compliance reports for external auditors or regulators.
Additional opportunities present themselves in that other departments within the organisation such as: compliance, legal, risk assessors and strategic partners could access the repository in a standard way.
Looking Ahead
Overall, this approach is more efficient and it creates an improved ability to quickly gather, monitor and publish compliance information. It also ensures that the data and information expected is transparent, easily accessible and flows freely from business analysts to product development, privacy and security teams, and to regulators as required.
In an increasingly cloud first information environment there is no reason why privacy regulators can’t be granted direct access to interactive on-line repositories managed by the data controllers from whom they need compliance data. Where the information available is based on an agreed standard and is presented in a consistent manner, regulatory review will be easier and more efficient.
Komentarze