Data Processing Agreement (DPA)

Effective date: May 20, 2026
Last updated: May 20, 2026
Version: 1.0

This Data Processing Agreement ("DPA") forms part of the Terms of Service between you (the "Controller", typically a CMS operator who licensed EasyGSM CMS from us) and Luis Enrique Moya Rozas (the "Processor", "we", "us", "our") in connection with the Portal at https://easygsmpro.com.

This DPA is intended to comply with Article 28 GDPR and equivalent provisions of the UK GDPR, the Mexican LFPDPPP, the Brazilian LGPD, and the California CCPA/CPRA.

1. Definitions

"Personal Data" has the meaning set out in Article 4(1) GDPR — any information relating to an identified or identifiable natural person.
"Data Subjects" means the end-users who use a CMS instance operated by the Controller.
"Processing", "Controller", and "Processor" have the meanings of Article 4 GDPR.
"Sub-processor" means a third party engaged by us to process Personal Data on behalf of the Controller. See /legal/subprocessors.

2. Subject matter and duration

The subject of the processing is the limited handling of Personal Data of the Controller's end-users by the Processor, strictly to:

Receive and store encrypted database backups transmitted from the Controller's CMS instance to the Portal for disaster-recovery purposes.
Receive and store (when expressly enabled by the Controller) network operation logs containing request/response bodies exchanged between the Controller's CMS and upstream service providers.
Receive license heartbeats and anti-tampering security events (which do not contain Personal Data of end-users).

The DPA applies for the duration of the Controller's active license and continues to apply after termination for backup retention as described in Section 9.

3. Nature and purpose of processing

We process Personal Data only on documented instructions from the Controller (Art. 28(3)(a) GDPR). The Controller's instructions are documented through: (a) these Terms and DPA; (b) the configuration settings the Controller chooses in the CMS (e.g., enabling/disabling backup uploads, enabling/disabling network operation logs); (c) any written instructions sent to luisenriquemr96@gmail.com.

4. Types of Personal Data and categories of Data Subjects

See Annex 1.

5. Obligations of the Processor

We undertake to:

Process Personal Data only on documented instructions of the Controller, including with regard to transfers to a third country (unless required to do so by Mexican or EU law; in such case we will inform the Controller unless prohibited by law).
Ensure that personnel authorized to process Personal Data are bound by confidentiality (in our case, sole-proprietor confidentiality undertaking).
Implement the technical and organizational measures set out in Annex 2 (Art. 32 GDPR).
Engage sub-processors only with the Controller's general written authorization, which is granted by acceptance of this DPA. We will notify the Controller of any intended changes concerning the addition or replacement of sub-processors with at least 30 days advance notice (via email and the /legal/subprocessors page), giving the Controller the opportunity to object.
Assist the Controller, by appropriate technical and organizational measures, in responding to requests from Data Subjects exercising their rights under Chapter III GDPR.
Assist the Controller in ensuring compliance with the obligations pursuant to Articles 32–36 GDPR (security, breach notification, DPIA).
Notify the Controller without undue delay (target: within 24 hours) after becoming aware of a Personal Data breach, providing the information required by Article 33(3) GDPR insofar as it is available.
At the choice of the Controller, delete or return all Personal Data after the end of the provision of services, and delete existing copies, unless storage is required by law.
Make available to the Controller all information necessary to demonstrate compliance with Article 28 GDPR and allow for and contribute to audits, including inspections, conducted by the Controller or an independent auditor mandated by the Controller. Audits require 30 days prior written notice and may not occur more than once per year unless compelled by a competent supervisory authority.

6. International transfers

Portal data is stored in Germany (Hetzner Online GmbH, Nuremberg), inside the European Union. The natural person operating the Portal resides in Mexico and accesses the Portal remotely. Where this remote access constitutes a transfer to a third country within the meaning of Chapter V GDPR, it relies on Article 49(1)(b) GDPR (necessary for the performance of a contract between the Data Subject and the Controller, with the Processor as sub-processor).

Transfers to non-EU sub-processors listed in /legal/subprocessors rely on the appropriate safeguards indicated for each (Standard Contractual Clauses, EU-US Data Privacy Framework, or applicable adequacy decisions).

7. Liability

Each party's liability under this DPA is subject to the limitation of liability in our Terms of Service, except that nothing in this DPA excludes liability that cannot be excluded under applicable data protection law (including administrative fines imposed by a supervisory authority).

8. Conflict

In case of conflict between this DPA and the Terms of Service, this DPA prevails for matters of data protection.

9. Term, termination, and data return

This DPA enters into force on the effective date and remains in force as long as the Controller's license is active. Upon termination:

Backup uploads to the Portal cease automatically when the license is revoked or expired.
Existing backups on the Portal are retained for up to 90 days after termination, then permanently deleted, unless the Controller explicitly requests earlier deletion in writing.
Network operation logs (if enabled) are retained for up to 180 days after termination, then permanently deleted.
Anonymized audit logs may be retained longer for legal-compliance and security purposes (up to 7 years).

10. Notices

All notices under this DPA shall be sent to luisenriquemr96@gmail.com for the Processor, and to the email associated with the Controller's account for the Controller.

Annex 1 — Data categories and Data Subjects

Categories of Data Subjects

End-users (natural persons) who hold an account in the Controller's CMS instance.
Customers of the Controller who interact with the CMS via the App.

Categories of Personal Data processed

Category	Examples	Channel to Portal
Identifying data	Username, email, full name, phone, Telegram chat ID	Backups (plain text inside DB dump)
Authentication data	Password hashes (bcrypt), TOTP secrets (Fernet-encrypted), recovery codes (bcrypt)	Backups — credentials remain encrypted/hashed; not readable
Order data	Device IMEIs, model, serial, custom fields, unlock codes, IP addresses at time of order, file uploads (metadata)	Backups (plain text); optional network logs
Financial data	Wallet balance, transactions, payment metadata (no card data)	Backups (plain text)
Technical data	Machine identifier, hostname, public IP of CMS, OS info, CMS version	License heartbeats only (no end-user PII)

Special categories of Personal Data (Art. 9 GDPR)

We do not knowingly process special categories of data (health, biometric, racial, religious, political, sexual orientation, etc.). The Controller undertakes not to upload such data to the CMS.

Annex 2 — Technical and Organizational Measures (TOMs)

Confidentiality

Access to the Portal infrastructure is restricted to the natural person operating it, via authenticated SSH and admin panel with 2FA.
Operator confidentiality is intrinsic to a sole-proprietor model.

Integrity

Backups transmitted from CMS to Portal use AES-256-GCM authenticated encryption over per-installation keys established at CMS bootstrap.
HMAC integrity verification per backup payload.
Append-only hash-chained audit log of all administrative operations.

Availability and resilience

Portal hosted on Hetzner ISO 27001 certified data center (Nuremberg, Germany).
Daily off-site backups of Portal data.
TLS-only public endpoints (HSTS, strong cipher suites).

Pseudonymization and encryption (Art. 32(1)(a))

Sensitive credentials in CMS backups are stored as bcrypt hashes or Fernet-encrypted with per-instance keys not held by the Processor — therefore unreadable by us even with raw backup access.
TLS in transit for all Portal channels.

Ability to restore (Art. 32(1)(b))

Backups can be downloaded by the Controller from the Portal admin panel for self-service restore.
Backup integrity verified at restore time via HMAC.

Regular testing (Art. 32(1)(d))

Pre-deployment review of changes to security-critical code paths (license validation, backup encryption, anti-tampering).
Periodic review of access logs and security events.

Incident response

Documented internal breach-response procedure: detection, containment, triage, supervisory authority notification within 72h (Art. 33), Data Subject notification when high risk (Art. 34).
Breach Response runbook published at https://easygsmpro.com/docs/BREACH_RESPONSE.md with notification templates and a 72-hour decision flow.

Built-in Data Subject rights tooling (Art. 12-22) we ship in the CMS and App

The CMS software we license to the Controller includes out-of-the-box mechanisms to fulfil most controller obligations without custom development:

Art. 7 (Consent) — registration form requires explicit consent to Privacy Policy and Terms of Service. Consent timestamps and version numbers are persisted on the user record (accepted_privacy_at, accepted_privacy_version, accepted_terms_at, accepted_terms_version) and recorded immutably in the append-only audit log (user_register_consent event) with IP and user agent. Marketing opt-in is captured separately and is off by default.
Art. 8 (Children) — age confirmation checkbox is mandatory at registration; optional birth-year input is validated server-side against the EU strict minimum of 16 years.
Art. 15 + 20 (Access & portability) — self-service JSON export of all data the CMS holds about the data subject. Web endpoint GET /user/profile/data-export; mobile GET /mobile/v1/account/export. Includes profile, orders, transactions, payment requests, support tickets and the data subject's own activity log. Excludes secret fields (password hash, TOTP secret, etc.).
Art. 16 (Rectification) — self-service update of name, phone, language, timezone, currency from web and mobile.
Art. 17 (Erasure) — self-service account deletion with password (and 2FA when enabled) confirmation and explicit phrase confirmation. Two execution modes:
- Hard delete — when no financial-ledger integrity constraint (CreditTransfer) applies. CASCADE deletes orders, transactions, payment requests, sessions, notifications, support tickets, API keys.
- In-place anonymization — when CreditTransfer rows pin the user row via RESTRICT foreign keys. PII fields are overwritten with placeholders; the record is preserved only for ledger continuity. JWT tokens are invalidated via token_version bump; API keys are deleted; orphan files on disk (payment proofs, file-order uploads) are purged; orphan PII in SecurityEvent and AdminNotification is redacted.
Art. 18 (Restriction) — self-service "freeze" endpoint suspends processing reversibly without deleting data.
Art. 5(2) and Art. 30 (Accountability) — tamper-evident hash-chained append-only audit log for consent, erasure, security events. Configurable retention with 7-year defensible default. Records of Processing Activities template published at https://easygsmpro.com/docs/RoPA.md.
ePrivacy (Cookies) — cookie consent banner included; CMS uses only strictly necessary cookies (session JWT, CSRF, locale).
Admin-editable Privacy & Terms — Markdown editor under /admin/settings/legal; rendered server-side with XSS-safe sanitization (bleach + linkify) and Unicode-bidi protection against URL spoofing.
Rate limiting on Data-Subject endpoints — strict throttle (default 3/min per IP) on erase, freeze, data-export to deter abuse of self-service rights by attackers holding stolen credentials.
Privacy-by-design — no third-party analytics, advertising or tracking SDKs in the App or CMS; network operation logs to the Portal are off by default; user-data export excludes secret material; consent and erasure events are forced through a strict audit path that aborts if logging fails.

These mechanisms are part of the CMS license. The Controller must configure their identity, jurisdiction and effective date in /admin/settings/legal; once configured, all of the above operate automatically. We commit to keeping these mechanisms updated as the law evolves and to publish material changes through the Portal.

← Back to home