Appendix: Using the Data Privacy API

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.

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

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

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

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

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

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

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

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

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

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

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

This figure shows the 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

This figure shows the 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
Produce Specification	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

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 or OCI IAM includes personal information (user name and email address). The user may also manually enter personal contact information in IDCS or OCI IAM.

The Brand Compliance Right to Access and Right to Erase/Right to be Forgotten data privacy services are not extended to access IDCS or OCI IAM, so the retailer must also check for a corresponding user profile in IDCS or OCI IAM, and where necessary, remove the personal information from OCI IAM.

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 or OCI IAM.

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.