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.
Restrictions on access to information and application systems via an access control policy. Users would only be provided with access to the network and network services that they have been specifically authorized to use. Xano’s CTO is responsible for providing guidelines on optional or conditional rules as necessary. Special measures are taken to account for changes to user permissions which are automatically made by the information processing department and which are user-requested and approval-based enactment.
Xano access control policy has been established, documented, and periodically reviewed on the basis of business and security requirements. Xano uses the policy as the basis for granting access rights to individuals and groups. Physical access to Xano instances is controlled via a virtual private network (VPN) and device and identity access management software.
Xano has a user registration and de-registration process which grants access rights to, new users as well as users with changed job functions. Immediately removing or blocking access rights of users who have changed roles or jobs or left the organization.
Xano requires users to sign statements indicating that they understand the conditions of access. The Information Security Officer reviews the user access rights intermittently to maintain effective control over access to data and information services. Maintaining a formal record of all persons registered to use the service (Information Asset Register or similar) with a duration of access capability.
All Xano users undergo yearly cyber security awareness training, with randomized phishing security tests throughout the year. Employee evaluations, access control, and password management are enforced and audited periodically, while the policy manual is updated and signed yearly.
Yes. Privileged accounts are only provided to Management that is authorized to perform system administration tasks. The number of privileged accounts is kept to a minimum.
Yes. Access to Xano instances is only accessed via VPN. No physical access.
Yes. Xano administrators authenticate utilizing MFA.
Xano has a responsibility to balance legal obligations with our commitments to our customers' privacy and data security. If we receive a court order from the U.S. Government to submit or transfer data, we would IMMEDIATELY consult with legal counsel before deciding how to respond. Legal counsel will provide crucial guidance on understanding the order, assessing its scope, and determining the appropriate response. Moreover, if we believe the order is overly broad, potentially infringing on privacy rights, or is in conflict with other legal obligations (like data protection laws in other countries), there may be grounds that legal counsel can help challenge the order or seek to modify its terms. Additionally, whenever legally permitted and practicable, we will attempt to notify affected users of any government request for their data. This allows users the opportunity to legally challenge the data request if they wish to do so.
Last modified 2mo ago