This agreement governs personal data that Valvasor Capital Ltd processes on behalf of a customer using Fuo. It forms part of the Terms of Service and takes effect when the customer accepts them.
It is written to satisfy Article 28 of the UK GDPR and Article 28 of the EU GDPR, both of which apply to us.
| Processor | Valvasor Capital Ltd, company number 16505609, 71-75 Shelton Street, Covent Garden, London WC2H 9JQ, United Kingdom |
| Controller | the customer named in the workspace |
| Contact | privacy@fuo.app |
1. Words used here
Data protection law means the UK GDPR and the Data Protection Act 2018, Regulation (EU) 2016/679, and any other law about personal data that applies to either of us — including Slovenian implementing law where the customer is established in Slovenia.
Controller, processor, data subject, personal data, processing, personal data breach and supervisory authority have the meanings that law gives them.
Customer Personal Data means personal data that we process on the customer's behalf through Fuo. Annex 1 says exactly what it is.
Sub-processor means anyone we engage to process Customer Personal Data. Annex 3 lists them.
SCCs means the Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914. UK Addendum means the ICO's International Data Transfer Addendum to those clauses, version B1.0.
2. Who is what
The customer is the controller of Customer Personal Data. We are the processor.
The customer decides why registrants' data is collected and what happens to it. We hold it because the customer's use of the product puts it there.
We are an independent controller for a narrow set of data that is not Customer Personal Data at all: the accounts of the customer's own staff, the record of how they use the product, service metering, security records, and the billing relationship. The Privacy Policy covers that, and this agreement does not.
Where we determine any purpose or means of processing Customer Personal Data on our own account, we become a controller for that processing and take on the obligations that come with it. We do not intend to, and Annex 1 is written so it does not happen by accident.
3. The customer's obligations
The customer:
- must have a lawful basis for every category of Customer Personal Data it collects through Fuo, and be able to demonstrate it;
- must give data subjects the information Articles 13 and 14 require — at the moment of collection, which for a registration form means on the form itself. The product gives a place to put a privacy notice URL, and the customer must supply one;
- must, where its basis is consent, obtain consent that is freely given, specific, informed and unambiguous, keep the evidence, and make withdrawal as easy as giving it;
- must not upload or collect special category data (Article 9) or criminal offence data (Article 10) through Fuo. The product is not built for it, Annex 1 does not contemplate it, and the safeguards such data requires are not in place;
- must not invite a person on stage without their agreement to be recorded, and must not circumvent the consent step the product presents;
- must ensure its own instructions to us do not put us in breach of data protection law;
- is responsible for the accuracy of what it uploads and for the conduct of the people it gives access to, including its distributors.
The customer's own security. We secure the platform (Annex 2); the customer is responsible for how it uses it: choosing who in its organisation gets access, keeping their sign-in details and the devices they use secure, and keeping its own exports of anything it cannot afford to lose. The customer confirms it has looked at the measures in Annex 2 and judges them appropriate to the risk of the data it puts into Fuo.
The customer's instructions to us are: this agreement, the Terms of Service, and the customer's ordinary use of the product's own features. Anything beyond that must be in writing, and we may charge for it where it is not something the product already does.
4. Our obligations
We will:
- process only on the customer's documented instructions, including for transfers, and tell the customer if we believe an instruction breaches data protection law (Article 28(3)(h));
- not use Customer Personal Data for our own purposes. We will not market to it, profile it, sell it, share it, or use it to train any machine-learning model — ours or anyone else's;
- not combine one customer's data with another's. Isolation is enforced in the database queries themselves, and is tested;
- keep it confidential. Everyone with access is bound by confidentiality obligations, and access is limited to those who need it to run the service;
- secure it in accordance with Article 32, as set out in Annex 2, and account for the risk when we change anything material;
- engage sub-processors only as section 6 allows;
- help the customer respond to data subjects, as section 7 sets out;
- help the customer with Articles 32 to 36 — security, breach notification, impact assessments and prior consultation — taking into account what we know and what a processor is able to know;
- tell the customer about a breach without undue delay, as section 8 sets out;
- delete or return the data at the end, as section 10 sets out;
- make available what the customer needs to show we comply, and allow audits as section 9 sets out.
5. Where the data lives
Customer Personal Data in the database is held on servers in Frankfurt, Germany.
Uploaded images are held on the same server. Recordings are held on Cloudflare's network and delivered from its edge. Live audio and video passes through LiveKit, in the region nearest the participants, while a broadcast is running. Email is sent through Resend, which operates from the United States.
Annex 3 states, supplier by supplier, what leaves the EEA and what covers it.
6. Sub-processors
The customer gives general authorisation for us to engage sub-processors. Annex 3 is the list at the date of this version, and it is the authorised list.
Every sub-processor is engaged under a written contract imposing obligations no less protective than these, and we remain fully liable to the customer for what they do.
Before adding or replacing one, we will give the customer 30 days' notice by email to the workspace's address. The customer may object on reasonable data-protection grounds within that period. We will then work with the customer in good faith to resolve it. If we cannot, the customer may, as its sole remedy for the objection, terminate the affected part of the service, and we will refund any period paid for and not used. Continuing after 30 days is acceptance.
Where a change is needed urgently to keep the service running or secure, we may make it sooner and tell the customer as soon as we can; the right to object survives.
7. Data subjects' rights
The product is built so the customer can answer most requests without us. From the workspace the customer can see, correct, export and delete registrants, their attendance, their chat and their recordings.
Where a request reaches us instead, we will not answer it ourselves. We will pass it to the customer without undue delay, and help the customer answer it — including by locating, exporting, correcting, restricting or deleting data the customer cannot reach on its own.
This help is included at no charge for a reasonable volume. Where a request is repetitive or requires engineering work well beyond the ordinary, we may charge our reasonable costs, after telling the customer what they will be.
8. Personal data breaches
If we become aware of a personal data breach affecting Customer Personal Data, we will tell the customer without undue delay, and in any event within 48 hours of becoming aware.
A breach means data actually lost, altered, disclosed or accessed without authority. It does not include attempts that fail and compromise nothing — failed sign-ins, pings, port scans, denial-of-service traffic and the like, which every service on the internet sees daily.
We will include what we know: what happened, which categories and roughly how many data subjects and records, the likely consequences, what we have done and what we plan to do, and a contact who can answer questions. Where we do not have all of it at once, we will send what we have and follow up.
Notifying the supervisory authority and the data subjects is the customer's decision — the customer is the controller, and the 72-hour clock in Article 33 is the customer's. We will give the customer what it needs to make that decision and to make the notification. Where a notification the customer makes will name us or describe our part, the customer will, where the law allows, show it to us first and consider our corrections about our own role.
Telling the customer about a breach, and helping with it, is not an admission of fault or liability.
We will not make a public statement identifying the customer's breach without the customer's agreement, unless the law requires it of us.
9. Audit
We will make available the information reasonably needed to show we meet Article 28 — including our security documentation, our sub-processor list, and answers to a reasonable security questionnaire.
Where that is not enough, the customer may audit, itself or through an auditor it appoints who is independent, is not our competitor and signs a confidentiality agreement with us. The customer proposes an audit plan — scope, duration and start date — with its notice, and we agree the final plan together; nothing in it may require us to break a duty of confidentiality to someone else or to weaken our security. The customer may use the audit's findings only to show its own compliance and ours with this agreement, and will tell us promptly of any non-compliance it finds. An audit takes place on 30 days' notice, during business hours, no more than once in any twelve months except after a breach affecting the customer or where a supervisory authority requires it, and must not disrupt the service or expose another customer's data. Each of us bears its own costs; where an audit finds a material breach on our side, we bear ours and the customer's reasonable ones.
10. What happens at the end
When the agreement ends, the data stays for 30 days, so the customer can export it. On request in that window we will help export it in a structured, commonly used, machine-readable format.
After that we delete it, together with the copies our sub-processors hold, other than what we are required by law to keep — and anything kept for that reason stays subject to this agreement for as long as we hold it. On the customer's written request we will confirm the deletion in writing.
This agreement stays in force for as long as we hold any Customer Personal Data, even after the Terms of Service end.
Backups expire on their normal cycle and are not restored except to recover the service. The current backup retention is stated in Annex 2.
11. International transfers
Where Customer Personal Data is transferred out of the EEA or the UK, the transfer is covered by one of:
- an adequacy decision. The European Commission's decision of 19 December 2025 recognises the United Kingdom as adequate until 27 December 2031, which is what covers EEA customers' data reaching us as a UK company. The UK recognises the EEA as adequate, which covers the reverse direction;
- the SCCs, module 2 (controller to processor) or module 3 (processor to sub-processor) as applicable, with the UK Addendum where the UK GDPR governs the transfer.
Where the SCCs apply between the customer and us, they are incorporated by reference and take precedence over anything in this agreement that conflicts with them. The customer is the data exporter and we are the data importer; Annex 1 supplies Annex I.B of the SCCs, Annex 2 supplies Annex II and Annex 3 the list of sub-processors. They are completed as follows:
- the optional docking clause in Clause 7 is not used;
- in Clause 9, Option 2 (general written authorisation) applies, with the 30 days' notice in section 6;
- in Clause 11, the optional language is not used;
- under Clause 13 and Annex I.C, the competent supervisory authority is that of the EU Member State where the customer is established or, if it has none, of the Member State where its Article 27 representative is;
- under Clause 17 (Option 1), the SCCs are governed by the law of Ireland, and under Clause 18 disputes about them go to the courts of Ireland — the SCCs require an EU Member State's law and courts, which is why these differ from the English law of the Terms of Service.
Where the UK Addendum applies, its Tables 1 to 3 take their details from this agreement and its annexes, either party may end it as its Table 4 allows, and the parties are bound by its Mandatory Clauses.
If the adequacy decision lapses, is annulled, or is not renewed — the December 2031 date is the one to watch — the SCCs with the UK Addendum apply automatically from that day, without either of us having to do anything.
If the SCCs are replaced or a new transfer mechanism becomes available or necessary — for example clauses written for importers who are directly subject to the GDPR, as we are — we may adopt it on notice, provided it does not reduce the protection this agreement gives.
We will tell the customer if we receive a binding request from a public authority for Customer Personal Data, unless we are legally forbidden to, and we will challenge a request that appears unlawful.
12. Liability
Liability under this agreement, and under the SCCs to the extent the SCCs allow, is subject to the limits in the Terms of Service, except where data protection law does not permit that — in particular, Article 82 gives data subjects rights against each of us directly, and nothing here affects them.
13. Order of precedence
Where documents conflict, the order is: the SCCs (where they apply), then this agreement, then the Terms of Service, then the Privacy Policy.
Annex 1 — Details of the processing
Subject matter. Providing the Fuo platform: registration pages, scheduled and live webinars, attendance and engagement records, offers, recordings and follow-up email.
Duration. For as long as the customer's workspace exists, plus the 30-day period in section 10.
Nature and purpose. Collecting registrations; sending confirmation and reminder email; admitting viewers to a live or replayed broadcast; carrying chat and reactions; recording which invitation link produced each registration; recording attendance and clicks on the customer's offer; storing recordings; making all of it available to the customer.
Categories of data subject
| Who | Why they are in the system |
|---|---|
| Registrants and viewers | they signed up for one of the customer's webinars |
| Guests on stage | the customer invited them to appear in a broadcast |
| Distributors and referrers | the customer's own people, who share invitation links |
| Guests at an in-person event | a registrant named them when booking their seats |
| The customer's staff | not Customer Personal Data — see section 2 |
Categories of personal data
| Category | Fields | Source |
|---|---|---|
| Identity and contact | email address; first name, last name, phone number, country where the customer's form asks for them | given by the data subject |
| Registration | which webinar, which date, when they registered, the language they saw | the act of registering |
| Attribution | the invitation link followed, the distributor it belongs to, first and last referring page | the link and the browser's referrer |
| Attendance | whether the personal join link was opened, and when | observed |
| Engagement | chat messages and the display name shown beside them; reactions; clicks on the customer's offer | given by the data subject |
| Playback telemetry | that the player started, and once a minute while it plays its position and whether it is playing, muted or stalling; the browser type; from these, the minutes watched live and on replay | observed by the player |
| Lead level | hot, warm or cold, worked out from attendance, minutes watched, offer clicks and email opens, or set by hand by the customer's team; it orders the customer's follow-up list and decides nothing by itself | derived by the product |
| In-person events | the names, and email addresses where given, of the guests a registrant brings; the time each person was checked in at the door | the registrant; the customer's door |
| Guest appearance | camera and microphone while on stage, and presence in the recording; backstage, the host sees and hears them but the broadcast does not carry them; the fact and time of agreeing to be recorded; the name and title the customer typed | the broadcast |
| Communications | the confirmation and reminder email sent, whether it was accepted for delivery, and whether the email provider saw it opened (a tracking image; a weak signal, since some mail apps open everything) | generated by the product |
| Follow-up | the customer's follow-up stage for the person, the time of a call the customer's team booked with them, and notes the customer's team writes | the customer's team |
Recipients the customer chooses. Where the customer switches on sharing with approved distributors, the platform shows each approved distributor, for registrants attributed to them since their account was created: name, email, phone, attendance, minutes watched, offer clicks, the number of webinar emails opened, and the follow-up stage, level, booked call and number of notes; it lets them keep their own follow-up stage and notes on those registrants, and emails them each new registrant's name and contact details. That disclosure is the customer's decision as controller; the product informs the registrant on the form, records each distributor's acceptance of the distributor terms, and logs each time a distributor opens their list.
No IP address of a registrant, viewer or guest is stored in the database. They are used in transit to route requests and to rate-limit; the web server's request logs hold them for 14 days.
Special category data. None. The customer must not introduce any (section 3.4).
Children's data. None. The service is not directed at children.
Frequency. Continuous, for as long as the workspace is in use.
Retention. As stated in the Privacy Policy, and in any event deleted under section 10 at the end.
Annex 2 — Technical and organisational measures
These are the measures in place at the date of this version. We may change them, provided the level of protection is not reduced.
Access control. Sign-in is by email and password, with passwords stored as scrypt hashes. Sessions are held in HttpOnly, Secure, SameSite cookies and expire. Access to a workspace is limited to the people the customer invites.
Tenant isolation. Every tenant-scoped table carries an organisation identifier, and every query enforces it. Isolation is enforced in the data layer rather than by hiding things in the interface, and it has dedicated tests.
Encryption. In transit, TLS between every browser and the platform, on the media path and to the email API. The application reaches the database over a private container network that does not leave the server. At rest, the server's disks are not encrypted at the operating-system level; access to the server is the control (see Infrastructure). Recordings are held by Cloudflare under its own security measures.
Infrastructure. A virtual server in Frankfurt, Germany, running the application, the database and uploaded images in containers behind a reverse proxy. The same server runs some of the company's other services, each in its own containers. Administrative access to the server as root is by SSH key only.
Segregation of environments. Development and production are separate, and production personal data is not copied into development.
Logging and monitoring. Application errors are reported to an error-tracking service. Administrative changes inside a workspace are recorded with who made them and when. Web server request logs are kept for 14 days, for operations and abuse investigation.
Backups. The database is copied every night at 03:17 UTC, and each copy is checked before it is kept. Copies are kept for 14 days and then deleted. Uploaded images are copied on the same schedule. A copy was restored in full on 6 October 2026, as a test, and matched the live database row for row; this is repeated after any change to how backups are made. Today the copies are kept on the same server as the database, so they protect against mistakes, not against losing the server; an off-server copy is planned.
Personnel. The team is small. Everyone with production access is bound by confidentiality. Access is removed when someone leaves. To answer a support request or investigate a fault, a member of staff may view a customer's workspace read-only. Each such view lasts at most thirty minutes, cannot change anything, and is recorded in the audit log with who opened it, when, and why; the customer can ask for that record at any time.
Sub-processor management. As section 6. Each is engaged under a written contract with equivalent obligations.
Resilience and restoration. The service runs on managed infrastructure with provider-level redundancy for media delivery and object storage. The application host is a single server; recovery is by redeploying from source and restoring the database from backup.
Testing. Automated tests cover tenant isolation and authorisation. No independent penetration test has been carried out yet.
Annex 3 — Sub-processors
Authorised at the date of this version.
| Sub-processor | Role | Data it receives | Location | Transfer basis |
|---|---|---|---|---|
| Hostinger International Ltd | server hosting and the database | all Customer Personal Data | Frankfurt, Germany | none needed — within the EEA |
| Cloudflare, Inc. | video encoding, recording storage and delivery | recordings, which contain guests' and presenters' images and voices | EEA and global edge | SCCs with the UK Addendum, in Cloudflare's data processing addendum |
| LiveKit, Inc. | real-time audio and video for presenters and guests | camera and microphone streams during a broadcast; the display identity of each participant | the region nearest the participants | SCCs with the UK Addendum, or the UK extension of the EU–US Data Privacy Framework where the supplier is certified |
| Resend (Plus Five Five, Inc.) | transactional and reminder email | recipient email address, name, and message content | United States | SCCs with the UK Addendum, or the UK extension of the EU–US Data Privacy Framework where the supplier is certified |
| Functional Software, Inc. (Sentry) | error reporting | technical fault reports, which may incidentally include an account identifier; personal links are masked before sending | stored in the EU region — Frankfurt, Germany | data is held in the EEA; SCCs in Sentry's data processing addendum for any access from the US |
Each supplier's data processing terms, with the transfer safeguards named above, are available on request.
Contact: privacy@fuo.app · Valvasor Capital Ltd, 71-75 Shelton Street, Covent Garden, London WC2H 9JQ, United Kingdom