GDPR

The data centre for our live chat software is located within the EEA in Frankfurt, Germany.

Our live chat software is fully GDPR compliant and all data is stored with the utmost security and transmitted with strong encryption in place. 

Our own internal application systems and data is stored on AWS servers within the EEA in Dublin, Republic of Ireland.

All data remains in the European data centre above and is processed by Yomdel staff operating outside the EU.

No, we do not.

If we were to transfer data outside of Europe, we would always inform you prior to proceeding.

We run a role-and-permission-based system to control access to your data.

1. Supervisors/managers – have access to all chat data and transcripts in order to manage the day-to-day chat service in terms of maintaining quality assurance, KPIs, business performance and general adherence to standard operating procedures.
2. Chat operators – have screen-only access to real-time and archived chat data and transcripts for a limited number of clients in order to communicate with website visitors and to process leads.
3. IT developers – have access to all chat data to be viewed only in relation to trouble shooting or technical development.

All system access is tracked and stored in database logs. As part of their contracted terms of employment, all personnel sign a confidentiality clause and have regular and robust training procedures to ensure data protection awareness and compliance.

Yes, subject to receiving notice and details of the audit.

We have BCR and Model Contracts in place with all our sub-processors not based within the EU.

Yes, we have an operations centres outside Europe.

Yes, we have contracts in place with all our operations centres to ensure they have the necessary processes and policies to be fully GDPR compliant.

All chat data remains archived in perpetuity unless a specific request is made to delete it from our production servers. Yomdel has written processes in place to ensure personal data is deleted upon request, subject to back-ups being maintained as per current UK laws. A record of deletions is also maintained in the event of a requirement to restore data from the back-up.

Yes – Yomdel’s DPO is Simon Townsend, Operations Director. Contact: 01403 616000 or via support@yomdel.com.

1. All transmissions to and from our live chat software provider use well configured, strong encryption via TLS 1.2 or higher. All communication between our live chat software provider and our servers use strong encryption over TLS 1.2 protocol.
2. Yomdel operates all its servers from a public cloud infrastructure that is stored in a ISO 27001 certified and SAS 70 Type II and SSAE16 compliant data centre with a defined and protected physical perimeter, strong physical controls including access control mechanisms, controlled delivery and loading areas, surveillance and 24x7x365 guards. Only authorised representatives have access to the data centre premises.
3. Yomdel currently uses several of the security features available from our cloud provider to help us handle security directly on the system, including:
   • Rigid security groups to limit remote access to servers
   • DDOS detection and automatic blocking of sources generating unexpected traffic
   • Strong password policy.
4. All our live chat software provider data centres are behind a number of security clearances, and there are always security guards on duty. Services are in compliance with theSSAE16 standard. Provider staff are granted access only in their respective fields and day-to-day work. They are also required to maintain confidentiality after departure from the company.
5. Live chat software provider developers treat stored customer data with the highest level of security and care. Each piece of customer data is treated as personal and in need of standardised protection. Our live chat software provider has employed security policies which ensure safety of the data storage and transmission.
6. All our live chat software provider connections are encrypted with 256bit SSL protocol. There is no expiration date on the stored data. The data will remain on their servers unless requested for it to be removed.
7. We train our users to be aware of phishing attacks, we use a password policy in Yomdel that enforces complex passwords and we use the Yomdel role system to give access to administrators only to the information they require.

We use continuous integration (CI) and deploy to development and staging environments before deploying to live. The staging site is a replica of the live environment and we run thorough manual test processes around data security. As part of the release process we stage coordinated ‘hack days’ in which we undertake a thorough review of the code in an effort to identify weaknesses that could be exploited. Our development team regularly run internal software vulnerability checks using automated products, and ensure patches are developed and delivered in a timely manner.

We have a Security Incident Response procedure available upon request.

Summary of the functions of the SIR procedure:

1. Making sure that all staff understand how to identify and report a suspected or actual security incident.
2. Advising the Incident Response Lead of an incident when they receive a security incident report from staff.
3. Investigating each reported incident.
4. Gathering, reviewing and analysing logs and related information from various central and local safeguards, security measures and controls.
5. Documenting and maintaining accurate and detailed records of the incident and all activities that were undertaken in response to an incident.
6. Reporting each security incident and findings to the appropriate parties. This may include the acquirer, card brands, third party service providers, business partners, customers, etc., as required.
7. Assisting police and legal personnel during the investigation processes. This includes any forensic investigations and prosecutions.
8. Resolving each incident to the satisfaction of all parties involved, including external parties.
9. Initiating follow-up actions to reduce likelihood of recurrence, as appropriate.
10. Determining if policies, processes, technologies, security measures or controls need to be updated to avoid a similar incident in the future. They also need to consider whether additional safeguards are required in the environment where the incident occurred.