Data Processing Agreement
The draft framework for processing personal data on a customer’s behalf, including instructions, safeguards, requests, and subprocessors.
This policy is a draft that requires review and approval by qualified legal counsel before public launch. It is provided for general information only and does not constitute legal advice. RYHA Technologies may update it from time to time, and only a formally approved published version should be treated as binding.
Status, Roles, Scope, and Instructions
This page is a draft DPA framework, not an executed data-processing agreement. The final agreement must identify the parties and define controller and data processor roles for each data category, documented instructions, processing purpose and duration, data subjects, categories of personal data, confidentiality duties, applicable data-protection law, and the order of precedence with customer terms. RYHA should process customer personal data only on documented lawful instructions, including approved transfers, unless applicable law requires otherwise. The final terms must address unlawful instructions, customer responsibilities, return and deletion, legal retention, audit information, liability, and termination.
Security, Incidents, and Compliance Assistance
The repository implements tenant authorization tests, credential encryption, signed service identity, redacted logging helpers, audit records, and privacy workflows. The final technical and organizational measures annex must be based on the deployed environment, access review, backup configuration, restore evidence, incident drill, penetration test, provider contracts, and retained production evidence. RYHA’s approved obligations should address personnel confidentiality, risk-based safeguards, incident assessment, data-subject requests, impact assessments, regulator consultations, and customer compliance information. If the GDPR applies and RYHA is acting as a processor, Article 33 requires notice to the relevant controller without undue delay after RYHA becomes aware of a personal-data breach. If RYHA is acting as controller, supervisory-authority timing is measured from awareness and is, where feasible, no later than 72 hours after awareness unless the breach is unlikely to create a risk to people’s rights and freedoms; reasons accompany a delayed notification. These role-specific rules do not create a universal customer-notice deadline or prove that the GDPR applies to every incident. Actual timing follows applicable law, an executed DPA, incident facts, and legal guidance.
Subprocessors and International Transfers
The final annex and Subprocessor Notice must list the actual identity, cloud, payment, communications, observability, storage, workflow, support, and AI subprocessors used by the deployed service, including purpose, data categories, processing region, transfer mechanism, and change-notification process. The current code evidences limited roles for Clerk authentication, Supabase operational form storage, Cloudflare frontend hosting and sampled security telemetry, and Dodo Payments hosted checkout. Those integrations do not by themselves prove an executed DPA, approved transfer mechanism, processing region, or complete production register. Cross-border transfer language and any contractual clauses must match the actual parties, regions, onward transfers, risk assessment, and approved legal mechanism. The executed DPA must define subprocessor flow-down obligations, notice, objection handling, replacement options, and responsibility.
Requests, Return, Deletion, Audits, and Contact
The product includes intake, export, consent, and deletion mechanisms intended to support rights requests, but operator verification, exceptions, response deadlines, processor acknowledgements, and escalation must be exercised in production. The final DPA must define assistance, information and audit procedures, frequency and confidentiality limits, deletion certification, backup handling, and legal-retention exceptions. DPA questions can be sent to privacy@ryha.dev.