English version 2026-09-25. Versioned copy. For privacy and contractual questions: vegalysuae@gmail.com.
Vegalys | Data Processing Addendum
Version: 2026-09-25
Provider: ALTAIR CONNECT - F.Z.E
Language: English only
Publication date: 25 September 2026
Status: Published conditional DPA framework. Customer-specific schedules must be completed before any separately authorised processor activity.
This Data Processing Addendum (“DPA”) accompanies the Vegalys B2B Terms & Conditions and the applicable Order (together, the “Agreement”). Its schedules are integral, not optional: the identities, instructions, processing scope, locations, security measures, retention arrangements and applicable transfer instruments must be completed and approved before production processing starts.
The clauses below are contractual requirements for a separately agreed processor activity, not an audit report or a representation that every control is currently implemented. Bracketed fields in the schedules are customer-specific completion requirements. Publishing this framework does not complete those schedules, execute a DPA or authorise personal business-dataset uploads.
Current approved launch scope: business customers in the United Arab Emirates and European Union, with genuinely anonymised business datasets only. This DPA is a conditional framework for any actual, separately identified personal-data processing on a Customer’s behalf, not a declaration that anonymous datasets are personal data or permission to upload personal business records. The parties must identify any activity requiring a processor DPA; separate controller duties for account, contact and billing information are addressed in the Privacy Notice. The non-personal business-content rule in Schedule D is to be incorporated into the Order independently of whether the DPA’s processor clauses apply.
Parties, roles and interpretation
The parties are the Customer identified in Schedule A and ALTAIR CONNECT - F.Z.E, a Free Zone Establishment - Limited Liability, licence and registration number 53850 issued by the Free Zones Authority of Ajman, at B.C. 1301562, Ajman Free Zone C1 Building, Ajman Free Zone, Ajman, United Arab Emirates (“Provider”). The Provider’s privacy and contractual contact is vegalysuae@gmail.com.
“Customer Personal Data” means personal data processed by the Provider on the Customer’s behalf to deliver the contracted Service. “Applicable Data Protection Law” means the personal-data laws actually applicable to the relevant processing, including the UAE Federal Decree-Law No. 45 of 2021 where applicable and the EU GDPR where its territorial and material criteria are met; it does not mean that every law applies to every activity.
The Customer acts as controller and the Provider as processor, unless Schedule A records that the Customer acts as processor for an identified or properly described upstream controller and the Provider acts as subprocessor. The Customer must have the authority and upstream permissions necessary for the instructions and appointments it makes.
Account administration, direct business correspondence and the Provider’s own billing or legal records may be processed by the Provider as a separate controller, as described in the Privacy Notice. This distinction does not permit Customer datasets to be repurposed as the Provider’s own controller data.
Subject matter and documented instructions
The subject matter, duration, purposes, operations, data categories and data subjects are specified in Schedule A. Processing is limited to the Service actually contracted and delivered; a roadmap or product prototype is not an additional instruction.
The Provider will process Customer Personal Data only on documented instructions, including instructions on international transfers. The Agreement, completed schedules and authorised account operations constitute instructions within their agreed scope. Additional instructions must come from an authorised contact and be recorded; the parties will assess scope and reasonable implementation costs without withholding assistance that law requires.
If an instruction appears to breach Applicable Data Protection Law, the Provider will immediately inform the Customer and pause the affected instruction where necessary while the parties resolve it. The Provider will not silently alter the purpose or rely on the Customer’s instruction to excuse its own statutory duties.
Where law requires processing beyond instructions, the Provider will inform the Customer before processing unless legally prohibited, limit the action to what is required and record the justification. A foreign disclosure demand is not assumed to override applicable transfer restrictions.
The Provider will not sell Customer Personal Data, use it for advertising, disclose it to general-purpose AI services or train general-purpose AI models on it. Any separately proposed AI processing requires a new documented scope, appropriate vendor and transfer assessment and express contractual approval before use.
Customer responsibilities and restricted data
The Customer determines a lawful purpose and basis for collection and processing, provides required information to individuals, obtains any required consents and ensures instructions and disclosures are lawful. It must minimise the data supplied, restrict authorised users, keep instructions current and avoid placing unnecessary identifiers in free-text fields.
Only personal-data categories expressly approved for an actual processor activity in Schedule A may be processed under this DPA. Business datasets in the initial offering must be genuinely anonymised before upload; completing Schedule A must not silently expand that restriction. Health data, biometric identifiers, criminal-offence records, full payment-card information, government identity documents, data concerning children and other sensitive or sector-restricted records are excluded. A future expansion requires a separately signed scope amendment identifying the category, legal basis, necessity, safeguards and sector-specific requirements before processing.
The Service’s insurance-industry context does not itself authorise processing of policyholder health, claims or other regulated personal data. Pseudonymised data remains covered where an individual is identifiable; only effectively irreversible anonymisation removes data from the personal-data scope.
Anonymisation must address identifying attributes in data, filenames, metadata and free text, including combinations that permit reasonably likely re-identification. The Customer must not upload re-identification keys or attempt re-identification. If personal data is discovered in purportedly anonymous content, the parties must restrict the affected processing, notify the appropriate contacts and arrange secure deletion or other lawful handling; they must assess any incident duties and must not use this DPA to retroactively legitimise an unauthorised upload.
Confidentiality and authorised personnel
The Provider will limit access to persons with a documented need to perform the approved tasks. They must be subject to binding confidentiality duties, receive appropriate data-protection and security instructions and have access removed when no longer needed.
Access for troubleshooting or administration must be authorised, proportionate and recorded as set out in Schedule B. Customer content must not be copied into development environments, ordinary email, support tickets or external logs unless specifically necessary, minimised and approved under the applicable instructions and safeguards.
Security and operational assurance
The Provider will implement and maintain technical and organisational measures appropriate to the processing risks and the measures completed in Schedule B. Production processing may not start while a necessary agreed control is unimplemented; the parties must adjust scope or close the gap first.
Measures must address confidentiality, integrity, availability and resilience, access control, tenant separation, secure transmission, storage protection, vulnerability management, recovery, incident response and deletion. Any improvement may replace a control with an equivalent or stronger one but must not materially reduce the agreed level of protection.
No certification, audit report, encryption configuration, backup frequency, recovery objective or residency guarantee is represented as existing unless documented and evidenced in the completed schedule. A development objective is not proof of implementation.
Subprocessors
The Customer grants general written authorisation only for the subprocessors specifically listed as authorised in completed Schedule C. A brand name or an incomplete row does not constitute an approved appointment; the legal entity, service, data scope, relevant locations and protections must be identified.
The Provider will give at least thirty calendar days’ written notice before adding or replacing a subprocessor, including information sufficient to assess the change. The Customer may object on reasonable data-protection grounds within fifteen calendar days of notice. Where upstream consent or a transfer instrument requires stricter approval, that requirement prevails.
The parties will work in good faith to resolve an objection through additional safeguards or a reasonable alternative. The proposed subprocessor must not process the affected data while a timely objection remains unresolved. If no reasonable resolution is possible, the Customer may terminate the affected Service before the change, with a refund of prepaid fees for the unused period and no additional termination fee.
The Provider must impose substantially equivalent relevant data-protection obligations by a binding written contract, assess sufficient guarantees and remain responsible to the Customer for its subprocessor’s performance. Relevant contract information will be supplied on reasonable request, subject to necessary redactions that do not prevent compliance verification.
Independent controllers used for activities such as payment processing are not automatically subprocessors under this DPA. Their role and disclosure basis must be recorded separately; calling a recipient an independent controller does not authorise sending it Customer dataset content.
Processing locations and international transfers
The parties will complete Schedule C with the relevant processing countries, remote-access locations, backup/replication locations and onward recipients. Exact physical server addresses and sensitive infrastructure details may remain confidential, but locations and safeguards necessary for a lawful customer assessment may not be withheld on that basis.
The Provider will not initiate a restricted transfer, remote access or onward disclosure until the necessary lawful mechanism, assessment and supplementary measures are in place. Storage in a European country does not by itself resolve transfer issues associated with an overseas contracting party, remote access or external providers.
For transfers subject to the GDPR, counsel must select an available mechanism and confirm its suitability for the actual exporter/importer roles and the importer’s territorial status. Where the European Commission’s 2021 transfer clauses are appropriate, the parties must complete and execute the applicable module and annexes, identify the competent authority and governing law/venue required by those clauses, and perform the necessary transfer assessment.
This DPA does not itself attach, execute or silently incorporate completed standard contractual clauses. If the 2021 clauses are not suitable for a particular transfer, the parties must adopt another valid mechanism before it occurs; an unsupported assertion of adequacy or “EU hosting” is not a substitute.
For transfers governed by UAE or other applicable rules, the parties must separately identify and satisfy those requirements. EU clauses must not be assumed automatically sufficient for every jurisdiction; any UK or other jurisdiction-specific instrument requires its own completed assessment.
The Provider will promptly inform the Customer of a legally binding request for Customer Personal Data where permitted, assess its lawfulness and challenge it where there are reasonable grounds. It will disclose only what is legally required, document the response and comply with any more protective applicable transfer-clause duties.
Data-subject requests
The Provider will promptly forward requests relating to Customer Personal Data to the Customer, with an operational maximum of three business days after receipt, and sooner where necessary to meet a legal deadline. It will not answer substantively or disclose the Customer’s records without instructions unless law requires it.
Taking account of the processing, the Provider will assist through appropriate measures with access, correction, deletion, restriction, portability, objection and other applicable rights. The parties will agree secure verification, search and delivery methods without collecting excessive identity information.
The Customer remains responsible for its controller response and statutory deadline; the forwarding period is not an extension of that deadline. Ordinary assistance within the contracted scope is included; extraordinary work may be separately priced transparently, but a fee dispute must not obstruct mandatory or urgent assistance.
Personal-data breaches
A “Personal Data Breach” is a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to Customer Personal Data. The Provider will notify the Customer without undue delay after awareness, and in any event within twenty-four hours, or sooner if Applicable Data Protection Law requires it.
The twenty-four-hour ceiling is a contractual commitment for the separately authorised processing, not a general statutory waiting period. The Provider must not delay notification to obtain complete information or conclude an investigation.
The Provider's two-Business-Day ordinary support first-response commitment is separate. It does not extend this incident deadline, and ordinary mailbox support must not be assumed to provide the required emergency cover.
The initial notice will include, to the extent known:
- Nature and scope: affected systems, data categories, approximate individuals and records, and discovery/incident times.
- Likely consequences: the reasonably foreseeable impact and current uncertainty.
- Response: containment, remediation, preservation of relevant evidence and measures to reduce harm.
- Contact: a responsible incident contact and arrangements for further updates.
Missing details will be provided progressively without undue delay. The Provider will investigate, cooperate, maintain an incident record and assist the Customer in deciding and making notifications to individuals and authorities.
The Customer controls notifications concerning its controller obligations, except where law requires the Provider to act directly. Neither party must wait for the other’s approval to comply with a direct legal duty; they will coordinate where lawful. Notification is not, by itself, an admission of liability.
Risk assessments and regulatory cooperation
The Provider will supply information and reasonable assistance for data-protection impact assessments, prior consultations, security assessments and regulator enquiries relevant to its processing, taking account of the nature of processing and information available to it. It will inform the Customer if a material change affects the processing risk or previously agreed safeguards.
The Customer remains responsible for determining whether its intended use requires a DPIA or sector-specific approval. The Provider remains responsible for its own duties and must not rely on that allocation to avoid providing necessary information or acting on a known unlawful instruction.
Audits and compliance information
The Provider will make available information necessary to demonstrate compliance with this DPA and permit and contribute to audits, including inspections, by the Customer or an independent auditor bound to confidentiality. Existing evidence may be used first where sufficient; no unverified certification or report may be substituted.
For routine audits, the parties will normally use at least fifteen calendar days’ notice, business hours and no more than one routine audit per twelve months. These arrangements do not restrict additional or shorter-notice audits justified by a breach, material compliance concern, regulator request, applicable law or mandatory transfer clauses.
Audit methods must protect other customers’ information and service security without preventing effective verification. The Provider will remediate substantiated deficiencies within an agreed risk-based period; urgent risks require immediate proportionate action. Reasonable routine audit costs are normally borne by the Customer, but the Provider bears its remediation costs and reasonable additional audit costs caused by its material non-compliance; costs must not defeat mandatory audit rights.
Return, deletion and retention
The Provider will follow the completed Schedule D during processing and at exit. The Customer may request lawful earlier deletion or return; the selected twelve-month post-subscription archive concerns genuinely anonymised business content and is not a minimum personal-data lock-in overriding such instructions.
At the end of the processing services, the Customer chooses return or deletion of Customer Personal Data. Where return is chosen, it must occur through the agreed secure method within the completed export period, followed by deletion of remaining copies in accordance with Schedule D, except to the extent a valid legal requirement requires retention.
The business-content archive lasts twelve months from the effective end of the final paid subscription period and concerns genuinely anonymised content only, subject to earlier deletion and lawful holds. Retention of any personal data after processing ends requires its own specific lawful purpose, necessary duration and safeguards; the business-content archive does not authorise it. Neither archive nor limited exit handling maintains ordinary product access or authorises new charges.
The export window, operational deletion deadline, backup-expiry ceiling and any limited archival service must be completed before processing begins. A blank schedule does not permit indefinite retention or relieve the Provider of legal deletion duties.
Backups awaiting expiry must be isolated from ordinary use. If a recovery restores previously deleted data, deletion instructions must be reapplied before the data returns to ordinary processing. Subprocessors must be subject to equivalent exit obligations, and the Provider will provide a deletion confirmation on reasonable request once the applicable stages are complete.
If law requires retention, the Provider will identify the requirement to the Customer unless prohibited, isolate the necessary records, limit access and use, and delete them when the obligation ends. No business-data twelve-month rule is automatically applied to invoices, contract evidence or all security logs.
Liability, term and precedence
The DPA applies from the effective date identified in Schedule A for as long as the Provider or its subprocessors retain Customer Personal Data, including limited backup or legally required retention. Ending a subscription does not end these protections prematurely.
The Agreement’s liability allocation applies to claims between the parties, subject to mandatory law and prevailing transfer clauses. It does not restrict data-subject rights, regulatory powers, non-excludable obligations or the Provider’s responsibility for subprocessor performance.
This DPA prevails over conflicting general commercial provisions for its subject matter; valid mandatory transfer clauses prevail over inconsistent DPA wording. Amendments must be documented and may not silently expand purposes, data categories or recipients by editing a public page.
Schedule A | Parties and processing description
This schedule is to be completed per Order. The entries describing potential activities are a drafting framework, not confirmation that each business module is available.
| Item | Required entry |
|---|---|
| Customer legal identity and address | [COMPLETE] |
| Customer privacy and urgent security contacts | [COMPLETE; monitored channels required] |
| Provider | ALTAIR CONNECT - F.Z.E; corporate address above |
| Provider privacy contact | vegalysuae@gmail.com |
| Provider urgent incident contact and cover | [COMPLETE; do not assume ordinary mailbox is staffed 24/7] |
| Customer role | [Controller / processor for authorised upstream controller] |
| Provider role for Customer Personal Data | [Processor / subprocessor corresponding to the role above] |
| Upstream controller/authorisation if applicable | [COMPLETE or not applicable] |
| Order and approved service description | [IDENTIFY exact version and enabled functionality] |
| Subject matter | Provision of only the data-processing operations in the accepted service scope |
| Purposes | Customer-directed organisation and processing of authorised business data, only as required for the contracted workflow |
| Operations | [SELECT only delivered operations: collection/import, structured storage, retrieval, validation, task/review handling, authorised export, deletion] |
| Initial business-data scope | Genuinely anonymised datasets only; no personal or merely pseudonymised business records |
| Data subjects, if an actual processor activity is identified | [SPECIFY authorised staff/business contacts only where actually processed on Customer instructions; do not misclassify Provider-controller records] |
| Personal-data categories, if an actual processor activity is identified | [SPECIFY necessary fields and exact operation, or mark no processor activity after counsel review; no general authorisation for insurance/policyholder data] |
| Restricted categories | Excluded unless expressly approved under the restricted-data clause and a signed amendment |
| Frequency and volume | [CONTINUOUS/occasional as appropriate; expected records, users and storage] |
| Duration | Contracted processing term plus only approved exit, backup and lawful retention periods in Schedule D |
| Documented instructions and authorised contacts | [IDENTIFY] |
| Lawful-basis and sector restrictions confirmed by Customer | [COMPLETE; Provider must still assess its own duties] |
| Effective date | [ONLY after the completed package is approved and executed] |
Schedule B | Technical and organisational measures
Every row below is a proposed minimum control area requiring concrete implementation details, an accountable owner and verification evidence before release. No row is a claim of current deployment; an unmet control blocks the affected production processing rather than disappearing from the schedule.
| Control area | Required description and evidence |
|---|---|
| Access management | Roles, least privilege, privileged-account MFA, joiner/leaver process, access review interval; [IMPLEMENTATION/EVIDENCE] |
| Tenant separation | Server-side checks for records, files, jobs and exports; negative cross-tenant tests; [IMPLEMENTATION/EVIDENCE] |
| Authentication | Password hashing, token lifecycle/revocation, rate limiting and recovery controls; [IMPLEMENTATION/EVIDENCE] |
| Transmission and storage | Actual TLS configuration, storage/backup encryption and key-access responsibilities; no unsupported end-to-end claim; [IMPLEMENTATION/EVIDENCE] |
| Upload and export safety | File-type/size/processing limits, macro/code restrictions, malicious-input handling and authorised export controls; [IMPLEMENTATION/EVIDENCE] |
| Logging and monitoring | Minimum useful events, access restrictions, alert routing, no unnecessary content in logs, approved retention; [IMPLEMENTATION/EVIDENCE] |
| Vulnerability and change management | Dependency review, patch triage, controlled deployment and secret management; [IMPLEMENTATION/EVIDENCE] |
| Availability and recovery | Backup frequency, location, isolation, tested restore procedure and documented recovery objectives if agreed; [IMPLEMENTATION/EVIDENCE] |
| Incident response | Monitored escalation, ownership, twenty-four-hour notice capability and exercise record; [IMPLEMENTATION/EVIDENCE] |
| Deletion and restoration | Retention trigger, deletion jobs, subprocessor deletion, backup expiry and protection against resurrection; [IMPLEMENTATION/EVIDENCE] |
| Personnel and suppliers | Confidentiality, training, provider due diligence and approved contracts; [IMPLEMENTATION/EVIDENCE] |
| Development and support | Separation from production, fictitious test data, approved support access and content minimisation; [IMPLEMENTATION/EVIDENCE] |
Schedule C | Approved recipients, locations and transfer mechanisms
This schedule is intended for the contracting parties and counsel, not automatic publication as a server inventory. Necessary public privacy disclosures must nevertheless be made separately.
The initial application, database and customer files use the same Njalla VPS. This infrastructure description is not a completed subprocessor appointment, transfer instrument or independent backup commitment. Complete this schedule for any separately authorised processor activity before it begins.
Subprocessor register to complete
| Service category | Contracting legal entity | Data and purpose | Primary, backup and remote-access countries | Transfer mechanism and safeguards | Approval status |
|---|---|---|---|---|---|
| Application/database hosting | Njalla brand confirmed; [CONFIRM applicable contracting legal entity] | Application and database on the same VPS, confirmed by owner | Europe per owner; Sweden per provider's server page; remote access and provider-side copies [COMPLETE] | [COMPLETE applicable DPA and transfer assessment] | Hosting arrangement confirmed; contractual approval pending |
| Customer file storage | Same Njalla VPS; [CONFIRM applicable contracting legal entity] | Customer files, confirmed by owner; no separate object-storage service reported | Same primary VPS; remote access and provider-side copies [COMPLETE] | [COMPLETE] | Owner-confirmed arrangement; contractual approval pending |
| Backups/replication | No separate destination reported by owner | Owner states everything is on the same VPS; backup existence, schedule and restoration capability remain unverified | Any owner-held copies reported as on the same VPS; provider-side copies [COMPLETE] | [COMPLETE; do not represent same-VPS copies as independent disaster recovery] | Not evidence of an implemented backup service |
| Transactional email, if acting within this DPA | [CONFIRM Resend contracting entity and role] | [LIMIT data and exclude dataset contents unless specifically necessary] | [COMPLETE] | [COMPLETE] | To assess and approve |
| Other processor with Customer-content access | [IDENTIFY or state none after verification] | [COMPLETE] | [COMPLETE] | [COMPLETE] | To assess and approve |
Separate controller/administrative recipient register
Stripe payment processing, the Gmail business mailbox and other administrative services must be assessed separately for their legal entity, role, data categories, country information and safeguards. Their existence in the application does not make them authorised recipients of customer-uploaded files.
| Transfer assessment field | Required entry |
|---|---|
| Exporter/importer and their roles | [COMPLETE for each relevant flow] |
| Remote access by Provider personnel or third parties | [IDENTIFY actual access locations and restrictions] |
| Applicable transfer regime | [UAE / EU / UK / other, as actually applicable] |
| Adequacy or other mechanism | [IDENTIFY valid instrument; no default adequacy assertion] |
| SCC module, where legally suitable | [Module 2 or 3 as appropriate; other modules only if roles justify them] |
| Importer GDPR territorial assessment | [COMPLETE before assuming the 2021 clauses are suitable] |
| Executed instrument and annexes | [ATTACH; not supplied or executed by publication of this framework] |
| Transfer impact assessment and supplementary measures | [COMPLETE where required] |
| Authority, governing law and courts required by instrument | [COMPLETE; do not automatically substitute Ajman] |
| Review owner/date and reassessment triggers | [COMPLETE] |
Schedule D | Business-content retention and personal-data exit
The selected retention period is during the subscription and for twelve months after the subscription ends, for genuinely anonymised business datasets and their associated non-personal results. The trigger is the effective end of the final paid subscription period, not the date of the cancellation request. This business-content policy must be incorporated into the Order even where no personal-dataset processor activity is contracted.
Personal account/contact/billing records and any genuinely applicable processor activity require separate purpose-based rules. The archive must not be used to retain accidentally uploaded personal data as if it were authorised anonymous content.
| Decision | Selected rule or required entry |
|---|---|
| Selected business-content retention | During the subscription, then twelve months from the effective end of the final paid period, subject to earlier valid deletion and lawful holds |
| Data scope | Genuinely anonymised business datasets, versions and non-personal derived results; no merely pseudonymised records |
| Archive purpose | Limited customer exit/retrieval continuity; no marketing, AI training, ordinary product access extension or automatic new charges; operational retrieval method still to be completed |
| Active-service deletion requests | [PROCESS and maximum completion period, consistent with applicable law] |
| Warning before scheduled business-data expiry | [CHANNEL and timing] |
| Return/export request window | [DURATION, authenticated request process and responsible contact] |
| Export format and secure delivery | [AVAILABLE format, completeness and delivery method; do not promise unbuilt export tools] |
| Operational deletion after instruction/exit | [MAXIMUM period and dependencies] |
| Backup expiry | [ALIGN implementation with the twelve-month business-content deletion deadline and earlier deletion instructions; any residual period must be separately specified and approved, not silently added] |
| Derivatives, versions, caches and temporary files | [MAPPED deletion rules; no untracked copies] |
| Subprocessor deletion evidence | [METHOD and accountable owner] |
| Records retained under legal obligation | [DATA, specific basis, duration, restricted access; distinguish Provider-controller records] |
| Deletion confirmation | [APPROVED format, stages and issuing contact] |
Selecting a period does not prove that an uploaded dataset is anonymous or that any personal-data processing is lawful. Earlier valid deletion requests remain effective, and the twelve-month anonymous-content policy does not authorise an unnecessary twelve-month archive of personal data.
Execution block
This block is for the completed, approved release version only. Each party must receive the completed schedules and any separately executed transfer instrument before signing or accepting electronically.
| Party | Authorised name/title | Signature or recorded electronic acceptance | Date |
|---|---|---|---|
| ALTAIR CONNECT - F.Z.E | [COMPLETE] | [COMPLETE] | [COMPLETE] |
| Customer identified in Schedule A | [COMPLETE] | [COMPLETE] | [COMPLETE] |