B Appendix: Using the Data Privacy API
The Brand Compliance Data Privacy web service API provides a means for the retailer/portal owner to execute data privacy requests. The requests are classified as Right to Access, where an individual requests details of all their personal data that is held in the system; and Right to be Forgotten, where the individual requests that their personal data be erased from the system.
Note:
The provision of the Data Privacy API is a security enhancement which aids the retailer/portal owner to carry out data privacy requests.
It is the responsibility of the retailer/portal owner to manage the fulfilment of data privacy requests. In order to do so, they will need to build an application to call the Data Privacy API, and handle the returned data. The API will be permanently available for access on demand.
The retailer/portal owner's responsibilities include verifying the identity of the individual making the request, presenting the information back to them in a secure manner, and deleting any local copies of the data; also the configuration of the portal's Terms and Conditions to include statements about the consent to store personal data, and any opt-out procedure.
This appendix provides additional detail to support the DataPrivacyService section of this document. It covers the following areas:
-
Definition of Personal Data: an explanation of some of the terminology used, and the type of data within Brand Compliance that is considered to be personal data.
-
Personal Data Flow: an overview of the flow of data within Brand Compliance which is considered to be personal data.
-
Right to Access Requests: further detail on this type of request, with an example of its execution.
-
Right to be Forgotten Requests: further detail on this type of request, with an example of its execution.
-
Other Aspects of Data Privacy: other aspects of Data Privacy and how they relate to Brand Compliance.
Definition of Personal Data
The following terms are used to describe the actors involved in the handling and processing of personal data:
-
Data Subject - The person whom the personal data describes. In Brand Compliance, this refers to an employee of the retailer/portal owner, an employee of a supplier, or an employee of a third party such as a design agency or certification body.
-
Data Controller - The retailer/portal owner. In a cloud environment, Oracle becomes the data custodian, but the retailer/portal owner retains ownership and control of the data.
-
Data Processor - Applications that work with personal data, such as Brand Compliance, and any external applications that share its data.
The definition of personal data is any information that can be mapped to a unique user, whether the identifiable information is stored with the key or not.
The personal data held in Brand Compliance is business contact information, such as:
-
Name of the data subject
-
Contact addresses
-
Email addresses
-
Telephone and Fax numbers
A general assumption is that user-defined/custom fields and file attachments are not used to store personal data. This is applied as a policy constraint rather than specific controls within the system.
Personal Data Flow
The following diagram outlines the flow of personal data within Brand Compliance:
Figure B-1 Personal Data Flow
![This figure shows the flow of personal data. This figure shows the flow of personal data.](img/personal_data_flow.png)
The Data Subject (requestor) makes the request to the Data Controller (retailer/portal owner) who submits the request to the Brand Compliance Data Privacy API. The API performs the search or erase processing accordingly and returns the results for the retailer/portal owner to relay back to the requestor.
The full suite of Brand Compliance APIs allows the retailer/portal owner to make requests from external systems to retrieve, create, update, (and in some cases delete) Brand Compliance data. The data handled by these APIs may include personal data.
Access to Brand Compliance data through the APIs is secured by an extension of the system's configurable Permissions security model. Based on the role-based access control model which restricts users' access to data and functionality based on their role within the system, external systems are granted access to the API services. If necessary, the access can be restricted to individual endpoints of the services. Authentication is achieved using individual ids and passwords.
Note:
Brand Compliance does not push data to external systems; the retailer/portal owner pulls the data. It is therefore the responsibility of the retailer/portal owner to trace and flag any personal data that has been taken from Brand Compliance, as appropriate.
Right to Access Requests
The Right to Access service facilitates the request from the data subject (individual requestor) to the data controller (retailer/portal owner) to provide details of what personal data concerning them is held, and to provide a copy of the data in electronic format.
The majority of personal data is held within User/Person records (an account for each user of the system) and Contact records (supplier users may be designated specific contact roles). There are also instances of personal data that are not linked to a user account, such as the names and email addresses of general contacts, who are not users of the system. The retailer/portal owner must decide which of that data returned by a search relates to the requestor.
When a retailer/portal owner receives a request, they use the Right to Access application they have developed to call the Data Privacy API. The API searches Brand Compliance and returns the results for the retailer/brand owner to analyze, and edit or reformat if necessary, before relaying back to the requestor.
Personal Data Searched and Returned
The following table describes the areas of the system that hold personal data, and which fields are searched and returned.
Personal Data
Record/ Element Name | Details |
---|---|
User <user> |
Each user of the system has a User record and a Person record which contain their Name, Email, Phone, Mobile, Fax, and Address details. Each account has a Login id, which is unique to the user. Names and email addresses are not necessarily unique. Search Field: Name Returned Fields: Record Type; Name; Email; Phone; Mobile; Fax; Login; Address; User Type (RETAILER, SUPPLIER or SITE); User record id; Person record id |
Contact <contact> |
A supplier user may be designated a contact for the supplier or its sites. Contact records share data with the User and Person records; they contain the Name, Email, Alternative Email, Phone, Mobile, Fax, and Address fields. A contact may be an individual who is not a user of the system. Search Field: Name (where contact is flagged as not a user of the system) Returned Fields: Record Type; Name; Email; Alternative Email; Phone; Mobile; Fax; Address; Contact record id; Supplier Name; Supplier Code |
Company <retailer> |
The single Company record holds the main retailer/portal owner contact details of a Contact Name and associated Email, Phone, Fax, and Address fields. The contact may or may not be a user of the system. Search Field: Contact Name Returned Fields: Record Type; Contact Name; Email; Phone; Fax; Address; Company record id |
Order Request <orderRequest> |
Order Requests are created when a new supplier completes registration. They contain details entered using the registration wizard, such as the name of an Individual or Department, a Contact Name, and associated Email, Phone, Fax, and Address. The contact may or may not be a user of the system. Search Field: Individual or Department; Contact Name Returned Fields: Record Type; Individual or Department; Contact Name; Email; Phone; Fax; Address; Order Request record id; Supplier Name; Supplier Code |
Design Agency <designAgency> |
A glossary of Design Agencies is used for sending email containing Pack Copy files when a product specification is completed. Each record contains a Contact Name and supporting Email, Phone, Fax, and Address, which refers to an individual at a third-party organization. Search Field: Contact Name Returned Fields: Record Type; Contact Name; Email; Phone; Fax; Address; Design Agency record id |
Counter Ticket Producer <counterTicketProducer> |
A glossary of Counter Ticket Producers is used for sending email containing Counter Ticket files when a Food or Produce counter ticket specification is completed. Each record contains a Contact Name and supporting Email, Phone, Fax, and Address, which refers to an individual at a third-party organization. Search Field: Contact Name Returned Fields: Record Type; Contact Name; Email; Phone; Fax; Address; Counter Ticket Producer record id |
Certification Body <certificationBody> |
A glossary of Certification Bodies is used to assign to Third Party Audits. Each record contains a Contact Name and supporting Email, Phone, Fax, and Address, which refers to an individual at a third-party organization. Search Field: Contact Name Returned Fields: Record Type; Contact Name; Email; Phone; Fax; Address; Certification Body record id |
Supplier <supplier> |
The Supplier record contains a Contact Name and associated Email, Phone, Fax, and Address fields, which refer to an individual who may or may not be a user of the system. Search Field: Contact Name Returned Fields: Record Type; Contact Name; Email; Phone; Fax; Address; Supplier record id; Supplier Name; Supplier Code |
The Supplier record also contains billing details entered using the registration wizard, including the name of an Individual or Department, a Billing Contact Name, and associated Email, Phone, Fax, and Address. They refer to an individual who may or may not be a user of the system. Search Field: Individual or Department; Billing Contact Name Returned Fields: Record Type; Individual or Department; Billing Contact Name; Email; Phone; Fax; Address; Supplier record id; Supplier Name; Supplier Code |
|
Site <site> |
The site may have a list of Growers associated to it for Produce type products. The Grower details contain a Grower Name and associated Email and Address, which refer to a third-party organization. Search Field: Grower Name Returned Fields: Record Type; Grower Name; Email; Address; Grower record id; Supplier Name; Supplier Code; Site Name; Site Code |
Audit/Visit <audit> |
The Audit/Visit record may have free text Name entries in the People Present table for attendees who are not users of the system. Entries for users also store the name in a snapshot text field. The Audit/Visit Issue record may have non-conformance actions with a free text Assigned To Name or a free text Completed By Name. Audit Checklists also share the Assigned To Name when a non-conformance is being created for a Checklist. Search Field: Name in People Present table; Issue Assigned To Name; Issue Completed By Name Returned Fields: Record Type; Name, Assigned To Name; Completed By Name; Audit/Visit record id; Audit/Visit Template Name; Audit/Visit Code; Supplier Name; Supplier Code; Site Name; Site Code; Audit/Visit Issue record id; Audit/Visit Issue Code |
Product Specification <productSpecification> |
The Product Specification record has a table of Printer Contact Name and associated Email, Phone, Fax, and Address, which refer to individuals at a third-party organization. Search Field: Printer Contact Name Returned Fields: Record Type; Printer Contact Name; Email; Phone; Fax; Address; Specification record id; Specification Number; Specification Version; Specification Name; Supplier Name; Supplier Code; Site Name; Site Code |
The FNF Product Specification record has a PIF Person Responsible and associated Email, Phone, and Fax, which refer to individuals at a third-party organization. Search Field: PIF Person Responsible Returned Fields: Record Type; PIF Person Responsible; Email; Phone; Fax; Specification record id; Specification Number; Specification Version; Specification Name; Supplier Name; Supplier Code |
|
The Product Specification has various approval names which are stored as free text. Search Field: Supplier Approved Name; Retailer Approved Name/Counter Ticket Issued By; Validation Override Approved By Returned Fields: Record Type; Supplier Approved Name, Retailer Approver Name; Validation Override Approved By; Specification record id; Specification Number; Specification Version; Specification Name; Supplier Name; Supplier Code |
|
Product Record <productRecord> |
The Product Record holds the name of the retailer approver of an associated specification/counter ticket. Search Field: Retailer Approved Name Returned Fields: Record Type; Retailer Approver Name; Product Record id; Product Number; Product Name; Supplier Name; Supplier Code |
Security and Logging
The following Service and Endpoint configurations must be configured within the Brand Compliance Admin area, and assigned to the External Systems that are to have access to the Right to Access service:
Service: |
DATAPRIV |
Data Privacy Service |
Endpoint: |
DATAPRIV_ACCESS_POST |
Creates a new DataPriv request and returns a link to the record's details |
Endpoint: |
DATAPRIV_ACCESS_GET |
Retrieves DataPriv details for a given id |
All calls to the service will be logged in the Brand Compliance Web Service Log.
The Data Privacy records created by the service are not viewable in Brand Compliance, and are not purged.
Example of Using the Right to Access Service
The request returns the actual data held, not the context in which it is used within the system. For example, to return the name and contact details of a Product Technologist, but not the fact that within the system they are responsible for approving product specifications and so on.
The stages involved in executing a Right to Access request are as follows. For this worked example, the call is made using a web service testing application.
-
Download the datatpriv WADL definition from the /services area of the Brand Compliance portal.
-
Submit a POST call to the services/rest/datapriv/access service, passing the name of the individual in the payload.
Figure B-2 Access Post Request
A recordLink element is returned with a link to a Data Privacy record.
-
Submit a GET call to the services/rest/datapriv/access service, passing the returned recordId value as the id parameter.
Figure B-3 Access Get Request
A message is returned containing the personal data that matches the name, within a dataprivRequestDTO root element. The structure of the XML message is as follows:
Figure B-4 Access Returned Message
Returned Elements
Element Name Details name
The name of the individual as passed on the POST request.
id
The record id of the Data Privacy record created for this request.
createdOn
Timestamp of when the request was submitted.
person
Personal data fields from the Person records that match the name parameter.
user
Personal data fields from the User records that match the name parameter.
designAgency
Personal data fields from the Design Agency records that match the name parameter.
counterTicketProducer
Personal data fields from the Counter Ticket Producer records that match the name parameter.
certificationBody
Personal data fields from the Certification Body records that match the name parameter.
orderRequest
Personal data fields from the Order Request records that match the name parameter.
retailer
Personal data fields from the Company/Retailer record that matches the name parameter.
supplier
Personal data fields from the Supplier record that match the name parameter.
site
Personal data fields from the Site record that match the name parameter.
contact
Personal data fields from the Contact records that match the name parameter.
audit
Personal data fields from the Audit/Visit and Issue records that match the name parameter.
productSpecification
Personal data fields from the Product Specification records that match the name parameter.
productRecord
Personal data fields from the Product Records that match the name parameter.
The personal data fields are contained within tags that are similar to their (English) field labels in the UI:
<ns0:user> <ns0:id>7</ns0:id> <ns0:loginId>john smith</ns0:loginId> <ns0:name>John Smith</ns0:name> <ns0:email>jsmith-supplier@example.com</ns0:email> <ns0:userType>SUPPLIER</ns0:userType> </ns0:user>
Additional metadata fields are included to identify the record by its code/id, name/description, and type.
Address elements may contain multiple localeData elements for country language translations:
<ns0:address> <ns1:country> <ns2:code>GB</ns2:code> <ns2:countryType>COUNTRY</ns2:countryType> <ns2:internetDomainSuffix>co.uk</ns2:internetDomainSuffix> <ns2:localeData> <ns1:description>Reino Unido</ns1:description> <ns1:locale>es</ns1:locale> <ns1:id>1904</ns1:id> </ns2:localeData>
There may be duplicates of the elements, where the system has more than one user with the same name, or where there are multiple records associated to an individual.
-
Edit the message using a text editor to remove duplicates, or entries that do not relate to the individual who made the request, and reformat if necessary, before delivering back to the requestor.
Right to be Forgotten Requests
The Right to be Forgotten service facilitates the request from the data subject (individual requestor) to the data controller (retailer/portal owner) to erase the personal data concerning them. The erasure of data is subject to certain predefined conditions within the system, and to the discretion of the data controller as to if/what data may be erased. The erasure is not reversible.
Data is erased by obfuscation, that is, replacing the value with a string of random text.
When a retailer/portal owner receives a request, they use the Right to be Forgotten application they have developed to call the Data Privacy API. The API validates the request and erases the requested data from Brand Compliance. The retailer/portal owner then relays the result back to the requestor.
Personal Data Updated
Generally, personal data is erased from User and Contact records, with the obfuscation of names and email addresses being reflected elsewhere in the system wherever they are referenced. Personal data that is not linked to a User or Contact record may also be erased; the retailer/portal owner must make a judgement on whether the data relates to the individual making the request.
The following table describes which areas of the system may have data erased.
Erasable Personal Data
Record | Fields |
---|---|
Users |
Name; Email; Phone; Mobile; Fax; Login; Address |
Contacts |
Name; Email; Alternative Email; Phone; Mobile; Fax; Address |
Company |
Contact Name; Email; Phone; Fax |
Order Request |
Individual or Department; Contact Name; Email; Phone; Fax |
Design Agency |
Contact Name; Email; Phone; Fax; Address |
Counter Ticket Producer |
Contact Name; Email; Phone; Fax; Address |
Certification Body |
Contact Name; Email; Phone; Fax; Address |
Supplier |
Contact Name; Email; Phone; Fax Individual or Department; Billing Contact Name; Email; Phone; Fax in the Billing Details |
Site |
Grower Name; Email; Address in the Growers table |
Audit/Visit |
Name in the People Present table Assigned To Name; Completed By Name in the Issue record |
Product Specification |
Printer Contact Name; Email; Phone; Fax; Address in the OLC section's Printers table PIF Person Responsible; Email; Phone; Fax in the FNF specification's Formulation section Supplier Approved Name; Retailer Approver Name; Validation Override Approved By |
Product Record |
Retailer Approver Name |
Text fields are replaced with randomly-generated text; the numeric GPS address fields are blanked; email addresses are set to x@example.com where x is 15 characters of randomly-generated text; countries and region selections are set to blank. If a field is blank, it remains unchanged.
If a User record is updated, the account is also deactivated and the password is expired.
Note:
The obfuscation of data in Brand Compliance as a result of a Right to be Forgotten erasure request is not reversible.
Personal data may also be updated using the individual APIs, or manually edited within the system. Physical deletion is not possible, due to referential integrity.
Exceptions
The key purpose of Brand Compliance is to assure due diligence in the management of the retailer/portal owner's products, and the suppliers thereof. There are legal or regulatory obligations to retain the approved technical product specifications for a set number of years, and during that time they may be required as legal evidence as part of a product safety issue. Where the approval or authorization by an individual forms part of the due diligence evidence, it is not feasible for the individual to be forgotten.
The following table indicates which fields are considered to be authorizations, and are preserved for due diligence purposes. These exceptions are therefore not erasable.
Preserved Personal Data
Record | Field |
---|---|
Scorecard |
Completed By |
Product Record |
Retailer Approval |
Produce Product Record |
Retailer Approval |
Temporary Specification |
Approved By |
Produce Specification |
Approved By |
Counter Ticket Issued By |
|
Product Specification |
Supplier Approved Name |
Retailer Approved Name |
|
Validation Override Approved By |
|
Counter Ticket Issued By |
Also, any names and email addresses within Pack Copy Files that have already been generated, and the Email, Batch Job, and Permissions Upload logs in the Admin area are preserved.
Purging Inactive User Accounts
The Right to be Forgotten service may also be used for purging user accounts that are no longer active, that is, those of users who have left the organization or are no longer involved in using the system. This is achieved by calling the API in the same way as if processing a Right to be Forgotten request.
Automatic date-based purging, such as a period of time since the user's account was disabled, or since their last login, is not provided, however the retailer/portal owner could feasibly develop a means of recursively calling the API based on a set of logic rules.
Security and Logging
The following Service and Endpoint configurations must be configured within the Brand Compliance Admin area, and assigned to the External Systems that are to have access to the Right to be Forgotten service:
Service: |
DATAPRIV |
Data Privacy Service |
Endpoint: |
DATAPRIV_VERIFY_POST |
Creates a new verification request for a login id |
Endpoint: |
DATAPRIV_ERASE_POST |
Creates a new Erasure request and returns a link to the record's details |
Endpoint: |
DATAPRIV_ERASE_GET |
Retrieves Erase details for a given id |
All calls to the service will be logged in the Brand Compliance Web Service Log.
The Data Privacy records created by the service are not viewable in Brand Compliance, and are not purged.
Entries within the Brand Compliance Change History logs, Attachments logs, and Comments logs use a foreign key to reference the name of the user who updated the record, attached the file, or added the comment. This means that if the name of the user is obfuscated in the User record, the name will automatically become overwritten with randomly-generated text in the logs.
Updates to records to erase personal data through the Data Privacy API are not recorded in the record's Change History log. This avoids showing what the value was before and after obfuscation.
Example of Using the Right to be Forgotten Service
The stages involved in executing a Right to be Forgotten request are as follows. For this worked example, the call is made using a web service testing application.
-
Download the datatpriv WADL definition from the /services area of the Brand Compliance portal.
-
Use the Right to Access service to retrieve the individual's set of personal data (see Right to Access Requests).
-
Edit the returned XML message using a suitable text editor, removing duplicate user and person elements.
Figure B-5 XML for Forgotten Returned
In this example, there are two pairs of user and person elements because there are two user accounts with the name John Smith - one for a retailer user and one for a supplier user (user name and email address are not unique, it is the login id that uniquely identifies a user).
In order to pass validation, there must only be one user and person element in the submitted XML message. Remove any user and person elements that are not the individual being erased. Delete all the data between the opening and closing tags, just leaving a single person and user:
Figure B-6 XML for Forgotten One Person
Note:
The message is XML and can be edited using any UTF-8 compliant text editor.
It is vital that the structure and syntax of the message is maintained (with matching pairs of tags), so editing with a tool that recognizes the XML file format is recommended. For details of the message structure, see Right to Access Requests.
Metadata fields that are included in the message to identify the records by their code/id, name/description or type are not erased. For details of which fields may be erased, see the Erasable Personal Datatable.
Person/User/Contact Relationships
There may be a combination of user, person, and contact elements for an individual, depending on their role within the system:
-
Each user of the system has a single User record and a single Person record.
-
If a supplier user is a contact, in addition to their User and Person records, they have a Contact record for each of their designated contact roles.
-
If an individual is a contact but they are not actually a user of the system, they have a Person record, plus a Contact record for each of their designated contact roles.
When submitting a Right to be Forgotten request, the following validation checks are applied:
-
Only one user element must be present.
-
Only one person must be present.
-
The associated person element must be present for a user or a contact element.
-
The personId in the user element must match the id in the person element.
-
The personId in the contact element must match the id in the person element.
-
The user id in the contact element must match that in the user element.
-
All contacts must be linked to the same person.
-
A person element must have an associated user or contact element.
-
-
Make further edits to the XML message to check that the data in the elements for designAgency, supplier, productSpecification, and so on, all relate to the individual making the request. If not, delete the elements.
When submitted, the personal data elements that remain in the message will result in the corresponding fields being erased in Brand Compliance (the field contents are replaced with randomly-generated text).
If an element is removed, the field contents remain unchanged. For example, if wishing to erase the Grower Name but not the associated Email Address or Address within the Site element, delete the growerEmail and growerAddress elements from the XML message.
-
Optionally submit a POST call to the services/rest/datapriv/verify service, passing the login id of the individual (obtained from the User element of the XML message returned in Step 2) in the payload:
Figure B-7 Forgotten Post Call
This step checks whether the individual is responsible for the completion of a Scorecard, in which case they will not be permitted to be erased.
-
Submit a POST call to the services/rest/datapriv/erase service, passing the XML message in the payload:
Figure B-8 Forgotten Post Second Call
A recordLink element is returned with a link to a Data Privacy record.
For possible failure conditions, see the Error Messages table.
-
Submit a GET call to the services/rest/datapriv/erase service, passing the returned recordId value as the id parameter:
Figure B-9 Forgotten Get Call
A confirmation message is returned, with the original data in a dataprivErasureDTO root element.
-
Optionally perform another a Right to Access request to check that the personal data has been erased as expected.
Otherwise, viewing the erased records within Brand Compliance will show the obfuscated data:
Figure B-10 Forgotten Removed Data
-
Advise the requestor of the outcome of their request.
Other Aspects of Data Privacy
This section describes some other aspects of Data Privacy, and how they relate to Brand Compliance.
Note:
The data passed to IDCS includes personal information (user name and email address). The user may also manually enter personal contact information in IDCS.
The Brand Compliance Right to Access and Right to Erase/Right to be Forgotten data privacy services are not extended to access IDCS, so the retailer must also check for a corresponding user profile in IDCS, and where necessary, remove the personal information from IDCS.
When a new user is created in Brand Compliance, the User record has a flag set to indicate that its data has been passed to IDCS.
Data Portability
Data Portability is the right for the data subject to receive the data concerning them, in a common, structured machine-readable format. The Right to Access service and other APIs provide access to the majority of Brand Compliance data. The Reports module also allows the export of data in various formats.
Privacy by Design and Data Minimization
Privacy by Design and Data Minimization relates to making data privacy and protection integral to the design of the system, such as minimizing the data set to that which is necessary to perform the function of the system, and restricting the access to personal data to just the users that need it. The personal data held in Brand Compliance is already minimal; it relates to business contact data.
Access to the Brand Compliance data is restricted by the Permissions security model, based on the user's roles and what organization they are associated to; the configurable access controls are granular, down the level of individual fields.
There is no need to specifically mark fields as sensitive in Brand Compliance, however, the retailer/portal owner could chose to do so by configuring the field label system text themselves.
Data Deletion
The deletion of data is limited due to the due diligence nature of Brand Compliance. Certain data must be retained indefinitely, so options to delete or purge data are limited to a select few areas. Where data is deleted, it is not possible for it to be re-accessed.
The Right to be Forgotten solution includes the retailer/portal owner's ability to purge personal data from inactive user accounts. As certain data cannot be physically deleted, the erasure is by obfuscating the appropriate fields.
Notice and Consent
Notice and Consent is necessary where personal data is being held or processed. In Brand Compliance, the Terms and Conditions pages can be configured by the retailer/portal owner to include the necessary notices for the user to accept or otherwise.
Availability
Backup and disaster recovery facilities for Brand Compliance are provided as standard as part of the Cloud Service solution.
The majority of Brand Compliance data is available for export using the suite of secure APIs.
Tracking Technologies
Brand Compliance does not include any Tracking Technologies such as IP addresses or device fingerprints. A single cookie is used, for session connectivity.
Separation of Duties
Some tasks, such as the approval of a Product Specification or completion of an Audit, require actions by separate users; the completion of the tasks is controlled in Brand Compliance by workflow rules.
Logging
Maintenance of Brand Compliance records is recorded in the Change History log. Read access is not logged.
The Web Service log records details of all API calls; these are accessible only to administrators.
The Brand Compliance data is secured by HTTPS/SSL in transit; data at rest in the MySQL application database is not encrypted.