Data processing agreement

This agreement applies when Creative Parrots BV processes personal data on behalf of a customer. It is required by article 28 of the General Data Protection Regulation.

No signature is needed. This agreement is incorporated into the Terms of Service by reference and takes effect automatically when the customer accepts those terms. Customers who need a signed copy for their own records can request one at hello@wyroo.io.

Parties and roles

The customer is the controller. The customer decides what personal data goes into its workspace and why.

Creative Parrots BV, registered at Ruwbeemd 9, 3755WD Eemnes, NL, company registration 80474624, is the processor. We process personal data only on the customer's documented instructions.

Using the service is a documented instruction to process personal data as needed to deliver it. Additional instructions must be agreed in writing.

1. Subject matter and duration

We process personal data so that we can provide the Wyroo service: project management for building and interior projects, including boards, files, comments, meetings, roles, digests and client updates.

This agreement runs for as long as the customer's agreement with us lasts, and ends when all personal data has been returned or deleted in accordance with clause 8.

2. Nature and purpose of the processing

Storing, organising, retrieving, transmitting, displaying, backing up and deleting personal data, and making it available to the people the customer has given access to. Where the customer uses AI features, this includes sending the submitted content to an AI subprocessor to generate a draft.

We do not process personal data for our own purposes. We do not sell it. We do not use customer content to train AI models, and our AI subprocessors do not train on content submitted through their APIs.

3. Types of personal data

Determined by the customer. In practice this typically includes:

• names, email addresses, telephone numbers and job or trade roles of the customer's staff, subcontractors, suppliers and clients
• the contact details of people who hold a role in a project, including people without a Wyroo account who receive email digests
• content written by those people: comments, mentions, meeting notes, annotations, card descriptions and client updates
• files and drawings uploaded to a project, which may contain personal data such as names on drawings or in documents
• metadata about activity: who did what and when

4. Categories of data subjects

The customer's employees and contractors, subcontractors and suppliers and their staff, the customer's own clients, and any other person whose data the customer chooses to put into its workspace.

Special categories. Wyroo is not designed for special categories of personal data as defined in article 9 GDPR, nor for personal data about criminal convictions. The customer agrees not to put such data into the service.

5. Our obligations

We will:

• process personal data only on the customer's documented instructions, including for transfers to third countries, unless required otherwise by law, in which case we inform the customer first unless the law forbids it
• tell the customer if we believe an instruction breaches data protection law
• ensure that everyone authorised to process personal data is bound by confidentiality
• apply the technical and organisational measures set out in Annex 2
• assist the customer, taking into account the nature of the processing, with requests from data subjects, with data protection impact assessments, and with prior consultation of a supervisory authority
• make available the information needed to demonstrate compliance with article 28, and allow audits as set out in clause 9

6. Subprocessors

The customer gives general authorisation for the subprocessors listed in Annex 1.

We may add or replace a subprocessor. We will inform the customer at least 30 days in advance by email or in the application. The customer may object on reasonable data protection grounds within 14 days of that notice. If we cannot resolve the objection, the customer may terminate the affected part of the service and receive a pro rata refund of prepaid fees.

We impose the same data protection obligations on every subprocessor, and we remain fully liable to the customer for their performance.

7. Personal data breaches

If we become aware of a personal data breach affecting personal data we process for the customer, we notify the customer without undue delay and at the latest within 48 hours of becoming aware.

Our notification describes, as far as known, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. We provide further information as it becomes available, and we assist the customer with its own notification duties towards the supervisory authority and data subjects.

Notifying the supervisory authority and data subjects is the customer's responsibility as controller, unless the law says otherwise.

8. Return and deletion

At the end of the agreement, and during the period before deletion, the customer may ask us in writing for a copy of its data, which we provide in a structured, commonly used and machine readable format.

At the end of the agreement, the customer closes the workspace as set out in the Terms of Service. We keep the personal data for 30 days after closure so the customer can still ask for a copy or change their mind, then delete it from our live systems and confirm the deletion in writing. Copies inside automated database backups expire within seven days of that deletion, uploaded files fall out of file storage within thirty days, and any manual snapshot holding the data is deleted with the request. On the customer's written request we delete sooner.

We may keep personal data for longer where the law requires it, for example invoices for tax purposes. In that case we stop all other processing.

On request we confirm deletion in writing.

9. Audits

On reasonable notice and no more than once a year, unless a supervisory authority or a personal data breach makes more frequent checks necessary, the customer may audit our compliance with this agreement.

We first offer available documentation, such as our security description and the third party reports we hold, including the SOC 2 Type 2 attestation of our hosting provider. If the customer needs more, an audit takes place during business hours, without unreasonable disruption, subject to confidentiality, and at the customer's cost unless the audit finds material non compliance.

10. International transfers

Hosting, database and file storage are in the European Union, in Amazon's Frankfurt region (eu-central-1). Requests reach the service through a global edge network before they arrive at that region, so connection data such as IP addresses is handled at the edge location nearest the visitor. Some subprocessors process personal data outside the European Economic Area, as marked in Annex 1. Those transfers take place under the European Commission's standard contractual clauses, together with supplementary measures such as encryption in transit, and where relevant under an adequacy decision.

11. Liability

Liability under this agreement is subject to the limitations in the Terms of Service, to the extent the law allows. Nothing in this agreement limits liability that cannot be limited by law, including liability towards data subjects under article 82 GDPR.

12. Order of precedence

If this agreement conflicts with the Terms of Service on the processing of personal data, this agreement prevails. If it conflicts with the standard contractual clauses, the clauses prevail.

13. Applicable law

This agreement is governed by the law of the Netherlands. Disputes are submitted to the competent court of the Rechtbank Midden-Nederland, Utrecht.

Annex 1: Subprocessors

Where a subprocessor is established outside the European Economic Area, the transfer takes place under an adequacy decision where one covers that provider, and otherwise under the European Commission's standard contractual clauses. We review the mechanism for each subprocessor and update this annex when it changes.

Browser push is the one entry with no subprocessor relationship to describe. When someone switches on browser notifications, their own browser decides which push service delivers them, and the notification title and body travel through it. We have no agreement with those providers and cannot choose a different one. Anyone who would rather not use them can leave browser notifications off and receive email instead.

Annex 2: Technical and organisational measures

These are measures in place today. They may be improved over time, but not weakened.

Access control. Data is scoped per company. Within a company, access is scoped per project, so a guest sees only the project they were added to. Role based permissions govern what a member can do. Actions taken by the processor's own personnel, including support access, company suspension, billing overrides and feature changes, are recorded in an append only audit log capturing actor, target, time and IP address. File and board activity inside a customer workspace is recorded in separate per project activity trails.

Authentication. Passwords are hashed with bcrypt. Two factor authentication and passkeys (WebAuthn) are available on every account. Sign in attempts are rate limited. New accounts must verify their email address.

Encryption in transit. All traffic is encrypted with TLS. Certificates are issued and renewed automatically by the hosting platform. Every response carries HTTP Strict Transport Security, so a browser that has reached the service once will not fall back to an unencrypted connection. Requests arrive through the platform's edge network; the application is not directly exposed to the public internet.

Encryption at rest. Uploaded files are encrypted at rest by Amazon S3. Server side encryption with S3 managed keys is the base level of encryption on every bucket and is applied to every object automatically: each object is encrypted under its own key with 256 bit AES, and that key is itself encrypted with a root key that Amazon rotates. The application, the database and the database backups are encrypted at rest by the hosting platform by default.

File access. Documents, drawings and project photographs are stored in a bucket that blocks public access, and are reachable only through a signed link that expires after five minutes and is issued after the application has authorised the request. A stored file that cannot be matched to a known category is treated as confidential, so a misfiled object cannot become readable by accident. Only non confidential display images, such as profile pictures, are held in the bucket for public assets. Where the customer deliberately creates a share link for someone outside the project, the customer chooses how long it lasts.

Segregation. Every company's data is logically separated in the application. Separation is enforced by authorisation policies and company scoped queries, and is covered by an automated multi tenant isolation test suite that runs on every change.

Availability. Hosting on managed infrastructure. The database is backed up automatically once a day, during a three hour window, and snapshots can also be taken manually at any time. Backups are encrypted at rest. Automated snapshots are retained for seven days and then expire on their own. A manual snapshot does not expire, so any manual snapshot holding a customer's data is deleted as part of a deletion request. A restore creates a new database cluster alongside the original rather than overwriting it, so a recovery never destroys the current data.

File storage. Uploaded files are versioned. If a file is overwritten or deleted, the previous copy is retained for thirty days and then permanently removed, so an accidental deletion can be undone inside that window and a customer's data does not linger beyond it. Project files additionally sit in a recoverable trash inside the application for ninety days before they are destroyed. Deletion on request removes a file's whole version history rather than only its current copy.

Platform. Our infrastructure provider holds a SOC 2 Type 2 attestation covering security, confidentiality and availability, and publishes the current report through its trust centre. Traffic passes an edge network that filters common injection, authentication and data exposure attacks using the OWASP core ruleset, absorbs denial of service traffic, and rate limits by source address before a request reaches the application. Runtime security patches are applied by the platform on its own schedule, tenants are isolated from one another at the cluster level, and our application dependencies are checked against published vulnerability advisories on every deployment.

Organisational. Access to production data is limited to personnel who need it. Everyone with access is bound by confidentiality.

This annex describes the measures in place at the version and date shown at the top of this agreement. Measures may be improved over time, but not weakened, and the annex is updated when they change.