DocAI Security Overview

Data Storage and Residency

Zuva DocAI is not intended as a long-term storage repository. Thus, DocAI is designed to automatically delete a document submission after 48 hours. Also, you can choose to delete it before 48 hours using the Files API. Once a document has been deleted from DocAI, it can not be restored.

Zuva DocAI is hosted in Microsoft’s Azure cloud platform; currently available in the following regions: United States, Europe and Japan. Our clients are allowed to select one of these regions to create their tokens and use Zuva DocAI services in that region. Zuva DocAI is also available in a private cloud environment (including in a different Azure region) or for self-hosting, for an additional fee.

Data Segregation and Encryption

All data within an individual Zuva DocAI 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 DocAI 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

Currently, we are working towards SOC2 Type-1 compliance for Zuva DocAI. At this time we do not have confirmed dates or compliance levels, however, we are aiming to finalize this process within 2022.

It is important to note that Zuva DocAI 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 DocAI and other Zuva products:

  • Incident Management Policy
  • Information Security Policy
  • Privacy Policy
  • Secure Software Development Policy
  • Change Management Process
  • GDPR Compliance


Need Help?

Couldn’t find the information you were looking for or need more assistance?

Contact Support