Zuva API Security Overview
Data Retention
Zuva’s API is not intended as a long-term storage repository. Thus, uploaded documents expire and are removed from the system after 7 days by default. The expiration duration is also configurable, from 1 hour to 14 days, with the option of extension (as long as the file needs to be kept for further processing).
Also, you can choose to delete it before the expiration date, using the Files API. Once a document has been deleted from Zuva API, it can not be restored.
Data Residency
Zuva’s API servers are hosted in Microsoft’s Azure cloud platform; currently available in the following regions: United States and Europe. Our clients are allowed to select one of these regions to create their tokens and use API services in that region.
Zuva API is also available in a private cloud environment (including in a different Azure region) or for self-hosting, for an additional fee.
Clients who are obligated to store their data within their own IT boundaries prefer to use Zuva API’s on-premise deployment option. In this way, they could use API services without requiring to send the contractual data out of their own IT systems.
Data Segregation and Encryption
All data within an individual Zuva API client account is stored and permissioned in a way such that only the token used to create the data can access it. This mechanism ensures the data is inaccessible from other client accounts.
Data is encrypted in transit and at rest. Transport Layer Security (TLS, protocol version 1.2) is utilized for encryption during transport. Our service supports high-grade 256-bit ciphers as well as ciphers providing forward secrecy. Once data reaches our servers, it is processed and stored in a client-specific object store on a 256-bit encrypted disk.
Data Ownership
Zuva enables you to build custom fields, by using your own documents for training the Zuva-offered AI models. By default, you have an exclusive right to fields you trained.
No other Zuva customer, or Zuva itself will have access to use your fields and data without your permission. In this way, you are guaranteed that your data will never be used by other parties for training or any other purposes without your permission.
Disaster Recovery
Currently we have a documented disaster recovery policy for existing Zuva products in production. These policies are reviewed and validated at least once a year. The technical procedures that support our disaster recovery plan are tested more frequently. As stated earlier, Zuva API is not intended as a long-term storage repository, so data loss in the event of catastrophic failure is limited. In the event of a catastrophic failure, our provisioning and deployments are highly automated to ensure that recovery time is minimal.
Security Testing and Response
End-to-end security tests continue to be performed for all updates. Zuva’s vulnerability tests are performed continually throughout the software lifecycle, and our team is willing to discuss the results of the latest 3rd-party testing for customers under NDA.
We employ the following best practices: applying software patches as soon as possible; regularly scanning our servers for known vulnerabilities; monitoring server logs and vulnerability scan logs; limiting external software dependencies; source code security reviews; and using restrictive policies for software jails, firewalls, and access control whenever possible.
Model Security
Zuva enables customers to build fields using their own documents as training data. The storage format of our AI models are designed in a way that does not rely on the content of the documents that were used to train them. This results in a structure that cannot be reverse-engineered to reveal the documents they were trained on.
If customers who have already trained fields within Kira Systems are willing to transfer these fields to Zuva, we offer them a secure method (called “AI Field Sharing”) for model confidentiality that uses differential privacy to guarantee confidentiality mathematically. With this technique, Zuva is able to ensure not only the documents, but every single word, number and symbol contained in those documents can’t be discerned or reverse-engineered.
Personnel and Data Security
All our employees go through background checks and are trained with respect to why the confidentiality of client materials matter to our company and our users, and in the consequences of insider trading. They are also subject to contractual confidentiality commitments that include a requirement that they keep client data confidential.
Despite trusting our team, we know the buck stops with our management. All members of our Systems Team (who are responsible for deployment, monitoring and maintenance of our infrastructure and application) have privileged admin access to all production environments in all our supported regions. With explicit management approval, senior members of the engineering team can obtain read-only access to application logs for triaging issues (customer or application related).
We do not outsource any programming tasks, though we do work with third-party consultants to test and improve our security.
SOC2 Compliance
Zuva API has successfully obtained SOC 2 compliance certification, demonstrating our commitment to the data security standards and practices.
It is also important to note that Zuva API is hosted within Microsoft’s Azure cloud platform, which is certified to SOC 2 Type II, ISO/ISE 27001:2013, and many others.
Information Security Policies
The following set of organization-wide policies are in place to protect personally identifiable information within Zuva API and other Zuva products:
- Incident Management Policy
- Information Security Policy
- Privacy Policy
- Secure Software Development Policy
- Change Management Process
- GDPR Compliance
On This Page