DPA

Data Processing Agreement

This Data Processing Agreement summary sets out the processor obligations applicable when Zmirf processes personal data on behalf of a customer.

Last updated: March 18, 2026

INSTRUCTION

Controller Authority

Customer acts as controller and instructs Zmirf as processor for the covered services.

SECURITY

Technical Measures

Appropriate technical and organizational controls are applied based on risk and service type.

SUBPROCESSORS

Vendor Chain

Subprocessors may be used under contractual protections and data transfer safeguards where needed.

1. Processing Scope

  • Subject matter: hosting, platform operations, support, and related managed services.
  • Duration: as long as services are active and data retention obligations apply.
  • Data types: customer data hosted or transmitted in service environments.
  • Data subjects: customer users, staff, and end-users defined by controller use case.

2. Core Processor Commitments

  • Process data only on documented controller instructions unless law requires otherwise.
  • Ensure confidentiality obligations for authorized personnel.
  • Assist with data subject rights and incident response proportional to service scope.
  • Delete or return personal data at termination, subject to legal retention duties.

Practical DPA implementation for customer workloads

A DPA is effective when controller instructions, technical controls, and operational procedures are aligned. Customers should define what personal data is processed, who can access it, and which retention windows apply. This improves accountability across hosting, support, and managed service interactions.

For platforms involving domains, payments, and custom system modules, data flows can cross multiple services. Documenting these flows helps clarify processor obligations, subprocessor usage, and incident response responsibilities. Clear documentation also simplifies audits and compliance reviews over time.

  • Define controller instructions for each processing activity.
  • Maintain an internal record of data categories and systems.
  • Review subprocessor scope and safeguards on a regular cycle.
  • Test response readiness for access requests and incidents.

FAQ

DPA FAQ

Who is controller and who is processor in this setup?

In covered service scenarios, the customer acts as controller and Zmirf acts as processor.

How should teams operationalize this DPA?

Define processing scope, data categories, and access controls before production use.

For complex systems, maintain internal records for instruction handling, subprocessor dependencies, and incident workflows. This keeps compliance actions auditable and reduces risk during security reviews or legal requests.

When should a customer request DPA clarification?

Request clarification before onboarding new data types or launching major system changes.

Early clarification helps align controller instructions, retention scope, and access responsibilities before production impact. This reduces compliance risk and avoids rework during audits or incident handling.