Are current Language Service Providers (LSP) really secure? Are your translation vendors (linguists) offering secure translations? Is your company sensitive, private, confidential and proprietary information being translated by secure processes, partners, employees and vendors?
Even if you have a strong background check and do business only with security diligent vendors your risk exposure might be way bigger than what you can imagine. The investment to provide secure translations is not little.
Let us see some security challenges with a non comprehensive list:
- No company can completely control a personal device used by a vendor unless a significant cost is incurred in Mobile Device Management (MDM) software. Add to it the transaction costs related to vendor agreements to deploy the MDM in their own machines. Add the local regulations under which those vendors operate, and the MDM related liability in terms of privacy (MDM controls the remote device from head to toes). Add the IT support you must put in place for vendors under MDM. This cost will go beyond the usual profit behind today's translation services prices. Can a company provide secure translations without incurring in the high cost associated to MDM?
- Data kept in an end user computer, even if encrypted under current best standards, can be stolen when such device is for whatever reason in the hands of a criminal. Will an LSP be able to provide secure translations if linguists are using their own devices?
- Devices break and need to be repaired so unmanaged technician devices will end up with copies of your data at their disposal.
- Encrypting data is not as easy as some might think. Without proper key management the best encryption in the world is as good as plain text. You cannot trust end users to manage encryption of your data and therefore you can't trust them to deliver secure translations from their own devices.
- Everybody backs up data without looking at retention needs. Retention must apply to daily work related data and backups as well, but most backup software is not prepared to cherry pick what to delete. As a consequence even when your data is deleted from operational systems, copies of it are still accessible from backups. Without a sound retention policy, secure translations can't exist.
- Is deletion even enough? We know for sure it is not because of data remanence so who will take care of real data purging? If there is a chance of data remanence any offered secure translation is just a wishful thinking.
- Information about contacts and linguists is stored in company owned systems, most of the time separated from each other even if they communicate via bridges that keep the information synched. The fact of the matter is that private information might be all over the places.
Companies' hosted translation services are also at serious risks. Last year we witnessed contracts and passwords publicly available because of miss handling of confidential information.
Some might claim the usage of Secure Socket Layer (SSL) as proof of security due diligence and due care when the protocol implementation is actually insecure. Furthermore, data must be protected not only in transit but at rest and in use. SSL which in reality should not be used because it has been superseded by Transport Layer Security (TLS) just protects your data when in transit. Some believe that just using SSL and having the green lock in the browser is enough. You need to look under the hood. Finding common vulnerabilities on SSL/TLS for any website is actually quite simple: Just hit SSL Labs Server Test to start right now if you wish. You will be surprised to see how many LSP portals and online translation management systems (TMS) out there do not have an "A+" rating. Of course the question is, why some fail to protect the most basic entry point to your data? Security of data in transit therefore should not be taken for granted.
It requires a big deal of key management procedures to make sure the encryption keys do not fall in the hands of unintended recipients to guarantee that such encrypted storage is actually secure. It requires serious backup and restore considerations before you can be completely sure that your data is not actually exposed. We must not forget big leaks related to poor encryption and bad media destruction practices. Security of data at rest should not be taken for granted.
Not less effort is required from applications and users that are authorized to read in plain text any confidential data that is encrypted in transit or at rest. Application logs containing sensitive data are way more common than what you would like, and applications that show intrinsic logs containing sensitive data are not unheard of. Data in use protection demands strong security-first architecture rarely practiced even in the most regulated environments. Most LSP own or lease technology that exposes functionality via Application Programming Interfaces (API) through which intimate details could be exposed as we have all seen in the news recently. Security of data in process should not be taken for granted.
You cannot expect your translator to be a security expert but you can create secure environments. Unfortunately to do that you will need to have at least one security expert on board because it is not enough to just check for the existence of reports and certifications. The devil is in the details. Here is a start:
- Have comprehensive internal information security policies (ISP) that align with your business objectives
- Ask your LSP for their ISP and make sure they comply
- Ask your LSP for their internal organizational service controls (SOC) and confirm the ISP is covered by such controls
- Ask your LSP for internal audits on their SOC including results showing material evidence of such audit being conducted. Confirm the controls comply with your expectations about security
- Ask your LSP for an external audit on their SOC by Certified Public Accountants (CPA) in the form of a SOC 2 type II report. Confirm that the report complies with your expectation about security. For example you might be concerned not just about the security principle but also confidentiality, integrity, availability and privacy principles. You want to assert your LSP third parties like cloud providers do have a SOC 2 type II report and that it is periodically reviewed. You want to make sure there are SOC 2 Type II reports in the whole chain of providers. Do not go for less like SOC 1, SOC 2 Type I or SOC 3 reports. It is your right to know who handles your data and how it is handled
- Ask your LSP for an ISO 27001 certification. Since this certification does not come with a report then ask them for the following documents: Information security risk assessment process, Information security risk treatment process, Results of the information security risk assessment, Results of the information security risk treatment, Evidence of the monitoring and measurement of results, The documented internal audit process, Evidence of the audit programs and the audit results, Evidence of the nature of the non-conformities and any subsequent actions taken, Evidence of the results of any corrective actions taken
- Ask your LSP for their practices on Privacy. You want to know in exactly how many systems private information is stored. Ask about what they store in their TMS, CRM, ERP and Marketing automation tool and where are these hosted. Ask if they retain data to avoid Ransomware impact and if when they do that the retention policy kicks in on such retention as well. Ask how users can opt-out from the service, how can they be forgotten. Make sure your LSP is GDPR compliant not because they have policies in place but because you actually audit them or you trust their external auditor as a recognized and authorized CPA firm.
- Ask your LSP for the names of individuals in charge of handling security and check their credentials