This whitepaper discusses the separation of Personally Identifiable Information (PII) from PfP’s core services, when PfP is being used as an API endpoint.
In Europe, the General Data Protection Regulation (GDPR) has established a framework for common decision-making and cross-border cooperation among Data Protection Authorities. But whilst DPAs may be collaborating (arguably, efficiently), we still live in a world where our personal, private data is co-opted, sold and used in ways we cannot know or discover, by profit-motivated corporations of all sizes and from around the globe.
The EU-U.S. Privacy Shield’s commitments are no more than paper commitments and are not being applied in practice. The US Federal Trade Commission is yet to start focusing on investigating substantive violations of Privacy Shield.
But privacy awareness is increasing. For example, since the effective date of GDPR, EU regulators have received more than 65,000 data breach notifications and 95,000 complaints.
It’s not just individuals who crave data privacy. Businesses too are seeking new and safe ways to hold, process and secure their data. Many will not allow PII to be stored “in the cloud”, shunning popular platforms such as AWS, GCP and Azure in favour of their own data solutions. These decisions are having knock-on effects on suppliers who rely on cloud services for efficiency and scale. A cloud-based supplier will simply not get the business of privacy-focused enterprise that shuns cloud services.
Here, we discuss a mechanism by which any user of business may benefit from the features and capabilities of a service provider, without giving the provider access to any of the user’s personally identifiable information.
- PII – personally identifiable information. Any information which alone or together with another piece of information, can be used to identify a living person
- PfP – Profiles for People. A web-based multipurpose Organisation Development (OD) tool for modelling individual and organisational behaviour.
- API – Application Programming Interface. One or more ways a service provider (such as PfP) can provide another business or service with ways to access its services from within their own.
Users and service consumers must create an account with a service provider and give, either as an individual user, or (in bulk) as an enterprise user, PII to the service provider in order that the provider can process the data.
This presents a clear and present danger to the provider of the information that
- data breach could result in the data being stolen, changed or deleted
- disaster could render the data useless
- loss of access for other reason (dispute, payment problems etc) could lead to lockout and effectively prevent the customer from doing business
When PfP began to look at this problem, we wondered if there might be a way we could give back something useful to a customer, even if we didn’t know who they were (and couldn’t begin to figure it out).
We started by asking some straightforward questions:
What do we actually need to do here? What problem are we trying to solve and what is the minimum information we need to have in order to solve it?nWhat do we actually need to do here? What problem are we trying to solve and what is the minimum information we need to have in order to solve it?
In coming up with answers, we thought about what our systems need in order to present a customer with the value they wanted from our service. It was very apparent that from the outset, we actually didn’t need to know the identity of the customer in order to process the responses to survey questionnaires.
Instead, our value proposition is centres around survey construction, responses and the processing we do on them. And because of our methodological approach (pairwise comparison) these responses are not required to carry any personal information with them – in fact, the whole point of PfP’s approach is that the personal information is, by design, unable to inform the results of our assessments.
Tokenisation: the secret sauce for decentralised personal services
PfP has developed a set of APIs that are designed to prevent the API user from passing any PII to PfP.
Instead, a user is represented on the PfP system only as tokenised data. A token is a unique, unguessable string of characters that bears no resemblance to any PII. Tokens are generated by PfP, and passed back to the customer to store as reference data.
These tokens are the only information PfP needs to reference the intelligent work it does when acting on inputs provided by API consumers.
An API-consuming organisation (a customer of PfP) need only store the token on their system, as a reference to what PfP has on its system. To retrieve results from PfP for you user, give us the token, and we’ll give you back the data we have (and remember, it’s not PII that we have).
PfP offers an API for data processing without sharing PII
For enterprise customers, on request and subject to commercial agreement, we provide access to our service via API.
API documentation is open for review and can be found here: https://docs.profilesforpeople.com