Security
Xano undergoes security and compliance audits multiple times a year and has secured the following certifications and attestations:
- ISO 27001:2013 Information Security Management System (ISMS) ISO 27001 is the only auditable international standard that defines the requirements of an information security management system (ISMS). An ISMS is a set of policies, procedures, processes, and systems that manage information risks, such as cyber-attacks, hacks, data leaks, or theft.
- ISO 9001:2015 Quality Management System ISO 9001:2015 serves as the quality benchmark for an array of organizations located across the globe. It acts as a crucial framework for businesses to judge & maintain their internal processes according to a fixed set of quality guidelines.
- SOC 2 Type 2 A SOC 2 Type 2 Report is a Service Organization Control (SOC) audit on how a cloud-based service provider handles sensitive information. It covers both the suitability of a company’s controls and its operating effectiveness.
- HIPAA The Health Insurance Portability and Accountability Act of 1996, commonly known as HIPAA, is a series of regulatory standards that outline the lawful use and disclosure of protected health information.
A subprocessor is any business or contractor customer data that may pass through as a side effect of using Xano's service. See our current list here.
Yes. Back-ups are executed every 24 hours. Backups are stored in the same region as the client's primary location, but in a different zone so as to escape any damage from a disaster at the main site.
Xano utilizes the Google Cloud Platform (GCP) as our cloud hosting provider. Google Cloud benefits are as follows when it comes to encryption at rest or in transit.
Google encrypts all customer content stored at rest, without any action from you, using one or more encryption mechanisms. Google uses several layers of encryption to help protect data. Using multiple layers of encryption adds redundant data protection and allows us to select the optimal approach based on application requirements.
All of Google's storage systems use a similar encryption architecture, though implementation details differ from system to system. Data is broken into subfile chunks for storage; each chunk can be up to several gigabytes in size. Each chunk is encrypted at the storage level with an individual data encryption key (DEK): two chunks won't have the same DEK, even if they are owned by the same customer or stored on the same machine. (A data chunk in Datastore, App Engine and Pub/Sub may contain the data of multiple customers.
If a chunk of data is updated, it is encrypted with a new key, rather than by reusing the existing key. This partitioning of data, each using a different key, limits the risk of a potential data encryption key compromise to only that data chunk.
Google encrypts data before it is written to a database storage system or hardware disk. Encryption is inherent in all of our storage systems, rather than added afterward.
Each data chunk has a unique identifier. Access control lists (ACLs) help to ensure that each chunk can be decrypted only by Google services that operate with authorized roles, which are granted access only at that point in time. This access limitation helps to prevent access to the data without authorization, strengthening data security and privacy. Each chunk is distributed across our storage systems and is replicated in encrypted form for backup and disaster recovery. An attacker who wants to access customer data would need to know and be able to access two things: all of the storage chunks that correspond to the data that they want and all of the encryption keys that correspond to the chunks.
Google uses the AES algorithm to encrypt data at rest. All data at the storage level is encrypted by DEKs, which use AES-256 by default, with the exception of a small number of Persistent Disks that were created before 2015 that use AES-128. AES is widely used because both AES-256 and AES-128 are recommended by the National Institute of Standards and Technology (NIST) for long-term storage use, and AES is often included as part of customer compliance requirements.
All data is encrypted at rest and in transit as discussed above. Additional encryption prior to insertion into a DB would be done through the Xano Function Stack, defined by the developer of this process.
Yes! Xano’s Disaster Recovery Continuity of Operations is the initiative that ensures that Xano is able to continue the operation of its essential functions under a broad range of circumstances including major service failures or disasters including denial of service, attacks, major virus outbreaks, or natural disasters. Viewing this plan is reserved for enterprise clients only.
Incidents are segregated as Major and Minor depending on the urgency and impact of the issue. All Incidents will be logged in Improvement Log with proper prioritization. Priority definitions as applied in the table below:
Priority | Definition | Description | Target Response | Target Resolution |
|---|---|---|---|---|
1 | Significant disruption to critical business activities; many users affected across many sites; major impact on business | Major Incident | 10 Minutes | 4 Hours |
2 | Some disruption to business activities; subset of users affected | High | 30 Minutes | 8 Hours |
3 | More than one user affected; moderate business impact | Medium | 1 Hour | 2 Days |
4 | Single user affected | Low | 4 Hours | 5 Days |
5 | Low urgency queries | Planning | 2 Days | 10 Days |
Due to extremely sensitive information that is highly confidential, we do not make the penetration testing report publicly available. We do however share the summary report.
Penetration tests are performed on an annual basis. Please see our OWASP web application penetration test results here.
Yes, we undergo yearly training and testing.
Last modified 3d ago