Personal data protection. GDPR compliance

GDPR (General Data Protection Regulation) is the EU regulation concerning personal data protection for EU residents. GDPR also regulates the transfer of personal data for processing by third parties outside the EU.

Personal data is information by which a person can be identified. Personal data includes name, address, phone number, MAC address of an IP phone, etc. Find the full list of personal data (defined by the administrator or provided by customers themselves) that may be stored in PortaBilling in Personal data that can be stored in PortaBilling section of this chapter.

To help you comply with this regulation the following enhancements are introduced in PortaBilling:

• Anonymizing personal data on the PortaBilling web interface and in API responses;
• Two-version PDF invoices and custom reports: one that contains full information and another that contains only anonymized personal data;
• Adjusted email/SMS notifications received by administrators to anonymize personal data;
• Recording user access to personal data in logs for troubleshooting and auditing purposes; and
• The “Right to be forgotten” functionality – the ability to completely remove customer personal data.

You can divide your administrative staff members into those who can see full customer details and those who are not allowed to process personal data.

Consider the following example:

Let’s say you provide services in France and your staff is in Paris, plus you have a remote administrator, Peter, in Montreal.

Peter must not process personal data without user consent and must not have access to it. Since you find it difficult to meet the GDPR requirements regarding personal data transfer and processing outside the EU, you decide to restrict Peter’s access to personal data.

To do this, you enable the Mask personal information in data accessed by this user option for his user in PortaBilling.

This way, when Peter opens a customer’s page, he sees that personal data is anonymized. When Peter receives an email or SMS notification that an invoice for a customer is re-generated, the customer name in the notification is also anonymized.

If you store additional information about your customers in custom fields and it could be considered personal (e.g., driver’s license or insurance ID), you need to anonymize it, too. To make this happen, mark this field as containing personal data in PortaBilling.

Peter can browse and modify customer details (e.g., assign add-ons to a customer account) and create new customers and accounts. However, upon customer creation or modification, he sees that the customer’s personal data is anonymized

All personal data, such as phone numbers, IP addresses and ports of call participants is anonymized in SIP and BE logs to prevent Peter’s access to it when he troubleshoots issues for a customer.

Peter’s activity in PortaBilling has the following limitations:

1. Access to customer and account self-care portals is forbidden.
2. Attachments with personal data that cannot be anonymized, such as call recordings and music on hold files are not available.
3. All other attachments such as account generation reports, invoices in invoice notifications, files with DIDs, etc. are available since personal data in them is anonymized.
4. Access to SIP and BE logs is forbidden since the logs contain personal data. (Personal data anonymization will be added in future releases to grant access to logs.)
5. Previously generated custom reports are not available for download. Reports yet to be generated are available since personal data in them is anonymized.
6. Access to the old web interface is forbidden so that access to unanonymized personal data is prevented.

The same logic applies when your staff manages personal data in PortaBilling via the API from an external self-care portal.

By default, all personal data is anonymized using the same pattern – only the first and last symbols are shown. In future releases we plan to introduce the capability to customize personal data masking.

Resellers can restrict access to their customers’ personal data for CC staff members via the API if they must not process it according to the GDPR. To make this happen, your ABC reseller enables the Mask personal information in data accessed by this user option, for example, for their CC staff member Bob Smith.

When Bob logs in to his self-care portal and retrieves customer information via the API, all personal data (e.g., name, contact details, etc.) is masked.

To protect personal data, PortaBilling produces two versions of customer invoices:

• Invoices with full data are generated for customers’ use;
• Invoices with anonymized personal data are available for administrators who have restricted access to personal data.

Previously generated invoices are not available for download for these administrators either; however, they can adjust and re-generate such invoices, if necessary.

Note that the generation of two-version PDF invoice files increases the load on the system and decreases statistics calculation performance.

To optimize the system load and increase the performance of the statistics calculation, you can disable the generation of invoices with anonymized data. For this, set the Invoice.Disable_Anonymized_Invoice_Generation option to Yes on the Configuration server. Note that in this case, the administrators with restricted access to personal data (the Mask personal information in data accessed by this user option is enabled for them on the PortaBilling web interface) won’t be able to review and download the invoices.

GDPR establishes requirements to record access to personal data by any user and consequently, to notify a supervisory authority should a personal data breach occur. Thus, service providers must track who processed personal data and when, and they must be able to prove it.

To meet these requirements, PortaBilling records every user action that deals with personal information. So whenever an administrator with full access to personal data modifies a customer, the action is recorded in a log. Similarly, when a helpdesk operator with restricted access opens a customer panel, PortaBilling logs the event.

This provides the ability to demonstrate the proper handling of personal data from creation to deletion. You can also provide proof of who exactly accessed personal data and a time stamp.

To comply with the GDPR “right to be forgotten” requirements, an administrator can completely remove customers’ personal data from PortaBilling.

The following personal data is removed from the PortaBilling database:

• All information about a customer and their accounts which is considered personal (e.g., name, billing and contact information, MAC address of an IP phone, etc.);
• all call recordings.

Сustomer and account xDRs remain in PortaBilling, however, account IDs, CLIs, CLDs and IPs (e.g., subscriber_ip or originating_ip) are removed from them.

There are two options for removing a customer’s personal data:

• immediately upon termination; or
• after the specified storage period ends. (e.g., you store customer’s personal data until the limitation period expires).

Let’s say customer John Doe asks the administrator to close his contract and remove all his personal data from the system. The administrator schedules the termination of John’s record and arranges for his personal data to be removed immediately upon termination.

So once John’s record is terminated, PortaBilling deletes his personal data.

An administrator can preconfigure personal data removal via the customer class. Thus, all the customers of this customer class share the same configurations for data removal.

For example, an administrator can assign a “European Customers” customer class to all customers located in Europe and specify that these customers’ personal data be stored for one month.

The table below lists the kinds of personal data that can be stored in PortaBilling and defines the availability for users with restricted access to personal data.

Entity	Personal information	Anonymized	Not available
Customer and reseller	Name	Y
	Billing address information	Y
	Address information including country, state, city, ZIP code	Y
	Contact information such as company name, contact details, email, phone numbers, fax, BCC email	Y
	Credit card details	Y
	Additional fields in xDRs		Y
	Custom fields	Y
	Sales agents’ names
	Self-care credentials	Y
	Invoices	Y
	Recipient’s email for custom reports	Y
	xDRs	Y
Account	ID	Y
	Service password	Y
	Subscriber details such as name, email, phone numbers	Y
	Address information	Y
	Contact information	Y
	Aliases	Y
	Phone book details	Y
	Follow-me lists	Y
	Abbreviated dialing lists	Y
	SIM card information: IMSI, MSISDN	Y
	IP phone details: IP address and port, MAC address	Y
	Location IP address specified for geo/IP verification	Y
	xDRs	Y
	Additional fields in xDRs		Y
	Call records		Y
	Voicemails		Y
	Credit card details	Y
	Self-care credentials	Y
Vendor	Name	Y
	Address information including country, state, city, ZIP code	Y
	Contact information such as company name, email, phone numbers, fax, BCC email	Y
	xDRs	Y
	Self-care credentials	Y
Representative	Name	Y
	Address information including country, state, city, ZIP code	Y
	Contact information such as email, phone numbers, fax, BCC email	Y
	Initials	Y
	Self-care credentials	Y
CC_staff	Name	Y
	Address information including country, state, city, ZIP code	Y
	Contact information such as email, phone numbers, fax, BCC email	Y
	Self-care credentials	Y
Adminitrative users (e.g., Helpdesk operators)	Name	Y
	Address information including country, state, city, ZIP code	Y
	Contact information such as email, phone numbers, fax, BCC email	Y
	Self-care credentials	Y
Payment system	Merchant account credentials	Y