Data Processing Agreement

This Data Processing Agreement is concluded under Article 28(3) GDPR between the customer as controller and Syncture as processor, and governs the processing of personal data contained in the files the customer publishes into the Service. It forms part of the Terms and is accepted with them.

1. Parties, scope and precedence

This Agreement is between the customer as controller and DI Osama Almughanni BSc, sole proprietor, Döblergasse 3/3/8, 1070 Vienna, Austria, trading as "Syncture", as processor. It forms part of the Terms and is accepted with them. Defined terms carry the meaning given in the Terms.

It governs personal data contained in Customer Data, being the projects, folders, models and versions the customer publishes. It does not govern the data we process about the customer in our own right as controller, being account, contact, billing and website data, which the Privacy Policy describes.

On a question of data protection this Agreement prevails over the Terms. A separately negotiated and signed agreement between the parties prevails over this one.

2. Processing on documented instructions

We process Customer Data only on the customer's documented instructions, including as to transfers to a third country. The instructions are the Terms, this Agreement, and the customer's own use of the Service: publishing, sharing, moving and deleting are instructions.

We process Customer Data for no purpose of our own. No process in the Service opens a model for any purpose of ours, and nothing published is used to train any model. We will tell the customer immediately if we consider an instruction to infringe the GDPR or other Union or Member State data protection law, and may suspend that instruction until it is resolved.

Where Union or Member State law requires us to process beyond the customer's instructions, we will tell the customer of that requirement before processing, unless that law forbids it on important grounds of public interest. This satisfies Article 28(3)(a).

If we determine the purposes and means of processing Customer Data, we are a controller for that processing under Article 28(10). We do not, and clause 2 is what says so.

3. What we are technically able to reach

A workspace is created either with encryption on or with encryption off. Off is the default. The choice is fixed when the workspace is created. This clause is what the answer to every access question turns on, and a controller answering their own client should know which kind they hold.

(1) Where a workspace was created with encryption off, Customer Data is stored in a form we are able to read. What limits that access is this Agreement, the Terms, Austrian law and the organisational measures in Annex II. It is not limited by cryptography. Under valid legal process we could be required to produce a model in readable form.

(2) In an encrypted workspace, the bytes of every file inside a published version and every element-ownership document are encrypted by the add-in on the customer's own Windows machines, under a 256-bit key generated on the customer's side and never transmitted to us. We hold no key with which to open them. Annex II records the algorithm and what Article 34(3)(a) does and does not reach.

(3) In both cases we hold in readable form: workspace, folder and project names; the relative path and exact byte length of every file in every version; the number and stored size of each piece; the sequence, time, author, note and host release of every publish; the share graph with its capabilities; and which machine holds a lock. A version's file list is written to object storage as plain JSON when it is too large for its database row.

(4) A workspace key lost by the customer cannot be reproduced by us, and clause 9 is unaffected by that.

(5) The same sub-processors apply whichever kind a workspace is. Turning encryption on introduces none. A workspace created in the customer's own storage keeps its project files in an object store the customer names and contracts directly: the Service holds that store's address and no credential for it, no request of ours reaches those files, and that store's provider is the customer's own processor and not a sub-processor under this Agreement. Annex III does not change.

(6) Production access reaches what the Service reaches and no more. It exists to deploy the Service, respond to an incident, and answer a support request the customer raised. It is held by the one person named in clause 1.

4. Confidentiality

Every person we authorise to process Customer Data is bound to confidentiality, by contract or by statutory duty, and that duty survives the end of their engagement. Access is granted only where a task requires it and is withdrawn when the task ends. This satisfies Article 28(3)(b).

5. Security of processing

We implement the technical and organisational measures in Annex II, which are appropriate to the risk on the factors in Article 32(1): the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing, against the likelihood and severity of the risk to individuals. We may replace a measure with one at least equivalent. This satisfies Article 28(3)(c).

On Article 25, and the default. Data protection by design and by default is the question the encryption setting raises, so the reasoning is stated rather than left to be asked for. A workspace key exists only where the customer put it. A default that switched encryption on would, the first time a key was mislaid before an estate was ready to hold one, destroy that workspace's versions permanently and with nothing on our side able to help. Off is therefore the default, the choice is put to the controller before the workspace is created, it costs nothing either way, and the measures in Annex II apply to both kinds. A controller whose assessment differs turns it on, and clause 3(2) is then the answer.

6. Sub-processors

The customer gives general written authorisation for the sub-processors in Annex III. We impose data protection obligations on each that are equivalent to those in this Agreement, and we remain fully liable to the customer for their performance. This satisfies Article 28(2) and 28(3)(d) and Article 28(4).

We will give thirty days' notice by email before adding or replacing a sub-processor. The customer may object on reasonable data protection grounds within that period. If we cannot resolve the objection, the customer may terminate the affected part of the Service at the end of the then-current period without charge, and the switching provisions of the Terms apply.

7. Assisting with data subject requests

We assist the customer by appropriate technical and organisational measures, so far as possible, in answering requests under Chapter III GDPR. A data subject who contacts us directly is referred to the controller, and the customer is told. This satisfies Article 28(3)(e).

In practice two rights need no request of us. Access and portability are served by the export, which writes the whole of an account to disk in a documented layout, run on a machine holding the key where the workspace was created with encryption on. Erasure is served by deletion, which the customer performs itself and which clause 9 describes.

8. Breaches, assessments and prior consultation

We assist the customer in meeting Articles 32 to 36, taking account of the nature of processing and the information available to us. This satisfies Article 28(3)(f).

We notify the customer of a personal data breach affecting Customer Data without undue delay after becoming aware of it, and in any event within 48 hours. The notice describes the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where the full picture is not available at once, we send what we have and complete it as we learn more.

Whether to notify a supervisory authority under Article 33 or individuals under Article 34 is the customer's decision as controller. Annex II states where Article 34(3)(a) unintelligibility applies and where it does not. We supply the information reasonably needed for a data protection impact assessment under Article 35 or a prior consultation under Article 36 on request.

9. Deletion and return

At the end of the provision of services the customer chooses whether we delete or return Customer Data. A return is made by the export before deletion. This satisfies Article 28(3)(g).

Deletion is the ordinary deletion of this product: no trash, no recovery window, structure removed at once and bytes released and then removed once nothing else refers to them. The same method applies in an encrypted workspace. Destroying a key is not offered in place of erasing the data.

One qualification. Rows removed from our database persist for up to thirty days in the platform's point-in-time recovery, which exists to restore the service after a fault, is not reachable as a customer feature, and ages out on its own. Nothing is restored from it at a customer's request.

Termination alone does not delete anything. The account becomes read-only and stays readable and exportable until the customer asks for deletion, or until we delete it after the ninety days' notice by email in clause 5 of the Terms. We delete existing copies unless Union or Member State law requires us to keep them, and invoices are kept under Section 132 BAO.

10. Information and audit

We make available to the customer all information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits and inspections conducted by the customer or an auditor it mandates. This satisfies Article 28(3)(h) and nothing in this clause restricts that right.

The practical route, offered first because it is what most controllers want, is a written answer. A question about this Agreement, Annex II or a security questionnaire is answered in writing within thirty days, by the person who wrote the code. An on-site or remote inspection is arranged on reasonable notice, during business hours, without disrupting the Service, and under confidentiality. We may charge our reasonable costs for more than one audit in a twelve-month period, except where an audit follows a personal data breach.

We hold no ISO 27001 certificate and no SOC 2 report, and we do not imply otherwise anywhere. A questionnaire asking for either should be answered with that sentence and with Annex II.

11. Transfers outside the EEA

Object storage for a European account is held under Cloudflare's EU jurisdiction, a contractual guarantee that those objects do not leave the European Union. It is the default and the fallback where a region cannot be determined. Annex III lists the regions an account may be placed in.

The control database carries the same guarantee, for every account. The database holding names, paths, the share graph, device records and invoices is a single Cloudflare D1 database created under Cloudflare's EU jurisdiction, which restricts it to run and store its data inside the European Union. For a European account, therefore, all Customer Data stored by the Service remains in the European Union.

Where a transfer to a third country occurs, it rests on an adequacy decision under Article 45 where one covers the recipient, and otherwise on the Standard Contractual Clauses under Article 46(2)(c) together with supplementary measures. We supply the safeguards relied on to the customer on request.

Most of what is stored is not personal data at all. A request from an authority outside the European Union for model geometry is governed by Article 32 of Regulation (EU) 2023/2854 rather than by Chapter V of the GDPR. We answer such a request only under a valid international agreement, or on the grounds that Article permits, and then only to the minimum required. We tell the customer unless we are lawfully barred, and we will challenge a request Union law does not recognise.

12. Liability, duration and contact

This Agreement takes effect when the Terms are accepted and runs for as long as we process Customer Data. Liability between the parties is governed by the limitations in the Terms. Liability to a data subject under Article 82 GDPR is governed by that Article and is not limited by this Agreement or by the Terms.

Enquiries under this Agreement go to mail@syncture.com.

Annex I. Subject matter and duration

Subject matter. Hosted storage, versioning and controlled sharing of building information models and the files published alongside them, for the customer's own project work.

Duration. For as long as the customer has an account holding Customer Data, and until deletion under clause 9.

Nature and purpose. Storage, transmission and retrieval on the customer's instructions. Content is stored in pieces addressed by a hash of the bytes held, deduplicated within one account and never shared between accounts.

Types of personal data. Names and email addresses appearing in shares, groups and sign-ins. Identity provider identifiers. The display name and Windows computer name recorded against a lock or a publish. And whatever the customer places in a model, which for Revit typically includes author, editor and reviewer names, title block entries, sheet and revision records and schedule content.

Categories of data subjects. The customer's staff, its consultants and other project participants it shares with, and any individual named inside a model the customer publishes.

Special categories. None is expected and none should be stored. Data within Articles 9 and 10 GDPR must not be published into the Service.

Annex II. Technical and organisational measures

Encryption in transit. Every request between a workstation, the browser console and the Service travels over HTTPS. There is no plaintext network path, and no inbound connection is made to a customer machine.

Encryption at rest. Objects are encrypted at rest by Cloudflare under keys Cloudflare manages, in every workspace. This protects against loss or theft of physical media and against nothing else, and no provider-managed scheme does more.

Encryption under a key the customer holds. In a workspace created with encryption on, chunk bytes and element-ownership documents are encrypted on the customer's Windows machines with AES-256-CBC and an HMAC-SHA256 tag over the whole stored object, verified before decryption, with subkeys derived through HKDF-SHA256 and bound to the workspace identity. The key is not transmitted. The Service refuses a write that does not carry the envelope header and the recorded key identifier. Article 34(3)(a) unintelligibility is available for those file contents only, and never for the items in clause 3(3).

Confidentiality and access control. Access is resolved by the Service on every request against workspace membership, shares and groups, so a withdrawn permission stops the next request. No workstation holds a storage credential and no client reaches object storage directly. A machine holds a 90-day device secret replaced on every use, and exchanges it for a one-hour access token. Sessions, device secrets and sign-in codes are stored only as peppered hashes. There is no password and no URL that grants access.

Integrity. A publish never overwrites an existing version. Content is addressed by a hash of the bytes held, and the Service re-hashes what it receives and refuses a mismatch. Software packages are signed and verified against a published SHA-256 before installation.

Availability and resilience. The Service runs on Cloudflare's infrastructure with the redundancy that provider offers within a region, and the control database carries point-in-time recovery for thirty days. No uptime figure and no recovery time is agreed, no independent backup of the customer's content is taken by us, and the Terms require the customer to hold its own.

Data minimisation. No IP address is recorded against an account, no hardware identifier is collected, and no record is kept of which projects anybody opened. A device record carries a label, which is the operating system and the city derived from the first request and thereafter the machine's own Windows computer name.

Organisational measures. Production access is limited to the one person named in clause 1 and is a provider account protected by two-factor authentication with its own audit trail. There is no API token, access key or storage credential in configuration, in secrets, on a workstation or in a log, because none is used. Deletion is verified by reference counting rather than by policy.

Testing and review. Authorisation, deletion, credential rotation and the accuracy of the representations on this site are covered by an automated test suite that runs on every change. No measure guarantees absolute security, and this Annex is a description rather than a warranty.

Annex III. Sub-processors and regions

These sub-processors are authorised at the date of this Agreement:

  • Cloudflare, Inc., United States, with processing in the regions below. Website hosting, the API and edge compute, the control database, object storage for customer project files, outbound mail, and the public store the software is downloaded from. Everything the Service holds passes through it.
  • Microsoft Corporation and Google LLC, United States, where a person chooses to sign in with them. They receive the fact of a sign-in and process it as controllers of that authentication under their own terms. They reach no Customer Data.

There is no payment processor, no analytics vendor, no error tracking service, no support desk product and no marketing platform. Storage is ordered by email and paid by bank transfer, so no card or payment-account data is collected by us or by anybody on our behalf.

A workspace created in the customer's own storage keeps its project files with a storage provider the customer chooses and contracts directly. That provider processes those files on the customer's instructions and not on ours, and is not a sub-processor under this Agreement. The Service holds that store's address and no credential for it. Beside the files, the Software writes into that store a description of each published version: its file names, sizes and digests, the publishing user's display name and the time of publishing, so that the customer can assemble the files without the Service.

The regions an account's object storage may be placed in:

  • European Union (Western Europe)
  • European Union (Eastern Europe)
  • United States (East)
  • United States (West)
  • Asia-Pacific
  • Oceania

The two European regions carry the EU jurisdiction guarantee described in clause 11. The control database carries it too, for every account.

Our tax adviser and our bank receive invoicing and accounting data about the customer as an organisation. They reach no project file and are not sub-processors of Customer Data.

Version of 10 October 2026.

10 October 2026