Data processing agreement framework
Pre-contract framework for future hosts, not an executed DPA. The legal supplier, host, actual subprocessors and safeguards must be completed and signed before production onboarding.
Parties and roles
For an independent host's own reservation records, the host generally determines the purpose and lawful basis and the Guestcord supplier acts on documented instructions. Data obtained through a platform API may instead have a different role allocation: Airbnb's API terms generally treat the software organisation as a separate controller unless partner-specific terms say otherwise. The actual agreements and data flows decide the roles; this framework does not override them.
Processing schedule
Subject matter: accommodation operations. Duration: the signed service period plus a documented export and deletion period. Purpose: listings, availability, reservations, guest communications, check-in, charges, reports and support. Data subjects: hosts, staff and guests. Data: identity and contact information, stay dates, messages, property access details, transaction references and support logs. Do not import card numbers or special-category data without a separately assessed lawful need and safeguards.
Instructions and confidentiality
The supplier processes host-controlled data only for the agreed services and documented instructions, unless legally obliged otherwise, and alerts the host to an unlawful instruction where permitted. Authorised staff are bound by confidentiality and receive access only for their role. The host handles notices, lawful bases, property permissions, disclosure of channel-specific information and instructions to the supplier.
Security and breaches
The production agreement must specify encryption in transit and at rest, access control, MFA, logging, backups, vulnerability handling, separation of host data, restoration testing and credential rotation, with evidence and owners. The supplier alerts the host without undue delay after learning of a personal-data breach and helps investigate, contain and document it. Any shorter channel-specific notification deadlines must be followed when applicable.
Subprocessors and transfers
Before activation, an annex must identify every actual infrastructure, mail, payment and support subprocessor, its purpose and data location; changes need prior notice and a contractual objection process. International transfers require a valid transfer mechanism and assessment where applicable. The current pilot has no verified public subprocessor register, so this framework is not ready to sign as-is.
Assistance, audit and end of service
The supplier assists with access, correction, deletion, portability, security assessments and regulator requests, subject to agreed scope. It makes compliance information available and permits reasonable audits. At the end of service, it returns or deletes host data on instruction, subject to documented legal retention, and confirms deletion of copies and backup expiry. Specific export format, retention windows, contacts and costs must be entered in the signed schedules.
Required annexes before signature
Annex A: identities, addresses, contacts and processing schedule. Annex B: actual technical and organisational measures. Annex C: named subprocessors, locations and transfer safeguards. Annex D: retention and deletion schedule, incident contacts and notification route. This public framework is informational and does not authorise production processing.