Data Processing Agreement
For venues whose guests are in the EEA, the UK or anywhere with similar rules. In effect from 25 October 2026.
This agreement is between the venue using vFound (the controller) and Naltyx Data and Marketing Consulting (the processor), and applies where we process personal data on your behalf under the UK GDPR, the EU GDPR, Canadian privacy law or comparable legislation.
Contents
1. Subject matter and roles
You decide why and how personal data about your guests and claimants is processed. We process it only to provide vFound to you. For your own account, staff sign-in and billing data we act as a controller. The venue still controls its ownership claim and release decision. That is covered by our Privacy Policy, not by this agreement.
Optional Google Analytics on the public marketing website is separate controller processing described in our Privacy Policy. It does not receive venue records, signed-in workspace activity or private guest workflows and is not a sub-processor of the venue records under this agreement.
2. Details of the processing
- Subject matter: providing lost-and-found software: publishing found items, receiving and managing ownership claims and lost-item reports, alerts, pickups and returns, messaging between your team and a guest and, within an authorised customer group, sending found items between venues; and, if you switch on vFound Parcels, logging parcels your venue receives for people and handing them over; and, if you switch on vFound Checkroom, checking guests' coats, bags and luggage in, recording stations and events, preparing them from an exit queue, recording optional fees and handing them back and, if you turn them on, taking advance luggage reservations for time windows you set and linking event ticket or wristband codes to checkroom tickets; and, if you switch on vFound Equipment, recording assets, reservations, multi-item and kiosk checkouts, borrower requests, maintenance and stock-takes, taking equipment back and, within an authorised customer group, recording transfers between venues; and, if you switch on vFound Visitors, registering and approving visitors, creating multi-day passes, signing them in and out at a desk or paired kiosk, telling and receiving short replies from the people they came to see, importing verified calendar invitations, running roll calls, printing badges and recording couriers; and, where your venue uses it, keeping a minimal private hotel stay reference current for found items and parcels, including, on vFound Enterprise, through a customer-controlled, read-only Cloudbeds connection; giving a customer that owns several venues an aggregate group command centre with group and regional access and explicit per-venue policy application and, when it opts in, named versioned operating policies, local exceptions, acknowledgements and aggregate service-level monitoring; keeping your people list current from a CSV link or automatic provisioning; and giving each person a signed page for their own linked records.
- Duration: for as long as your plan is active, plus the retention period in section 9.
- Nature and purpose: hosting, storage, display, transmission by email, backup, security monitoring and deletion; transmission of an optional browser alert at the person’s request, from 25 October 2026 or sooner where you have agreed to the push services (see the notice below); AI suggestions and translation where you keep vFound AI switched on (section 4); looking up the approximate city, region and country of the IP address a claim or a lost-item report sent from your lost and found page came from; and sending data to services you connect yourself, such as Slack, Microsoft Teams, Google Chat, the calendar apps your team adds a private calendar link to, a directory or CSV source you choose, a hotel property or coworking member system you authorise, your own systems through our API and webhooks, or an AI assistant your owner or manager connects by signing in, which are yours to choose and instruct and not our sub-processors. An assistant you connect reaches only the tools its permissions allow, for the products you have open, and stops at once when you disconnect it; you pay for it and are responsible for your agreement with its provider.
- Types of personal data: claimant name, email address, optional phone number, description of the lost item, place and date of loss, answers to verification questions, photographs uploaded as proof, messages with your team, submitting IP address and the approximate city and region derived from it; for a lost-item report or alert, the guest’s name, email, optional phone, what they lost, any item-location link they add and any photo of the item they add to a report, and for a report sent from your lost and found page its submitting IP address and the approximate city, region and country derived from it; for a found-item message a member of the public sends to your venue, the photo, the item description, the place and date it was found and where it is now, and an optional name, email and phone; for a return, a shipping address or the name and signature given at pickup, a booked pickup time and any feedback; for vFound Parcels, the name, email, room or apartment and any reference of each person on your parcel list, and for each parcel a photo of its label, the carrier, tracking number and sender, where it is kept, handling instructions, reminder snooze or hold date, desk arrival, delegate name and email, the notices sent, and the name, optional pickup photo and any signature of whoever collected it; for outgoing parcels and delivery rounds, the destination, courier or recipient and handover signature; for vFound Checkroom, a photo of what a guest handed in, its number and, where given, the guest's name, email, room and ticket language, its station, event and storage location, each piece's letter, type, storage location and hand-back state, a request to have it ready, any fee, currency and whether it was recorded as cash or an external POS or card payment, and who collected each piece, with a signature for a lost ticket; for vFound Equipment, each borrower's name and, where given, email, ID or reference and email language, what they borrowed and when it is due, the notices sent, any signature, reservations and their dates, approval state, extension requests and problem reports, and how each item came back with any note and photo; equipment asset fields, which can include a serial number, value, purchase and warranty dates and venue-defined fields, plus maintenance and stock-take records; equipment status changes and their times for utilization reports, team members’ warranty reminder choices per venue and delivery attempt records linked to the item, warranty date and team member, deleted with the venue or, for item-linked records, with the item; for a found item sent between venues of a customer group, both venues, where it was kept and where it goes, an optional note, status, times and the team members who sent, received or took it back; and, for a group equipment transfer, the owning, source, destination, service and custody venues, source and destination locations and codes, status, times, operational notes and the team members who performed its steps; for vFound Visitors, who they came to see and when they arrived and left, and, where given, their email, company, reason for visiting, expected time, valid dates, recurrence and email language, their visitor type and answers to your questions, the invitation sent, approval state, host reply, roll-call status and a copy of your visitor terms, that they agreed and any signature; where you enable them, a private visitor photo and the staff member and time of a visual check of a physical photo ID, but no image or number from that ID; for calendar intake, organizer and attendee names and addresses, meeting identifier, sequence and times, with no meeting description; for paired kiosks, the device name, random token, permitted actions and last-seen time; AI suggestions about items, claims, parcel labels and equipment you add; meeting invites your team pastes or forwards to vFound Visitors (a forwarded invite is kept up to 30 days); for email to inventory, each photo your team emails to the venue’s private address, with the sender’s email address, the subject and the first 500 characters of the message (kept up to 30 days); the requests your team makes in Ask vFound and the actions it suggests; for each email vFound sends, whether it was delivered, bounced or marked as spam, the provider’s reason with any email or IP address removed, the recipient’s domain and a one-way hash of the address, but not the address itself (kept 90 days); and, when a person turns on browser alerts, the browser push address, public encryption key, authentication token, expiry and delivery result linked to their account, pass, ticket or signed service-email record; and for a connected people directory, its encrypted CSV link, source identifier, active status and sync results; for a connected hotel property system, its encrypted credential and settings, connection state, sync cursor, timestamps, counts and bounded error history; for a connected OfficeRnD or Microsoft Entra directory, its encrypted application credential and source settings, connection state, sync cursor, timestamps, counts and bounded error history, and only the source ID, name, email and active status used in the people list; and for a hotel stay, its manual, CSV, API or property-system source, stable stay reference, optional stable guest reference, guest name, arrival, departure, source timezone, current room, state, source update time, sync time and the room recorded when a linked item or parcel entered vFound. The hotel stay context does not include room rate, payment or card data, loyalty status, passport or ID data, guest preferences or unrelated reservation notes. For a customer group, the data also includes its name, venue and region mappings, members and roles, policy templates, named operating-policy versions and targets, venue assignments, local exception reasons and expiry dates, acknowledgements, aggregate venue and service-level counts, alert notification times and group audit history. Aggregate summaries and escalation emails do not contain operational record details. The separate open-work lists include item titles and claim status, parcel recipient names and units, checkroom ticket numbers and guest names, equipment and borrower names, and visitor and host names for authorised venues. They omit email and phone fields.
- Enterprise custom attributes contain the field definitions and values your staff enter. Workflow checklists keep step labels, answers, notes, staff identity and completion time. Values follow the product record retention period; orphaned completions are removed nightly. Claim guest erasure also removes its completed checklists. Venue definitions go with venue deletion; group definitions are removed 24 months after group closure. Enterprise expiry removes none of these records and stops checklist requirements.
Categories of data subject: people who claim items from your venue, report a lost item or set an alert, people who tell your venue they found something, people your venue receives parcels for, guests who use your checkroom, guests who reserve luggage space ahead, people who borrow your equipment, visitors to your venue and the people they come to see, hotel guests whose minimal stay context your venue links to an item or parcel, coworking members on a connected people list, and members of your team. - Special category data: not requested and not required. You must not publish identity documents, payment card details or sensitive personal data found in or on an item.
A venue can group visits under an event name and preview a CSV invitation list. If an owner or manager enables a backup host, that person receives the venue and host name when an arrival remains unanswered, but no visitor details or private pass. Replies to that email go to the venue.
At your instruction, the optional visitor-delegation feature records host/delegate relationships, creation and revocation timestamps and revocation attribution using the people already on your venue’s list. Delegates can see only supported hosts’ approved, confirmed expected or signed-in visit names, host names, times and arrival replies and can send the existing arrival replies; they cannot approve entry. Reply attribution identifies the delegate in the visit history. Optional arrival escalation records the configured delay, backup-person reference and reception follow-up actor and time. Delegate and escalation email attempts use arrival, grant and recipient references and attempt statuses for duplicate prevention; the messages contain the minimal host/venue details described in the Privacy Policy. Both venue settings begin off.
Optional visitor preregistration, event signup and written induction acknowledgement process visitor names, email addresses, company names, answers to controller-configured visitor questions, requested visitor photos, event and visit associations, visitor-terms agreement text and time, preregistration completion time, and induction version, acknowledgement time and expiry. The purposes are advance preparation for a visit, managing event registration capacity, and recording acknowledgement of the controller's visitor instructions. The controller chooses whether to enable each feature and sets its questions, instructions, event parameters and acknowledgement validity. Acknowledgement evidence does not certify understanding or determine admission. Private pass and invite-only event URLs act as transferable bearer credentials.
When the Controller enables Checkroom phone notices for an Enterprise venue, the Processor records a guest's explicit, ticket-specific SMS and/or WhatsApp choice and processes the encrypted alert number, its keyed fingerprint, channel choices, language, consent wording version and consent and withdrawal times. Notices use the Controller's existing messaging connection and customer-owned provider account. The recipient number, venue name, short ticket status and private ticket link are sent to that provider; guest names, email addresses, rooms, item descriptions and photos are excluded from these notice payloads. The Controller is responsible for its provider arrangement, fees, approved WhatsApp templates, recipient coverage and provider-side retention. Existing signed preference withdrawal and authenticated inbound STOP handling apply; already-started or accepted messages cannot be recalled. Stopping both channels clears the live alert number and keyed fingerprint. Consent records follow the associated Checkroom ticket's retention, are erased at once if the ticket's guest email address is corrected, and orphan consent records are removed during nightly cleanup. Existing venue erasure and backup schedules continue to apply. This feature adds no vFound-owned messaging account.
Where enabled by the controller, Lost & Found processing includes email control verification before a claim is created and optional journey context supplied with a lost-item report: flight or route, service date/time, seat/gate, event and station/seating area. Journey context and its earlier report versions are processed under the agreement's existing access, retention, erasure, backup and sub-processor terms. We keep venue-scoped hashes of the address, code and challenge token, with an expiry time, and explicitly clean up expired challenges and remove them when the venue's data is deleted. Verification confirms control of an email address, not identity or ownership; journey context does not authorise cross-venue disclosure.
Your authorised team may record a lost-item report for a person by telephone or in person. A name and contact details may be omitted. Staff record how they helped and that they explained the use of the details. This is a privacy explanation, not marketing consent or proof of ownership. Private location or journey details may include a room, route, vehicle, seat, gate, lift, run, lodge or locker reference where you chose those fields, and your team can record the same kind of private details on a found item. Passwords, payment information and identity documents must not be provided or recorded.
Group intake: An explicitly published organisation page routes one report to the chosen receiving venue, or its stated intake venue when the location is unknown. Publication does not enable matching across venues. A group’s owner can also choose to list, on that page, the found items its selected venues already show on their own pages, with each venue’s public label and a link to claim the item on that venue’s page. This is off unless the group turns it on. Group review and exports follow current membership, region, product and explicit review settings. A report sent from an organisation page is handled like one sent from your lost and found page. Matching across a group’s venues is off unless the group’s owner switches it on; while it is on, open lost reports are compared with found items at the group’s other venues and shown, without the reporter’s contact details, address or photos, to people in the group who have a role at both venues.
Customer-configured CRM destinations: Selected webhook events may be sent to systems you choose, such as your CRM. Extra report contacts are sent only after a separate explicit choice, and the source record and transport are checked again before each send.
Where you enable the private Equipment borrower catalogue, your instructions also include showing your equipment names, categories and photographs to holders of current venue-scoped My vFound links and recording grouped Equipment requests against the borrower's existing name, email address, reference and language. The catalogue adds no new borrower identity field, attachment upload or application-level browsing-history record. Where the controller enables equipment specifications, staff-written borrower-visible technical descriptions are published through the private catalogue; they must not contain personal information or internal asset details. Where the controller separately enables reservation history and change requests, we process the existing borrower/reservation association, proposed booking dates, equipment quantities, optional text notes of up to 1,000 characters, request and decision timestamps, the deciding staff identifier and recorded reservation status changes. The purposes are to let the borrower inspect their booking and ask for changes, let authorised venue staff review requests, recheck allocation on acceptance, and send the borrower and venue staff a request or decision notice. Notes are encrypted in storage and are not included in these notices. The existing service-email provider receives the recipient address, venue name, request/decision status and a private My vFound link or staff workspace link as applicable. No attachments, new identity document collection, additional messaging provider or AI processing of these notes is introduced. Existing support, hosting, sub-processor and international-transfer arrangements apply. Grouped requests follow the retention and deletion controls for Equipment reservations in section 9.
Parcel recipient-correction reporting is on unless the Controller turns it off; an existing saved off choice is preserved. When a recipient confirms a report, we process the parcel recipient-correction report, its report and resolution times and activity records. Where the Controller enables parcel notice hours, we process scheduled parcel notice times and delivery-attempt states. Delivery guards also process notice delivery-attempt states when needed to prevent stale or duplicate notices. These records are linked to the parcel, venue and applicable staff actor, with hashed forms of recipient addresses and pickup codes for stale-notice and duplicate checks. The purpose is to correct parcel assignments and deliver collection notices during configured desk hours.
Optional Checkroom ticket conversations process guest and desk message text, sender side, sending timestamps, and links to the existing venue and ticket record to exchange questions and replies about that ticket. No staff author identifier is stored with a message. Access follows venue membership permissions and possession of the private ticket link, subject to existing support and sub-processor arrangements. Message bodies are encrypted in the application database, excluded from displayed conversations after 30 days and deleted by routine pruning; deleting the ticket or venue also deletes its messages. Backup copies follow the existing backup deletion schedule. Requested reply notifications use the existing email provider and contain no conversation text. Notification records include the message reference and a hash of the recipient email address; these follow the existing notification-record lifecycle rather than the message-body retention period. No additional provider is introduced.
Unless the Controller turns accepted-terms copies off, the accepted-terms copy displays the agreement text and acceptance time already held with a visit, with a SHA-256 digest, through the current eligible private visitor pass. An existing saved off choice is preserved. Optional visit feedback records one 1–5 rating, an optional comment of up to 1000 characters, its submission time, the visit's feedback opt-out, active email-choice and invitation-attempt times, and the active choice's email/pass fingerprint. The purposes are allowing visitors to retain their accepted terms and optionally report their experience to the venue after sign-out, including between recurring sessions. Feedback does not determine admission or approval. Authorised venue members with visit-read access may review it, subject to the existing platform support and sub-processor arrangements. Private pass links are transferable bearer credentials. Invitation email uses the existing visit email address and email provider only after the visitor requests it and the Controller enables the relevant settings; it includes the venue name and private feedback/preferences link, not the response. The active choice is bound to that address and pass token and is cleared if either changes. Accepted-terms copies are on unless turned off, with existing saved off choices preserved. Visit feedback and feedback invitation emails begin off.
On your instructions, vFound processes optional finder name, email, phone, affiliation and unclaimed-notice preference, receiving staff identity and time, and staff-started owner-contact claims. Authorised venue members can read these records; platform administrators may access them to support your venue. Finder details are not published. Staff initiate finder receipt and unclaimed-item emails; owner-contact invitations use the existing private claim link. Owners and managers can erase finder contact details and the notice preference without retaining their values in item history. Finder details otherwise remain until their item or venue data is deleted, with existing protected-backup retention. Staff-started claims use the existing claimant retention and erasure controls. Optional handover identification type and a note of up to 120 characters are recorded without an identification-document upload field; staff are instructed not to type identification numbers. The note is erased with the claimant’s personal details and is omitted from release receipts. When an item moves between venues of one authorised customer group, its finder details move with it and are then processed for the receiving venue under the same terms, including erasure by its owners and managers and its retention. Erasure of finder or claimant personal details also invalidates the venue’s stored retry responses, including ID-check notes. Staff-contact and finder emails share limits of 50 per venue and 3 per recipient per venue-day, including confirmed resends. To keep deletion from resetting those limits, coded recipient, date and count records remain until venue data is deleted; the counts contain no email address. Unclaimed-item notices are rechecked before sending and stale notices are dropped. Queued staff-contact and finder emails are dropped if their reserved venue-day has ended.
3. Our obligations
We will:
- process personal data only on your documented instructions, your use of the product, and this agreement, are those instructions, unless the law requires otherwise, in which case we will tell you first unless that law prohibits it;
- ensure people authorised to process the data are bound by confidentiality;
- implement the security measures described in section 6;
- not sell the data, use it for our own marketing, or use it to train AI models;
- tell you if in our opinion an instruction infringes data protection law.
4. Sub-processors
You give general authorisation for the sub-processors below. We remain liable for their performance of these obligations.
- OVHcloud: application, database and file hosting in Singapore, including our own mail server, which receives the photos your team emails to vFound.
- Resend (Plus Five Five, Inc.): sends vFound’s service email from 7 October 2026. It receives each email’s recipient address, subject and content, and tells us whether the email was delivered, bounced or marked as spam. It processes data in the United States, where it sends through Amazon Web Services, under its data processing addendum, which includes the EU Standard Contractual Clauses.
- Cloudflare: bot protection on public forms.
- ipapi.co: IP-to-approximate-city lookup used to help you assess a claim or a lost-item report.
- OpenRouter (OpenRouter, Inc.): AI gateway for venues that keep AI assistance switched on: suggesting item details and search words from item photos; reading a parcel's label photo to suggest who it is for, the carrier and the tracking number; ranking possible matches for a guest's description, search photo (used once, not kept by vFound) or the photo a guest adds to a lost report (kept privately with the report and deleted with it); checking a claim against the item record (including its private description and internal notes) and proof photos as a suggestion for staff, who make every decision; translating messages between guests and staff and drafting staff replies; structuring a guest's lost item chat, which never asks for contact details; suggesting a name for equipment from its photo; turning a team member's typed request in Ask vFound into a suggested action (phone numbers removed first; the records found are never sent); telling whether a workspace camera photo shows a found item or a parcel label (codes are read on the device); reading meeting invites you paste or forward into suggested visits (links, passcodes, phone numbers and place lines removed first); comparing the description your team types of a checkroom item (email addresses, links and phone numbers removed) with that night's item photos and item types (never ticket notes, or the name, email address or room on a ticket); and cutting a photo that shows several items into one photo per item; comparing a newly logged item's photo and description with up to three earlier items to flag a possible duplicate; wording the daily summary on the workspace home page and the checkroom's end of night summary from counts only; and writing a weekly read of your venue's numbers from the venue name and aggregate counts, rates, item categories and the places guests said they lost things (never a guest's name or contact details), shown on the dashboard and emailed every Monday to your owners and managers unless you switch the email off. Nothing suggested is applied to a record or sent to a guest until a person on your team confirms it. Photos of items already flagged as showing personal details are not sent again, and an answer to a verification question that asks for a passcode, password, PIN, phone number, address, date of birth or full name is not sent. Proof photos a claimant uploads are sent as supplied when AI is on for your venue. Requests pass to the model provider (Google, with an OpenAI model as a backup run by OpenAI or Microsoft Azure), which may process them in the United States or other countries. Every request asks for zero data retention: only providers that keep no copy and do not use the data to train models are used, and OpenRouter keeps no copy of the content and does not train on it.
- Google (Google Workspace): our support mailbox, where messages about your venue’s data may arrive.
Stripe validates the card used to start a trial and handles billing for a vFound subscription. If you record a Checkroom fee collected in cash or through your own external POS or card terminal, that provider is yours to choose; vFound receives no such Checkroom payment or card details.
We aim to give 30 days’ notice before adding or replacing a sub-processor. When a provider has to be replaced at once to keep the service working, for example when email stops arriving, we make the change first and tell you at the time, on this page and in the owner email. If you reasonably object on data-protection grounds within 30 days of the notice, we will work with you in good faith on an alternative; if none is workable, you may terminate the affected subscription and receive a pro-rata refund of fees paid for the unused period.
5. International transfers
We host the data in Singapore, keep an encrypted copy of our backups in Canada, and our AI, email delivery and support email providers may process it in the United States. Where personal data is transferred out of the EEA or the UK, we rely on an adequacy decision where one applies (Canada holds one from the European Commission) and otherwise on the EU Standard Contractual Clauses, with the UK International Data Transfer Addendum where relevant, together with appropriate supplementary safeguards. Those clauses are incorporated here by reference, with the details in section 2 filling their annexes.
6. Security measures
Taking account of the state of the art, cost and the risks involved, we maintain: encryption of data in transit (HTTPS with HSTS); passwords stored only as salted hashes, with rate-limited sign-in; one-time sign-in links by email that work once, for 15 minutes, checked against a one-way hash; browser push addresses and keys encrypted in the database; directory links encrypted in the database, public HTTPS checks on every redirect and a 10 MB download limit; pending calendar invitation details encrypted in the database; paired kiosk tokens stored only as a hash on the server, revocable by an owner or manager, and never used as a staff identity; kiosks that never list the people at a venue and reset entered details after 60 seconds; role-based access control, with every request checked against the person’s venue or group membership, regional group roles restricted to matching venue regions, group summaries containing no operational record details and open-work lists restricted to authorised venues without email or phone fields, policy effect previews tied to the actor, version, selected venues, their current settings and active exceptions before explicit assignment, every record query limited to an authorised venue, and automated tests of cross-venue and cross-region denial; signed, expiring links for claimant access, lost-item reports and My vFound pages, and an owner or manager can also reset a My vFound link; people-list email addresses shown in full only to owners and managers; a content security policy and bot protection on public forms; rate limiting; an audit log of security-relevant actions, kept 24 months; daily backups kept 30 days on our server with access limited to administrators, an encrypted copy kept off the server, and rehearsed restores; and least-privilege access for our own staff. Encrypted copies of the daily backups are also kept in OVHcloud’s Beauharnois region in Canada, encrypted before they leave the server and kept 30 days, while the application, database and files stay hosted by OVHcloud in Singapore. We review these measures as the service changes.
Optional enterprise identity adds encrypted provider client secrets, DNS domain-ownership proofs and provider subject/email links to staff logins. The identity provider is chosen and controlled by you under your agreement with it, rather than a vFound-supplied provider. We validate signatures, issuer, audience, expiry, browser state, nonce where applicable and replay. Provisioning starts off and creates staff only within configured venues. Authenticator secrets are encrypted, recovery codes fingerprinted and single use, and challenges deleted after 24 hours past expiry. Venue settings and provider links go with venue deletion. Group settings follow its 24-month closure retention, with provider access disabled and its client secret removed on closure. Settings and sign-in changes are audited for 24 months.
7. Helping you meet your duties
Taking into account the nature of the processing, we will give you reasonable assistance with requests from data subjects (access, correction, deletion, portability, objection), with data protection impact assessments, and with consultations with a supervisory authority. In the product your owners and managers can read claim records, correct a guest’s name, email and phone, export every claim with its messages as a spreadsheet file, and delete a guest’s personal details from a finished claim, which keeps only an anonymous record of the item’s outcome, delete a guest’s personal details from a lost report that never became a claim, which leaves an anonymous record of the report (its category and when it was reported), and export the people list. Your owners and managers can also export your venue’s audit record for the period it is kept, up to 20,000 events in one file. In a customer group, a group owner, manager or regional manager can find the lost reports, claims and finder details that hold one person’s email address or phone number (with or without its country code) at the venues where they are an owner or manager and Lost & Found is open (a regional role, only its region), and open each record in its venue to delete the details there in the same way. Each search is recorded in the group’s activity without the address or number. If a data subject contacts us about your venue’s data, we will refer them to you rather than respond on your behalf.
8. Personal data breaches
We will notify you without undue delay after becoming aware of a personal data breach affecting data we process for you, with the information we hold about what happened, the categories and approximate numbers affected, the likely consequences and the steps taken, supplementing it as we learn more. Notifying regulators and affected individuals where you are the controller remains your decision and duty.
9. Return and deletion
You can export your records at any time while your subscription is active. If your account is closed, your owners and managers can still sign in for 90 days to export your items, claims, parcels, visits, equipment checkouts, checkroom tickets, hotel stays and people list (lost-item reports and alerts, equipment transfers and checkroom stations have no download once an account is closed), or you can ask us to reopen it; after that we permanently delete the personal data we process for you, except where the law requires us to keep it, except the reserved venue code and the sign-in of an owner who still has another venue (which goes when that venue is deleted), and except copies in backups, which are deleted within 30 days as those backups age out (archives from our September 2026 server move are deleted once that move is confirmed complete). Data in backups remains protected by this agreement until it is deleted. Parcel records, their label photos, pickup photos and signatures are deleted 12 months after a parcel is collected or returned; finished outgoing parcels follow the same period. Expired delegate codes and served desk-arrival rows are deleted after 30 days. Checkroom tickets, their piece and hand-back records, photos and signatures are deleted 90 days after all the things are handed back, or 12 months after they were left at closing. Unclaimed self check-ins are deleted after two days. Checkroom events are deleted 12 months after they end once no ticket refers to them; station records remain until the venue deletes them or its account. Luggage reservations are deleted 30 days after their reserved time window ends; time windows nobody reserved are deleted 30 days after they end. An event ticket or wristband code linked to a checkroom ticket is kept only as a keyed hash, cleared when the link ends and deleted with the ticket. Equipment records, their return photos and signatures are deleted 13 months after the item comes back or is marked lost. Collected or cancelled equipment reservations and completed stock-takes are deleted after 13 months. Completed equipment-transfer records, including venue, custody, location, status and note history, are deleted after 24 months. Equipment asset and maintenance records remain until the venue account is deleted. A hotel stay is deleted 13 months after its last known date (departure, then arrival, then last update) when no item or parcel still links to it, whether or not the source ever marked it departed or cancelled; linked stay context remains until those parent records no longer require it. A venue chooses a visitor retention period from 7 to 365 days, with 365 days as the default, and may set a different period for a visitor type; a type without its own period follows the venue’s. After that period, a finished visit, its optional visitor photo, staff visual-check record, sessions, roll-call entries, courier link and any signature are deleted. Calendar invitation details with no visit are deleted after 30 days. Found-item messages are deleted 30 days after they arrive if your team does not deal with them, 7 days after your team declines one, and 30 days after your team logs the item; a message’s own copy of the photo is deleted as soon as it is logged or declined. What vFound AI wrote for your team (item descriptions and search words, match verdicts for lost reports and weekly insights) is deleted 13 months after it was written, and the wording of the daily summary after 30 days; a claim check is kept with its claim and deleted when the guest’s details on that claim or the venue’s data are deleted. Photos emailed to a venue’s address for email to inventory are deleted with their sender, subject and note 30 days after they arrive, logged or not (the photo file goes as soon as the draft is logged or discarded). Paired kiosk records are deleted with the venue account, and can be revoked sooner. Background tasks that could not finish, with the details they were working on, are deleted after 30 days. The record of an AI assistant connection is deleted 90 days after it is disconnected. Error reports, which record faults in vFound itself with email addresses, numbers, codes and quoted text removed, are deleted 90 days after the error was last seen. The daily count of how each kind of email link ended, which holds no address, token or person, is deleted after 90 days. Browser push addresses are deleted when the person turns them off, the browser expires them, or the related account or record is deleted, and a host’s are also deleted when their My vFound link is reset, their email changes, or they are deactivated (including by a directory sync) or removed; an address whose deliveries keep failing is deleted after 30 days. The record of whether an email was delivered is deleted after 90 days. Current venue and product access is checked again before every alert. Deactivated people cannot be selected for new work. Their open operational records remain venue-scoped and follow the product retention periods above while authorised staff resolve them. People-list entries and their encrypted directory setting are deleted with the venue account. A signed My vFound link expires after 60 days. Removing or deactivating a person, changing their email or resetting their link invalidates their earlier links at once.
Equipment reservation change requests and recorded status history are deleted with their reservation, including deletion of collected or cancelled reservations after 13 months without an update. They are deleted sooner when the borrower is removed from the venue’s people list or the venue’s data is deleted. Configuration remains until venue deletion; turning a setting off does not erase retained records. Backup copies remain protected and age out under this agreement’s existing 30-day backup retention.
A report whose chosen contact method is email receives a queued acknowledgement email through the venue’s normal private report journey. Phone messages require separate report-specific consent and the venue’s configured provider; staff may instead call and record whether they reached the person. A report without contact details receives no outbound acknowledgement. Its reference alone does not grant private access. Authorised staff may verify a new mailbox with a report-bound code valid for 15 minutes and up to five attempts, then attach the address and send the ordinary signed private link. Those links are bearer credentials. The pending address is encrypted, and the code and challenge token are kept only as one-way hashes. This verification state is removed on replacement, completion, expiry cleanup, or when the report is erased or your data is deleted. Matches across venues are deleted when matching is switched off, the report is erased or either venue is deleted, and with the group’s records 24 months after the group closes.
External copies: Customer systems and their retained copies are separate from vFound’s deletion boundary: deleting vFound’s copy does not prove external copies were deleted. Backups retain their existing boundaries.
Customer-group activity records are deleted after 24 months. Closing a group removes its group access immediately; the remaining membership, venue-region, policy-template, operating-policy version, assignment, exception, acknowledgement alert and completed equipment-transfer records are deleted 24 months after closure. A venue’s own owner can take their venue out of a group at any time, which ends group access to it at once. Removing a venue stops its assignments, exceptions and open alerts. Removing a venue from a group or closing the group does not delete the venue or any of its operational records, which continue under the venue's own account and the periods above.
CSV invitation previews and results are deleted after seven days. Authorised invitation delivery continues from visit IDs and delivery state, kept with the visit. Event names and backup-host settings remain until the venue account is deleted.
Visitor-delegation relationships and revocation records are retained until the host or delegate is removed from the people list or the workspace is deleted; the workspace shows ended relationships for only 30 days without deleting the underlying records. Arrival follow-up records, notice references and attempt statuses, and historical delegate reply attribution follow the visit’s retention and are deleted with it. Revocation ends delegated access without erasing attribution on a retained visit. Existing backup retention applies.
Preregistration records, event associations and induction acknowledgement evidence are deleted with their related visit under the controller's existing visitor retention setting. Expiry of an acknowledgement is a validity boundary, not a deletion trigger. Event signup configuration and induction versions remain until venue account deletion. Turning an optional feature off does not erase retained records. Venue account deletion removes the added configuration and evidence; protected backups continue under the backup deletion periods above.
These parcel-correction, notice-scheduling and attempt records follow their parcel's retention: while waiting and for 12 months after collection or return, then deletion with the parcel, or earlier with venue deletion. Settings remain until venue deletion; backup copies follow the backup retention already stated in this agreement.
The feedback response, active email/pass fingerprint and preference and invitation-attempt times follow the related visit's existing retention and are deleted with that visit or venue erasure. A visitor's feedback opt-out clears the live rating, comment, submission time and active email choice including its fingerprint, while the opt-out and any invitation-attempt time remain until visit deletion. Disabling a setting ends access without shortening retention. Expected and signed-in visits use the existing preparation expiry, including recurring passes returned to expected between sessions. Visits marked signed out permit private follow-up access for less than 30 days after recorded departure. Access may end earlier through settings withdrawal, cancellation, approval withdrawal, token revocation, venue or product unavailability, or deletion. Existing protected-backup, application-log, delivery-record and failed-task retention continues to apply. Encrypted queued invitation references and recipient/pass fingerprints are checked against the current visit before transport; a deleted visit cannot generate a later invitation. Already-started email and visitor-saved or printed copies cannot be recalled by live erasure.
10. Audits
On reasonable written request, and no more than once a year unless a regulator requires otherwise, we will provide the information reasonably necessary to demonstrate compliance with this agreement. Any on-site audit must be at a mutually agreed time, under confidentiality, and must not compromise the security or data of other customers.
11. General
If this agreement conflicts with the Terms of service on the processing of personal data, this agreement prevails. The liability limits in the Terms of service apply to this agreement, except where data protection law does not permit them. It is governed by the laws of Ontario, Canada, except where mandatory data protection law requires otherwise.
Questions, or a countersigned copy: armaan@vfound.io.
Version history
The 25 October version adds to section 7 that your owners and managers can delete a guest’s personal details from a lost report that never became a claim, which leaves an anonymous record of the report (its category and when it was reported). It also adds to section 2 that an organisation page can list found items that its venues already publish, off unless the group turns it on, and to section 7 that your owners and managers can export your venue’s audit record. Section 2 now says that an item moving between venues of one authorised customer group takes its finder details with it. Section 7 now says that a group owner, manager or regional manager can find one person’s records by email address or phone number at the venues they manage with Lost & Found open, to delete the details in each venue.
The 24 October version describes in section 2 lost-item reports your team records for a person by telephone or in person, which are on unless you turn them off, the private location or journey details you can choose to collect, organisation pages a group can publish to route a report to one of its venues, matching across a group’s venues, and selected webhook events you can send to systems you choose. Section 9 says how acknowledgements, phone messages and mailbox verification work for those reports, how long matches across venues are kept, and that customer systems sit outside vFound’s deletion boundary.
The 23 October version describes Visitors delegates and unanswered-arrival escalation, both off unless you turn them on, in section 2 and their retention in section 9. Sections 2 and 9 also describe the Equipment catalogue and Parcels desk notice hours, which remain off unless the venue turns them on. Parcels wrong-recipient reporting is on unless the venue turns it off; an existing saved off choice is preserved. Venues can now let guests reserve luggage space ahead, and link an event ticket or wristband code to a checkroom ticket. Both are off unless the venue turns them on. Connections to Cloudbeds, OfficeRnD Flex and Microsoft Entra ID are part of vFound Enterprise; a venue can still pause or remove an existing connection at any time. This version also describes optional claim email verification and journey details, Checkroom phone alerts, and visitor preregistration, event signup and induction acknowledgements. This version also describes optional Checkroom ticket conversations, Equipment specifications and reservation change requests, and Visitors accepted-terms copies and feedback, with their access and retention limits. Claim privacy guidance, search-ended email, Checkroom collection receipts, Visitors accepted-terms copies and Parcels wrong-recipient reporting are now on unless the venue turns them off; existing saved off choices are preserved. The 22 October version adds equipment status history and optional staff warranty reminder records in section 2, and CSV invitation previews, event names and optional backup-host notices in section 2 with their retention in section 9. It also adds in section 2 found-item messages that members of the public send to your venue, when you turn them on, and their retention in section 9. The 19 October version adds in section 2 the internet (IP) address a lost-item report sent from your lost and found page comes from and the approximate city, region and country derived from it, which your owners and managers see in full and your other team members as the place only, and in section 4 that the location lookup also serves those reports. The 17 October version changed nothing in this agreement: its date moved with the Privacy Policy, which now describes vFound support records. On 16 October it removed the optional service through which a guest could pay vFound to post an item back, which was never switched on for any venue, so Easyship is no longer one of our providers (section 4) and no shipping details were ever sent to it from a venue. It also adds scoped open-work lists, Enterprise custom attributes and workflow checklist records (sections 2, 6 and 9). On 15 October it added in section 2 sending found items between venues of an authorised customer group and the record kept of each move. On 8 October it added in section 6 that encrypted copies of the daily backups are also kept in OVHcloud’s Beauharnois region in Canada. It also removed the stopped server that held archives from before our September 2026 move, which has been deleted (sections 4 and 5). On 7 October it named Resend, which now sends vFound’s service email, as a sub-processor in section 4, and added in section 2 the record of whether each email was delivered, kept 90 days without the address (section 9). On 6 October it added one-time sign-in links by email to the security measures in section 6. On 5 October it stopped describing spoken requests in Ask vFound, which no longer takes them, and added how long background tasks that could not finish, disconnected AI assistant connections and error reports are kept. On 4 October it added email to inventory, the weekly insights and their Monday email, photo splitting and duplicate checks, what is withheld from the AI, how long what the AI wrote is kept, and what stays after an account is closed, and it clarified the closed-account exports and when a hotel stay is deleted, a venue owner’s right to take their venue out of a customer group, and that a platform administrator’s reads and refused changes of customer records are logged, and that describing a lost checkroom ticket to the AI sends no ticket notes. On 3 October it added the private, minimal hotel stay context used by Lost & Found and Parcels, with manual, CSV and API input, source freshness and separate room-at-event history, and customer groups with regional access, aggregate oversight and explicit per-venue policy application. It also covers customer-configured named operating-policy versions, local exceptions, acknowledgements and aggregate service-level alerts, which remain off until a group manager configures them. On 3 October it also covers a customer-authorised Cloudbeds connection limited to read:reservation and OfficeRnD Flex and Microsoft Entra ID connections limited to source ID, name, email and active status for the shared people list. The Cloudbeds reader keeps only the minimal stay context described below and never changes provider records. The OfficeRnD reader excludes memberships, bookings, invoices, payments, custom properties, addresses and phone numbers; the Entra reader never creates vFound staff accounts, roles or access decisions. It also states that deactivation prevents new assignments while authorised venue staff can resolve open parcels, equipment, reservations and visitor records. On 2 October it added optional private visitor photos, photo badges and a staff-recorded visual check of a physical photo ID, with no ID document image or number stored and no automated verification, facial recognition or watchlist screening. On 25 September it began to cover vFound Parcels, vFound Checkroom, vFound Equipment and vFound Visitors, directory connections and My vFound pages. On 26 September it added Checkroom stations, events, its exit queue, kiosk self check-in and fee recording. On 28 September it added that every product’s records can be exported for 90 days after an account closes, that My vFound links expire after 60 days and can be reset, that people-list email addresses are shown in full only to owners and managers, that a visitor type can follow the venue’s retention period, that lost-item report links expire after 30 days, that a host’s browser alerts end when they leave the people list, and that Slack host connection records and the Checkroom phone wallet option are no longer kept or offered. The previous version was dated 19 October 2026.
Also on 15 October 2026: optional enterprise sign-in uses the customer’s own OpenID Connect or SAML identity provider. Optional authenticator-based two-step sign-in is available to venues on an arranged plan (vFound Enterprise, Terms section 3). Owners can require it for their team; venue policies never force it on platform administrators. These settings start off. No identity-provider account is supplied by vFound. When an arranged plan ends, single sign-on and two-step sign-in are no longer required and sign-in falls back to the password.
Shared lost-report kiosks (15 October 2026): A venue can pair a tablet for passenger lost-item reports. The normal report, language, consent and retention rules apply. The private report link is emailed rather than shown on the shared screen. Entered details clear on submission, return to the home screen or 60 seconds without activity. Personal sign-in and language cookies are cleared on kiosk entry; device pairing still uses an essential, revocable cookie. The venue is responsible for securing and locking its tablet.
Lost & Found integrations (15 October 2026): A venue can explicitly give a customer-managed API key permission to create a guest report, record a human ownership review and decision, record release approval and physical pickup, or record eligible donation or disposal. The audit names the manager who created the key; the customer must control its own operators. A review keeps its method, result, actor and time with the claim, not an identity-document copy or a claim of document authenticity. Custody reads include the private collection name and time, but no signature image. Claim erasure clears that name and any handover history that contains it. These decision and handover operations are unavailable to MCP and Ask vFound assistants.
Phone alerts (15 October 2026): SMS and WhatsApp notifications are optional, off by default, and use the venue’s own messaging-provider accounts. A guest must explicitly choose each channel for their claim or lost-item report. We send the guest-supplied number, venue name and a private link through that provider; WhatsApp uses the customer’s approved templates in English or Arabic. Email continues separately. Provider acceptance is not proof of delivery. Replies go to the customer’s provider, not to a vFound message inbox. If the customer connects its provider’s reply address, vFound reads a reply only to recognise a stop word such as STOP and does not keep its text. Phone alerts are available to venues on an arranged plan (vFound Enterprise, Terms section 3), and they stop when that plan ends.
Phone-alert choices include an encrypted number, a keyed fingerprint of it used only to match stop replies, channel choices, language and consent timestamp. They remain with the underlying record and are removed when it is deleted or its guest details are erased. Stopping both channels through a message’s private link, which keeps working while the choice exists, clears our active alert number for that record; a stop reply does the same for every alert to that number from that venue or group, and START does not turn alerts back on; messages already accepted by a provider cannot be recalled. Delivery-attempt records and provider references are kept for 30 days and pruned nightly. The customer controls provider fees, sender registration, template approval, local messaging rules, the provider’s own retention and international processing. vFound supplies no messaging-provider account. A dedicated deployment must assess those providers, carriers and recipients separately; residency mode cannot certify their processing locations.
Dedicated customer deployments (15 October 2026): The hosting locations and providers below describe vfound.io. A separately agreed dedicated deployment uses the customer’s infrastructure and the locations and providers named in its contract. Optional residency mode disables vFound’s default external services; customer-configured destinations remain under the customer’s control. Infrastructure, mail routing, backups and each connected service must also meet the agreed location requirements. The configuration check does not establish the physical location of a customer-configured service.
