Data Processing Agreement

Version 1.0.0 · Standard agreement for the Dyntora-hosted AZExecute service. The customer's electronic acceptance incorporates this agreement and Annexes A–D. This is Dyntora's agreement, not a claim of approval or certification by a supervisory authority.

1. Parties, scope and precedence

Controller: the organisation identified by legal name, registered address and company registration number in the electronic acceptance receipt. Its accepting administrator is the initial privacy contact; the customer may update this contact through info@azexecute.com.

Processor: Dyntora ApS, Danish CVR 46375599, VAT DK46375599, registered address Nørregårdsvej 232, 2610 Rødovre, Denmark, privacy and contractual contact info@azexecute.com.

This DPA forms part of the AZExecute subscription agreement identified in the electronic acceptance receipt. It applies to personal data processed by Dyntora on the customer's behalf as specified in Annex A. The customer determines the purposes and essential means of that processing; Dyntora acts only as processor for it. If the customer acts as processor for another controller, the customer must document that controller and its authority before instructing processing on that controller's behalf; Dyntora then acts as subprocessor within that authorised chain.

Processing by either party as an independent controller for its own lawful business purposes, such as supplier contract administration and statutory accounting, is outside this DPA and requires its own lawful basis and transparency. This does not permit Dyntora to reclassify Customer Data as independent-controller data to avoid these instructions.

Applicable data protection law means the GDPR and applicable Danish supplementary law. Mandatory law and any applicable mandatory international-transfer clauses prevail. This DPA prevails over conflicting commercial provisions concerning personal-data processing. Nothing restricts data subjects' rights or supervisory authorities' powers.

2. Instructions and controller obligations

Dyntora shall process personal data only on documented instructions from the customer, including instructions concerning international transfers, unless required by EU or Member State law. In that case Dyntora shall inform the customer of the legal requirement before processing unless prohibited on important public-interest grounds. The contract, annexes and authorised service configuration constitute the initial instructions. Additional instructions must be documented through the contacts in Annex D.

Dyntora shall immediately inform the customer if, in its opinion, an instruction infringes applicable data protection law and shall suspend the affected instruction while the parties resolve the issue. It shall not independently determine unrelated processing purposes, sell the data, use it for advertising, train general-purpose AI models on it or reuse it for unrelated product development.

The customer is responsible for lawful collection, a valid processing basis, notices to data subjects, the accuracy and scope of its instructions, and authorising access and integrations. The customer shall not submit special-category or criminal-offence data unless explicitly agreed with suitable safeguards in Annex A. Each party remains responsible for its own statutory obligations.

3. Confidentiality and access

Dyntora shall ensure that persons authorised to process the data are bound by confidentiality commitments or an appropriate statutory duty and receive appropriate data protection/security instruction. Access shall be limited to persons who need it to perform the agreed service, support or legal obligations. These duties continue after the person's engagement ends. Credentials and support access shall be managed as specified in Annex C.

4. Security

Dyntora shall implement and maintain measures appropriate to the risk under GDPR Article 32, considering the state of the art, implementation costs and the nature, scope, context and purposes of processing. The agreed technical and organisational measures are specified in Annex C and shall cover confidentiality, integrity, availability, resilience, restoration and regular evaluation as appropriate.

Measures may evolve without materially reducing the agreed level of protection. A material change affecting the customer's risk assessment shall be communicated in advance where practicable. Descriptions of a cloud provider's capabilities do not substitute for the controls actually configured for this service.

5. Subprocessors

The customer gives general written authorisation only for the subprocessors identified in Annex B. Before adding or replacing one, Dyntora shall provide the customer's privacy contact with the legal entity, service, locations, data categories and any transfer safeguards at least 30 days before the proposed use. The customer may object on reasonable data protection grounds during that period.

The parties shall seek a compliant alternative. Dyntora shall not introduce the objected-to subprocessor for that customer's data while the objection remains unresolved. If no reasonable solution is available, the customer may terminate the affected service before the change takes effect and receive a refund of prepaid fees for its unused period.

Dyntora shall impose substantially the same data protection obligations on each subprocessor by binding written agreement, including adequate security guarantees, and remains fully liable to the customer for the subprocessor's performance of those obligations. Dyntora shall maintain information about the relevant processing chain and provide information necessary for the customer to verify compliance. Confidential third-party terms may be redacted only insofar as this does not prevent meaningful verification.

6. International transfers

Processing locations, including hosting, backup and remote support, are limited to those agreed in Annex B. Hosting and backup countries are Denmark and Sweden. The provider support and onward-processing arrangements are described in Annex B; the hosting-country statement is not a guarantee that every provider support activity occurs in those two countries. Dyntora shall not transfer or permit access to personal data outside the EEA without documented customer instructions and a valid GDPR Chapter V mechanism. Where required, the parties shall execute the appropriate transfer clauses, assess the transfer and implement supplementary measures before it occurs. Onward transfers must meet the same requirements. This DPA alone is not a Chapter V transfer mechanism.

If safeguards cease to be valid or effective, Dyntora shall promptly notify the customer, suspend the affected transfer and cooperate on a lawful solution. It shall inform the customer of binding public-authority disclosure demands unless legally prohibited and disclose only what the law requires.

7. Assistance and individual rights

Taking account of the nature of processing, Dyntora shall assist the customer by appropriate technical and organisational measures, insofar as possible, with requests under GDPR Chapter III, including access, correction, deletion, restriction, portability and objection. Requests received directly shall be forwarded promptly to the customer. Dyntora shall not respond substantively on the customer's behalf without instructions unless legally required.

Taking account of the nature of processing and the information available to it, Dyntora shall assist the customer with Articles 32–36, including security, breach assessment and notifications, data protection impact assessments and prior consultation. Assistance shall be provided in time for the customer's applicable legal deadlines. Commercial discussions about exceptional assistance shall not delay mandatory assistance.

8. Personal data breaches

Dyntora shall notify the customer's incident contact without undue delay after becoming aware of a personal data breach affecting processing under this DPA. It shall not wait for a complete investigation. The notice shall provide available information about the breach, affected data and individuals, approximate numbers where known, likely consequences, containment/remediation and a contact for follow-up. Missing information shall follow in phases without undue further delay.

Dyntora shall contain, investigate and remediate the breach, preserve relevant evidence and cooperate with the customer's assessment and required notifications. The customer determines notifications to the authority and individuals for its controller processing; Dyntora retains any independent legal duties. The controller's possible 72-hour authority-notification deadline is not a permitted waiting period for Dyntora's notification.

9. Demonstrating compliance and audits

Dyntora shall make available all information necessary to demonstrate compliance with Article 28 and this DPA, and allow and contribute to audits, including inspections, by the customer or an auditor mandated by it. Documentary reviews and relevant independent assurance may be used first where adequate, but shall not replace a necessary inspection or limit a supervisory authority's powers.

Audits should use reasonable notice, confidentiality and safeguards for other customers' information. Urgent incidents, credible non-compliance and authority requirements may require shorter notice. Neither fees nor procedural arrangements may make the statutory audit right ineffective. Identified deficiencies shall be remedied promptly according to their risk, with corrective actions documented for the customer.

10. Return, deletion and duration

This DPA starts when validly accepted and applies for as long as Dyntora or its subprocessors retain personal data on the customer's behalf. At service end, at the customer's choice Dyntora shall return or delete all such personal data and delete existing copies, unless EU or Member State law requires storage. Export, active-data deletion and backup expiry follow Annex D. The customer may issue deletion instructions during the term through authorised controls or agreed contacts.

Retained backup data shall remain protected, inaccessible for ordinary service use and used only for recovery until its agreed expiry. Recovery uses a full backup restore rather than selective editing of individual records inside a backup. Previously effective deletion and restriction instructions remain binding. Restored data affected by those instructions must remain outside ordinary processing until the instructions can be respected; if that cannot be achieved, the affected restored data must not be reopened for ordinary use. This is a recovery condition, not a representation that automatic selective backup deletion exists. Any legally required retention shall be limited to the required data and period, disclosed unless prohibited, and isolated from other uses. Dyntora shall provide written confirmation of completed deletion on request, identifying any remaining legally required retention.

11. Non-compliance and signatures

If Dyntora cannot comply, it shall promptly notify the customer and cooperate to suspend affected processing until compliance is restored. The customer may terminate affected processing for material or persistent non-compliance; termination does not discharge return, deletion, confidentiality or statutory duties. Liability provisions in the commercial agreement shall not restrict obligations or rights that cannot lawfully be restricted, including GDPR Article 82 rights.

For Customer: the authorised administrator and acceptance time recorded in the electronic acceptance receipt.

Dyntora offers this DPA as part of its published subscription terms. Customer acceptance of that offer incorporates this DPA without a separate handwritten signature.

Annex A — Processing description and customer instructions

Subject matter and duration: the Dyntora-hosted AZExecute subscription for the organisation and tenant identified in the acceptance receipt, across the subscribed plans. Processing continues for the service term and the limited return/deletion period in Annex D. Self-hosted deployments require a separately agreed responsibility allocation.

Purpose: customer-directed identity/access administration and infrastructure automation, with necessary service operation, security and support. Customer Data is not provided for general reuse of employee information.

Operations: receipt, recording, storage, retrieval, display, permission checks, execution of authorised workflows, service logging, support, export and deletion. The actual operations depend on the customer's enabled features, permissions and instructions.

Data subjects: the customer's authorised users, administrators, employees and contractors, and other persons identified in customer-provided material insofar as necessary for authorised use.

Data categories: names, work email addresses, tenant/user identifiers, roles, access grants and user-linked activity or execution records. Customer-provided scripts, configuration, infrastructure identifiers, credentials and outputs are included insofar as they contain personal data. Technical request information and support material are included where processed to secure or support the service. The customer shall limit personal data in scripts, outputs and support submissions to what is necessary and shall not send passwords or private keys through ordinary support email.

Special-category and criminal-offence data are not authorised under the standard service. A required exception must be agreed with its purpose, lawful basis, scope and additional safeguards before processing.

Customer-selected integrations and destinations are those the customer configures and authorises. They do not become Dyntora's infrastructure subprocessors merely because the customer selects an integration. The customer is responsible for its contracts and lawful instructions for those destinations. Dyntora's own infrastructure provider is described in Annex B.

If the customer is itself a processor, it must hold the controller's authority to appoint Dyntora and provide the relevant controller identity and documented instructions. The customer remains Dyntora's instruction contact unless otherwise agreed. Acceptance does not establish authority for an undisclosed processing chain.

Annex B — Infrastructure provider, payment provider and locations

Infrastructure provider: Microsoft Azure (Microsoft group), supplying the hosting, database, storage and associated infrastructure needed to process the Customer Data in Annex A. Hosting and service backups are located in Denmark and Sweden.

Microsoft's applicable Products and Services Data Protection Addendum governs its processing for the Azure subscription. Dyntora shall maintain the identity of its contracting Microsoft entity and the applicable Microsoft processing-chain information and make this available for the customer's due diligence under clause 9. This authorisation is limited to supplying the agreed Azure infrastructure under those data protection obligations; it is not authorisation for unrelated Microsoft products or processing purposes.

Provider support and onward processing can involve Microsoft's affiliates and authorised subprocessors. Microsoft's published EU Data Boundary documentation describes exceptions, so the Danish/Swedish hosting commitment is not a promise that all provider access is confined to those countries. Dyntora remains responsible for documenting the applicable locations and safeguards, supplying the relevant information to the customer, and meeting clause 6 before permitting a transfer outside the EEA. A provider's general terms alone do not waive those obligations.

Dyntora has identified no other directly engaged infrastructure, mail, monitoring or support providers for the service. Addition or replacement of an infrastructure subprocessor follows the advance-notice and objection procedure in clause 5. A website update alone does not replace that notice.

Stripe is used for Dyntora's payment and billing relationship, not to host the customer's automation data. Dyntora acts as an independent controller for its own billing and statutory accounting purposes. Stripe may act as processor or independent controller depending on the activity, including its own fraud-prevention and legal-compliance processing. Stripe is therefore not automatically authorised here as an infrastructure subprocessor of the customer's automation data. Payment processing is separate from the hosting-country commitment above.

Provider references: - Microsoft Products and Services DPA: https://www.microsoft.com/licensing/docs/view/Microsoft-Products-and-Services-Data-Protection-Addendum-DPA - Microsoft EU Data Boundary and exceptions: https://learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-learn - Stripe DPA and processing roles: https://stripe.com/legal/dpa

These references supply provider information. Changes to a referenced website do not silently reduce Dyntora's obligations or replace the accepted version of this DPA.

Annex C — Technical and organisational obligations

The following measures are contractual obligations for the agreed processing. They do not represent a certification, an independent audit report or a guarantee that security incidents cannot occur. Dyntora shall maintain evidence of their implementation and provide relevant information under clause 9.

1. Identity and privileged access

Customer access uses Microsoft sign-in and the service's tenant and role permissions. The customer manages its own identities, authorisations and integration consents. Dyntora shall limit operator access to authorised persons and service identities, apply least privilege and multi-factor authentication to human privileged infrastructure access, and review and remove access when responsibilities change. Support access shall be limited to a documented service need and confidentiality obligations.

2. Tenant separation

The standard service uses shared infrastructure and a shared database, not a dedicated database per customer. Tenant-scoped data access and application permission checks provide logical separation. Administrative and background processing must preserve the tenant boundary. Dyntora shall test tenant isolation and authorisation when changing the relevant code and investigate any suspected cross-tenant access.

3. Data and secret protection

Dyntora shall use encrypted transport for service communications carrying personal data and encryption at rest for hosted databases and service backups. Credentials and cryptographic keys shall be access-controlled, kept out of public source code and public documents, and replaced or revoked when compromised. Keys needed for recovery must remain protected and available to authorised recovery personnel.

4. Infrastructure and change security

Dyntora shall restrict administrative/network access, maintain supported infrastructure and dependencies, assess security updates and vulnerabilities according to risk, and test relevant changes before release. Production data shall not be exposed in public development or test environments. Urgent security changes may be made with proportionate safeguards and subsequent review.

5. Logging and data minimisation

Dyntora shall limit logs to the information necessary for service operation, security and troubleshooting; restrict access; avoid recording secrets or unnecessary customer content; and apply the retention rules in Annex D. Customer-configured scripts and outputs must also be limited by the customer's instructions.

6. Backup and recovery

Service backups are located in Denmark and Sweden, protected from unauthorised access and subject to the maximum expiry period in Annex D. Recovery uses a full PostgreSQL backup restore rather than selective editing inside a backup. Dyntora shall test recovery and check data integrity, tenant boundaries and effective deletion/restriction instructions before resuming ordinary processing. Necessary instruction evidence must be retained separately from the database state being restored. No automatic selective backup deletion, fixed recovery time or recovery point is promised.

7. Incident response and personnel

Dyntora management is responsible for incident handling. The info@azexecute.com mailbox is monitored by two persons, without a promise of round-the-clock staffing. Dyntora shall maintain incident ownership and escalation, protect evidence, contain affected access, notify affected controllers without undue delay, provide phased updates and verify recovery. Persons with access to Customer Data shall receive confidentiality and relevant security instructions. Physical infrastructure protection is provided through the applicable Azure arrangements.

8. Evaluation and supplier oversight

Dyntora shall review these measures at least annually and after material changes or significant incidents, track corrective actions to completion and assess relevant provider assurances. This does not replace a necessary audit under clause 9. Controls and recovery instructions shall be tested proportionately to the service risks.

Annex D — Contacts, return and retention

Customer contact: the accepting administrator identified in the electronic receipt is the initial instruction and breach contact. The customer shall keep contact details current and notify info@azexecute.com of a replacement. Service instructions require the relevant tenant permissions; instructions received outside the service require proportionate verification of the sender's authority before disclosure or change.

Dyntora contact: info@azexecute.com, monitored by two persons. Security reports should identify the organisation, a safe reply address, the time and a brief description without unnecessary personal data or secrets. Dyntora management owns escalation and compliance with the notification duties in clause 8.

Return: an authorised tenant administrator may use Backup / Restore to create a tenant JSON export in the customer's configured Azure Blob Storage. Copies in the customer's storage remain under the customer's control. Where self-service export is unavailable or does not meet a required personal-data return request, Dyntora shall provide assistance through the contact above, agree a usable format and secure delivery, and act in time for applicable legal deadlines. Acceptance of revised terms shall not be a prerequisite for required data return.

Tenant deletion: the tenant-admin deletion control disables access immediately and schedules permanent cleanup after the recovery period shown in the application, normally seven days. Cleanup runs in the background; a request is not confirmation of completed physical erasure. Dyntora shall follow up failed cleanup and assist with a lawful instruction requiring a different deletion timetable. Where return is requested, Dyntora shall not destroy data before fulfilling the agreed return instruction.

Backup expiry: copies of actively deleted personal data shall expire no later than 90 calendar days after active-data deletion and may expire earlier. Until expiry, they remain protected and outside ordinary use. Clause 10 applies after any full restore. This is an upper retention limit, not a guarantee that an earlier recovery point remains available for 90 days.

Logs: routine user-linked operational and security logs shall be deleted or anonymised when no longer needed and no later than six months after recording. Relevant evidence may be isolated for a documented incident, rights request or applicable legal obligation, restricted to that purpose and reviewed for deletion when no longer necessary. This does not authorise general reuse or indefinite storage of Customer Data.

Legal retention: if EU or Member State law requires retaining data that would otherwise be deleted, Dyntora shall identify the applicable basis, affected data and period to the customer unless legally prohibited, restrict its use to that requirement and delete it when the requirement ends. Dyntora's independent-controller accounting records are governed separately by the privacy notice and applicable law.

Confirmation: on a verified customer request, Dyntora shall provide confirmation of completed deletion without undue delay, identifying any residual backups still within their expiry period and any legally required retention. Dyntora shall not label requested or failed cleanup as completed erasure.

These annexes are part of the version identified in the electronic acceptance receipt. Customer identity and acceptance evidence belong to the individual organisation and are not published with this standard text.