Schemvia Data Processing Agreement
Version 1.0 | 17 October 2026
This Data Processing Agreement sets out how Schemvia processes personal data contained in Customer Content on the Customer’s behalf. It forms part of the agreement governing use of the Schemvia Service and applies to both free and paid use where Schemvia acts as a processor.
Schemvia: Hexlane Systems Ltd, registered in England and Wales under company number 16979924, with its registered office at Corbiere Church Hill, Chilton, Didcot, England, OX11 0SH, trading as Schemvia.
Customer: the person or organisation entering into the Agreement, identified in the relevant account, order form or other contracting record. A person accepting on behalf of an organisation must have authority to bind it.
1 Incorporation and scope
1.1 This Data Processing Agreement, including its Schedules (the DPA), is incorporated into the Schemvia Terms and Conditions or other agreement governing the Customer’s use of the Service (the Agreement). It takes effect when the Customer enters into the Agreement and applies whenever Schemvia processes Customer Personal Data on its behalf. No separate signature is required where the Agreement validly incorporates this DPA.
1.2 Schemvia acts as a processor and the Customer ordinarily acts as a controller. If the Customer is itself a processor, Schemvia acts as its sub-processor. The Customer must obtain the controller’s authorisation and relay its lawful instructions; references to the Customer’s controller obligations apply to that extent.
1.3 This DPA does not govern personal data for which Schemvia determines its own purposes and means, such as account administration, subscription management and service security information processed in its controller capacity. That processing is described in the Privacy Policy. Classification depends on the actual activity, and Customer Personal Data does not become controller data merely because it appears in a log or support request.
2 Definitions
2.1 Data Protection Laws means the UK GDPR and Data Protection Act 2018, and the EU GDPR and applicable EEA national data-protection laws where they apply to processing under this DPA, in each case as amended or replaced.
2.2 Customer Personal Data means personal data in Customer Content, analysis inputs or outputs, or related information that Schemvia processes on behalf of the Customer under the Agreement. Service and Customer Content have the meanings given in the Agreement.
2.3 Sub-processor means another processor engaged by Schemvia to process Customer Personal Data. Restricted Transfer means a transfer, including access from another country, requiring safeguards under Chapter V of the applicable UK GDPR or EU GDPR.
2.4 Controller, processor, personal data, processing, data subject, personal data breach and supervisory authority have the meanings given in the applicable Data Protection Laws.
3 Processing details and duration
3.1 Schedule 1 describes the subject matter, nature, purpose and duration of processing, the categories of data subjects and types of personal data. Schemvia will process Customer Personal Data only for the purposes and within the scope described there and in the Customer’s documented instructions.
3.2 This DPA remains in force while Schemvia or its Sub-processors retain Customer Personal Data, including during return, deletion and any permitted backup retention after the Service ends.
4 Customer responsibilities
4.1 The Customer determines why Customer Personal Data is submitted to Schemvia and is responsible for the lawfulness of its collection and processing, required transparency information, lawful bases, relevant permissions and the accuracy and minimisation of the data submitted.
4.2 The Customer will assess whether the Service and its security measures are appropriate for its processing, manage workspace access and credentials, and provide lawful, documented instructions. It will give Schemvia information reasonably needed to fulfil this DPA, including a current contact for urgent privacy and security notices.
4.3 Schemas should use synthetic examples where practical. The Customer must not submit special-category data, criminal-offence data or live authentication credentials unless expressly agreed in writing with Schemvia and supported by appropriate lawful conditions and safeguards. If such data is submitted inadvertently, this DPA continues to protect it while the parties arrange its removal or other lawful handling.
4.4 Nothing in this section transfers Schemvia’s own statutory or contractual obligations to the Customer.
5 Documented instructions
5.1 The Agreement, this DPA, the Customer’s authorised use of Service functions and written instructions accepted through the parties’ designated contacts constitute the Customer’s documented instructions. These include instructions concerning permitted transfers and use of authorised Sub-processors.
5.2 Schemvia will follow those instructions unless processing is required by UK law or, where the EU GDPR applies, applicable EU or Member State law. It will notify the Customer before that processing unless the relevant law prohibits notification on important grounds of public interest. Other legal demands will be assessed against applicable Data Protection Laws and transfer requirements.
5.3 Schemvia will immediately inform the Customer if, in its opinion, an instruction infringes Data Protection Laws. It may pause the affected processing while the parties resolve the issue, limiting any suspension to what is reasonably necessary.
5.4 Schemvia will not sell Customer Personal Data, use it for advertising or profiling, train machine-learning models on it, or use it for independent product-development purposes. Access for maintenance, troubleshooting and requested support must remain within the Customer’s instructions.
6 Confidentiality and personnel access
6.1 Schemvia will ensure that personnel authorised to process Customer Personal Data are bound by contractual confidentiality obligations or an appropriate statutory duty of confidentiality. Access will be limited to personnel who need it to perform authorised duties.
6.2 Personnel will receive appropriate privacy and security instruction. Access rights will be reviewed and removed when no longer required. Confidentiality obligations continue after an individual’s engagement ends.
7 Security measures
7.1 Schemvia will implement and maintain appropriate technical and organisational measures to meet Article 32 of the applicable GDPR, taking account of the state of the art, implementation costs, the processing and risks to individuals. The measures in Schedule 2 form part of this commitment.
7.2 Schemvia may update those measures as technology and risks change, provided the updates do not materially reduce the overall protection of Customer Personal Data. It will provide information reasonably necessary for the Customer to assess the measures.
8 Sub-processors
8.1 The Customer gives general written authorisation for Schemvia to engage Sub-processors under this section. The initial authorised Sub-processors are listed in Schedule 3. Schemvia will maintain an accessible register at https://schemvia.com/legal/sub-processors identifying their legal entities, functions, data categories and processing locations.
8.2 Schemvia will give the Customer at least 30 days’ advance written notice of an intended addition or replacement, using the designated contact or account email. Updating a public register alone does not replace that notice.
8.3 The Customer may object within that notice period on reasonable grounds relating to protection of Customer Personal Data. The parties will work in good faith to resolve the objection, including considering alternative arrangements. Schemvia will not give the proposed provider access to that Customer’s data while a timely objection remains unresolved.
8.4 If no reasonable solution is available, either party may end the affected part of the Service before the new Sub-processor starts processing the Customer’s data. Schemvia will arrange a proportionate refund of prepaid fees for the unused affected period through Paddle where applicable, and apply section 13 to the affected data.
8.5 Before a Sub-processor receives Customer Personal Data, Schemvia will carry out appropriate diligence and enter into a binding written contract imposing data-protection obligations equivalent to those required by this DPA for the processing concerned. Schemvia remains responsible to the Customer for the Sub-processor’s performance of those obligations.
9 International transfers
9.1 Schemvia will process Customer Personal Data in the locations stated in Schedule 3 and the notified register. A hosting region describes primary infrastructure location and does not, by itself, exclude processing elsewhere through support access, backups or other providers.
9.2 Schemvia will make a Restricted Transfer only on documented instructions and after putting in place a lawful transfer mechanism. This may include approved EU Standard Contractual Clauses and the UK Addendum, or the UK International Data Transfer Agreement, as applicable. Any applicable adequacy route must remain valid and cover the actual recipient and processing.
9.3 Where required, Schemvia will assess the transfer and implement supplementary safeguards before it begins. It will provide the Customer with relevant information about destinations and safeguards, subject to proportionate confidentiality and security protections.
9.4 This DPA is not itself a set of Standard Contractual Clauses, a UK Addendum or an International Data Transfer Agreement. If those instruments are required between the Customer and Schemvia, the parties will complete and execute or validly incorporate them before the transfer, including the required annexes and selections. Schemvia will separately secure the instruments required for onward transfers.
9.5 If a transfer mechanism becomes invalid or no longer provides the required protection, Schemvia will promptly inform the Customer and implement a lawful alternative or suspend the affected transfer. If the issue cannot reasonably be resolved, the Customer may terminate the affected Service and section 13 will apply.
10 Requests from individuals
10.1 Taking account of the nature of processing, Schemvia will assist the Customer through appropriate technical and organisational measures to respond to requests under Chapter III of the applicable GDPR. Assistance includes locating, exporting, correcting, restricting or deleting relevant Customer Personal Data where required.
10.2 If Schemvia receives a request concerning Customer Personal Data, it will promptly notify the Customer and forward relevant details. It will not substantively respond on the Customer’s behalf except on documented instructions or where legally required. The Customer remains responsible for deciding and responding to such requests.
11 Personal data breaches
11.1 Schemvia will notify the Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data. It will send the notice to the designated security or privacy contact, or otherwise the relevant account or workspace contact. It will not delay an initial notice until its investigation is complete.
11.2 To the extent available, the notice will describe the breach, affected data and individuals, approximate numbers, likely consequences, containment and remediation measures, and a contact for further information. Schemvia will supply further information as it becomes available without undue further delay.
11.3 Schemvia will investigate, contain and remediate the breach, preserve relevant evidence and keep records. It will reasonably cooperate with the Customer’s assessment and legally required notifications. The Customer decides whether to notify authorities or individuals in its controller capacity; Schemvia will not notify on its behalf without instructions unless legally required.
12 Compliance assistance and audits
12.1 Taking account of the processing and information available to it, Schemvia will assist the Customer with its obligations under Articles 32 to 36 of the applicable GDPR, including security assessments, breach notifications, data protection impact assessments and prior consultation with a supervisory authority.
12.2 Schemvia will make available all information necessary to demonstrate compliance with Article 28 and this DPA, and allow and contribute to audits and inspections by the Customer or its appointed independent auditor. Schemvia will maintain records required of it under Data Protection Laws and cooperate with competent supervisory authorities.
12.3 The parties will ordinarily use relevant documentation and remote review first, where sufficient. Inspections will take place on reasonable notice, during normal business hours, under confidentiality obligations and with proportionate measures to protect other customers and system security. These arrangements must not prevent an audit needed to establish compliance.
12.4 The parties will normally coordinate routine audits no more than once each year. Additional or expedited audits are permitted following a relevant breach, credible evidence of non-compliance or a supervisory-authority requirement. Neither a notice requirement nor a frequency preference limits mandatory rights or urgent investigation.
12.5 Schemvia will remedy identified failures within a period appropriate to their severity and provide reasonable evidence of corrective action. It may propose reasonable, pre-agreed charges for exceptional assistance beyond standard Service functions, but will not charge for remedying its own non-compliance or make payment a condition of legally required assistance or audit access.
13 Return and deletion
13.1 At the end of the relevant processing, Schemvia will, at the Customer’s choice, return Customer Personal Data in a commonly used, machine-readable format and delete remaining copies, or delete all Customer Personal Data, unless applicable law requires continued storage. Return rights under this DPA apply irrespective of plan-level export functionality.
13.2 A request from an authorised Customer contact may specify return, deletion or an earlier deletion date. If the Customer gives no other instruction, the default is deletion after the applicable recovery period in Schedule 1. Before that period expires, Schemvia will provide a reasonable opportunity to request return. Anonymous processing follows its shorter retention schedule, without a recovery window unless expressly provided.
13.3 Production copies, recovery copies and backups will be deleted within the maximum periods in Schedule 1. Pending backup expiry, data will be protected, put beyond ordinary use and accessed only where strictly necessary for recovery or legal compliance. If a backup is restored, deletion instructions will be reapplied before the restored data is returned to ordinary use.
13.4 Legally required retention will be limited to the necessary data and period. Schemvia will identify the requirement to the Customer unless prohibited by law, restrict processing to that purpose and delete the data when the requirement ends. Records retained in Schemvia’s independent controller capacity remain subject to the Privacy Policy and applicable law.
13.5 Schemvia will procure corresponding return and deletion by Sub-processors and, on request, provide written confirmation of completion, including any remaining protected backup retention and expected expiry date.
14 Liability and priority
14.1 Contractual liability between the parties under this DPA is governed by the Agreement’s applicable limitations and exclusions, only to the extent permitted by law. Nothing in the DPA or Agreement removes either party’s direct statutory duties, restricts individuals’ rights or limits supervisory-authority powers.
14.2 If documents conflict on processing Customer Personal Data, mandatory transfer instruments prevail, followed by this DPA, followed by the Agreement. A separately agreed data-protection amendment may expressly vary this DPA where legally permissible.
15 Changes and notices
15.1 Changes to this DPA follow the Agreement’s valid change procedure. Schemvia will give advance notice of material changes and will not materially weaken protection of Customer Personal Data during an existing subscription term without the Customer’s agreement, except where a change is required by law and continues to meet Data Protection Laws. Sub-processor changes follow section 8.
15.2 Schemvia privacy contact: privacy@schemvia.com. Schemvia security contact: security@schemvia.com. Customer notices will use its designated contact or relevant account contact. Each party will keep these details current.
15.3 Governing law and jurisdiction follow the Agreement, subject to mandatory Data Protection Laws and any governing-law or jurisdiction provisions in applicable transfer instruments.
Schedule 1 Processing description
Subject matter and purpose
Processing personal data incidentally contained in JSON Schemas, metadata and associated analysis information to provide the requested Schemvia schema compatibility and evolution service. The Customer determines the particular schemas and business purposes.
Nature of processing
Receiving and validating submissions; hosting and storing saved projects and schema versions; performing semantic analysis; generating and storing diagnostics and results; retrieving, transmitting and exporting data at the Customer’s request; and deleting data. Authorised support, maintenance and security operations are included only to the extent necessary to provide the Service under the Customer’s instructions.
Types of personal data
Names, email addresses, identifiers and other ordinary personal data that the Customer includes in descriptions, examples, defaults, enums, comments, project names or other schema metadata; personal data reproduced in analysis outputs; and related support information processed on the Customer’s behalf. The exact fields are determined by the Customer. The Service does not require personal data to perform schema analysis.
Categories of data subjects
Individuals referenced in Customer Content, potentially including the Customer’s employees, contractors, users, customers, suppliers or business contacts. The actual categories depend on the Customer’s submissions. Restricted data categories are addressed in section 4.3.
Frequency and duration
Submissions and analysis occur as initiated by the Customer, including API and CI requests. Saved content is processed while the relevant project or workspace is retained and through its applicable return and deletion process. Anonymous inputs and outputs are processed transiently under the separate maximum period below. Contractual protection continues until deletion is complete.
Retention and deletion limits
| Data or stage | Maximum period or rule |
|---|---|
| Saved schema content and results | While retained at the Customer’s instruction in an active workspace; then the return and deletion process below. |
| Workspace recovery period | 14 days after deletion or termination, unless earlier deletion is instructed. |
| Production deletion completion | Within 1 day after the recovery period ends, or after an earlier deletion instruction is received. |
| Backups and recovery copies | 7 days after production deletion; protected and beyond ordinary use pending expiry. |
| Anonymous inputs and outputs | 24 hours from submission, including any operational copies; no durable account history. |
| Customer Personal Data in support records | 2 years after the support matter closes, unless earlier deletion is instructed or retention is legally required. |
| Customer Personal Data inadvertently in logs | Remove or redact promptly once identified; any remaining copies expire within 30 days. |
Controller records such as Schemvia’s billing and account-security records have their own retention rules under the Privacy Policy.
Schedule 2 Technical and organisational measures
The following measures are contractual commitments for processing covered by this DPA. They do not assert any certification or independent audit.
Access and tenant isolation
Authenticated access to stored Customer Content; workspace-scoped authorisation checked on the server independently of client-supplied identifiers; role-based permissions; least-privilege personnel access; multi-factor authentication for privileged administration; and timely access revocation. Personnel access to schema contents is exceptional, authorised and logged.
Encryption and secrets
Encryption in transit using supported TLS configurations and encryption at rest for databases and backups. Credentials and secrets are held in controlled secret-management or deployment systems, excluded from source code and logs, and revoked or rotated when compromised. Access to encryption and configuration controls is restricted.
Application security
Input validation, request and payload limits, abuse prevention, rate limiting and protection against unauthorised API access. Development practices include code review, dependency and vulnerability management, and timely remediation proportionate to risk. Production data is excluded from development and test environments unless specifically authorised and equivalently protected.
Logging and monitoring
Security-sensitive operations are logged with access and retention controls. Application and error monitoring are configured to exclude complete schema contents, authentication secrets and unnecessary personal data. Monitoring identifies relevant availability, security and operational events; alerts are reviewed and escalated.
Resilience and restoration
Access-controlled backups or recovery facilities appropriate to the Service, documented restoration procedures and periodic recovery testing. Backup retention follows Schedule 1. Restoration processes preserve tenant isolation and reapply deletion instructions.
Incident response and assurance
Documented incident handling and escalation, designated privacy and security responsibility, and periodic assessment of security measures. Findings are tracked to remediation. Personnel receive relevant training and confidentiality obligations. Sub-processors are reviewed before use and on material changes.
Data lifecycle controls
Processes support the Customer’s lawful requests for access, return, correction, restriction and deletion. Retention limits are implemented across production, temporary processing, support and backup systems. Anonymous analysis is separated from durable authenticated project history.
Schedule 3 Sub-processors and locations
The initial Sub-processors authorised under section 8 are listed below with their contracting entities and processing locations.
| Provider | Purpose and data | Processing locations and safeguards |
|---|---|---|
| Render Services, Inc. | Application and API hosting; schemas, associated content and results processed by the hosted application. | Primary hosting: Frankfurt, Germany. Backup, support and remote access locations: as published in the provider information linked from the register. Transfer mechanism where required: EU Standard Contractual Clauses and the UK Addendum, through the provider’s DPA. |
| Databricks, Inc. (Neon PostgreSQL) | PostgreSQL hosting; stored projects, schemas, versions and analysis information. | Primary database: Frankfurt, Germany (AWS eu-central-1). Backup, support and remote access locations: as published in the provider information linked from the register. Transfer mechanism where required: EU Standard Contractual Clauses and the UK Addendum, through the provider’s DPA. |
Other providers whose classification depends on processing
Clerk, Resend and Sentry are not authorised under this Schedule to process Customer Personal Data on the Customer’s behalf. If their services involve such processing, Schemvia will identify them in the register and give notice under section 8 before that processing begins.
Clerk provides identity and authentication services. Account data processed for Schemvia’s own account administration is addressed in the Privacy Policy.
Resend delivers transactional emails. Where it processes Customer Personal Data on the Customer’s behalf, it will be identified in the register.
Sentry provides error monitoring. Where it processes Customer Personal Data on the Customer’s behalf, it will be identified in the register.
Paddle independently processes payment and transaction information as merchant of record. It is not included as a Sub-processor for Customer Personal Data on that basis.
The register describes relevant onward processing or links to detailed vendor information. Listed locations cover primary hosting, backup and support access. The online register and this Schedule are subject to the same change-notice and objection procedure in section 8.