Privacy policy

What vFound collects, why, who can see it, and what you can ask us to do about it. In effect from 25 October 2026.

vFound is operated by Naltyx Data and Marketing Consulting (“Naltyx”, “we”), Ontario, Canada. We sell software to venues. We do not sell personal information, we run no advertising trackers, and we do not use your data or your guests’ data to train AI models.

Version history

1. Who is responsible for what

This distinction matters, so it comes first.

• We are the controller for venue account data, staff sign-in data, billing data and data from our public website. We decide how that is used. The venue continues to control the ownership claim and its decision to release an item.
• The venue is the controller for the found items it publishes, for claims made to it, for found-item messages people send it and, if it uses vFound Parcels, vFound Checkroom, vFound Equipment or vFound Visitors, for its parcel, checkroom, equipment and visit records. We are only its processor, acting on its instructions under our Data Processing Agreement.

So if you submitted a claim, the venue handling your item decides what happens to your information. Contact them first; we will help them respond.

2. What we collect

If you make a claim as a guest: your name, email address, optional phone number, where and when you think you lost the item, your description of it, your answers to the venue’s verification questions, any photos you upload as proof, and your messages with the venue. If your item is returned we also keep a shipping address if it is sent to you, or your name and, where the venue asks for one, your signature when you collect it, plus any pickup time you book and any feedback you give. We also record the internet (IP) address you submitted from and an approximate city and region derived from it, so the venue can weigh a claim before handing over someone’s belongings, and so we can detect abuse. We do not collect precise GPS location. The venue’s owners and managers see the address and the approximate place; its other team members see only the approximate place, and view-only members see neither.

When a venue enables claim email verification, we send a one-time code to the address you provide before creating a claim. It expires 15 minutes after your request. 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. Email jobs are encrypted and checked again before sending. Database backups and failed email jobs follow the retention periods described in this policy. This checks control of a mailbox, not ownership of an item.

If the team posts your item to you: the delivery address you give on your private claim page, and the carrier and tracking number the team records. The venue's team uses them to post the item with a carrier it chooses and pays itself; vFound sends nothing to the carrier. If you open the tracking link, your browser goes to the carrier's own website, under that carrier's privacy policy. These details are never shown publicly and are deleted with the claim's details.

If you open a private walkthrough: a walkthrough is a video we make for one named person or organisation and send as a private link, so a record of it being opened is personal information about the person we sent it to. When the page is opened, our server records which walkthrough, the time, whether the device is a computer, phone or tablet (worked out from the browser’s identification, which we do not keep) and the main language the browser asks for. We do this because we have a legitimate interest in knowing whether a film we sent has been seen, so that we can follow up with the person it was made for. Nothing is stored on your device for this, the page sets no cookies, and the only thing it reads from your device is whether you pressed Allow on an earlier walkthrough. This applies only to walkthroughs we make as prospect films; walkthroughs made for our customers record nothing. Only if you press Allow on the page, we also record how much of the video you play and for how long, how far you get, which chapters you reach, the subtitle language you choose and whether you reach the end, and your browser keeps one note that you allowed it. That note applies to all vFound walkthroughs in that browser until you press Stop, which removes it and ends recording on every walkthrough page open in that browser. Stopping does not delete what was already recorded: it stays for the 12 months in section 6, or until we delete it on your request (section 9). Without Allow none of that is recorded or stored. We do not link one open to another unless you press Allow: no code made from your IP address or your device is kept, so a count of opens is not a count of people. We do not store the IP address. Visits by our own team while signed in, and the automated previews and crawlers we recognise, are not counted. The records are shown only in vFound’s platform administration, never to a venue or to anyone else you share the link with. Our emails to ourselves about them name the walkthrough and the person or organisation it was made for (section 4).

If you report a lost item: your name, email address, optional phone number, what you lost, when and where, any item-location link you add (such as an Apple Find My link) and any photo of the item you choose to add. The photo is kept privately with your report: the venue's team can see it, it is never shown publicly, and when the venue keeps AI assistance switched on, vFound AI compares it with found items to suggest matches. When you send the report from the venue’s lost and found page, we also record the internet (IP) address it came from and an approximate city, region and country derived from it, to prevent abuse and to help the venue check a later claim of ownership. The same people at the venue see them as for a claim. A report made at a venue’s kiosk, by its team or through its own systems keeps no address. When you change your report from its private page, the venue’s team can see what it said before each change; those earlier versions are kept and deleted with the report, and also when your details on a claim made from it are deleted. If you set an alert before 7 October 2026: your email address and what to watch for. New alerts are no longer offered; a lost report includes them.

If a venue enables optional journey details, you may add a flight or route, service date and time, seat or gate, event name, and station or seating area to your private lost-item report. Do not include passenger names, booking references, identity documents or medical information. These details are available through your private report link and to authorised venue staff; platform support access, service providers and backups follow the access and processing arrangements described elsewhere in this policy. Earlier values are retained in the report's edit history. The details follow the existing report retention and deletion periods; erasing guest details from a linked claim clears the current journey details and report versions.

A venue’s 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 the venue chose those fields. Do not provide passwords, payment information or identity documents.

Where the venue chose those fields, its team can record the same kind of private details on a found item. They are not shown on public item pages.

If you tell a venue you found something: when the venue has turned this on, the photo you send, what the item is, where and when you found it, where it is now and, only if you add them, your name, email address and phone number. Nothing from your message is published while the venue reviews it: the venue’s team and our platform administrators can see it. If the team logs the item, its photo may appear on the venue’s found items page like any found item the team logs. If you give an email address, we send it one short receipt (none if that address has had several receipts recently), and replies go to the venue. To stop receipts being used to flood someone’s inbox, we keep a coded (hashed) form of the email address and a count of receipts for two days. When the venue’s team starts logging the item with vFound AI switched on, the AI provider below reads the photo to suggest a description, as it does for any found item. Sending a message is not proof that the venue or vFound has the item.

If a venue receives parcels for you (vFound Parcels): your name, email address, room or apartment and any ID the venue adds to its list; and for each parcel, a photo of its label (showing whatever the label shows, such as your address), the carrier, tracking number and sender, handling instructions, where it is kept, any reminder snooze or hold date, whether you said you were at the desk, any delegate name and email you provide, the emails sent to you about it, and the name, optional pickup photo and, where the venue asks for one, the signature of whoever collected it. For an outgoing parcel or a delivery round, it also records the destination, courier or recipient and handover signature. Parcel records are never shown publicly: the venue’s team and our platform administrators can see them, and the AI provider below reads a label photo when the venue logs a parcel with vFound AI switched on. If the venue also uses vFound Visitors, the same list is who visitors can come to see, and you are emailed when a visitor signs in to see you.

Wrong-recipient reporting is on unless the venue turns it off, and an existing saved off choice is preserved. If you confirm a wrong-recipient report, we keep your report that a parcel is not yours, linked to the parcel and venue, the time it was reported and when staff resolve it, with the parcel's activity history. Reporting it removes its assignment to you and stops its reminders; the venue's staff check and correct the recipient. It does not identify another recipient to you. Optional parcel desk notice hours also keep scheduled delivery times, delivery-attempt states, parcel and venue references, the staff actor where applicable, and hashed forms of the recipient address and pickup code to check whether a notice is stale or duplicated. These records are not shown publicly; authorised venue staff and vFound platform administrators can access them to operate and support the service. Our existing hosting, email and backup providers process the relevant data as described below.

If a hotel links a stay to an item or parcel: the hotel may store its stable stay reference, an optional guest reference, your name, arrival and departure times, source time zone, stay state, current room and the room recorded when the item or parcel was logged. This private context is visible to the venue team and our platform administrators, never on a guest page. A room search helps staff navigate only; vFound never treats a room number as proof or a suggestion of ownership. The feature does not accept rates, payment details, loyalty data, identity documents, preferences or unrelated reservation notes. The hotel can enter this context manually, import it by CSV or API, or, on vFound Enterprise, connect its own Cloudbeds property key limited toread:reservation. Connection credentials and the sync cursor are encrypted, and the hotel can revoke access in Cloudbeds or vFound.

If you leave things at a venue's checkroom (vFound Checkroom): what you handed in and a photo of it, its number and, for a multi-piece ticket, each piece's letter, type, storage location and hand-back state; and, if you give them, your name, email address and room; the language of your ticket; its station, event and storage location; a request to have your things ready; any fee and whether the venue records it as cash or an external POS or card payment; when each piece was collected, and who collected it, with a signature when the ticket was lost. Your ticket is a private page whose long random address is the only key to it. Tags on your things show only the ticket and piece number, type, station and, on a bag tag, where it is stored; they never show your name, email address or room. The ticket’s QR code is printed only on the stub you keep. Checkroom records are never shown publicly: the venue’s team and our platform administrators can see them. If your things are still there at closing, the venue may move them to its lost and found, with your details in its private notes so it can contact you. If you lose your ticket and the team uses vFound AI to find your things from a description, the AI provider below compares that description (with email addresses, links and phone numbers removed) with the photos and the type of that night's checked-in items. Ticket notes and the name, email address and room on any ticket are never sent, and the team still checks who you are before handing anything back. If the venue lets you reserve luggage space ahead (only when the venue turns this on): your name, email address, language, the number of pieces, the time window you chose, whether you arrived, cancelled or did not come, and the checkroom ticket it became. We email you a confirmation with a private link to see or cancel the reservation. In the reservation record we keep only a scrambled (hashed) form of that link's key. Your confirmation email contains the full private link; its queued copy is encrypted. If the team links your event ticket or wristband code to your checkroom ticket, we keep only a keyed hash of that code, never the code itself, and only while the link is active.

If an Enterprise venue enables Checkroom phone alerts, you may choose SMS, WhatsApp, both or neither at drop-off or self check-in. We record only your explicit choice for that ticket. We keep the alert number encrypted, a keyed fingerprint used to recognise a stop request, your channel choices, language, consent wording version and consent and withdrawal times. The venue uses its own messaging provider and pays its provider directly. That provider receives your destination number and a message containing the venue name, a short ticket, ready-for-collection or left-behind status and your private ticket link; the message does not include your name, email, room, item description or photos. Anyone with that private link can open the ticket, so keep it private. You can stop alerts from the ticket's Phone alert settings. Where the venue has connected its provider's reply webhook, replying STOP also withdraws alerts for that number within that connection's venue or group. Stopping both channels clears the stored alert number and fingerprint; it does not stop separate email updates or recall a message already started or accepted by the provider. We retain consent records for the ticket's lifetime, except that correcting the email address on a ticket erases its alert choices and consent records at once; orphan records are removed in nightly cleanup. Delivery-attempt records, without message bodies or phone numbers, are deleted after 30 days. Existing Checkroom ticket and backup retention periods still apply. The venue must manage its provider's own records, opt-out lists and retention separately.

If you borrow something from a venue's desk (vFound Equipment): your name and, if you give them, your email address and an ID or reference such as a student number, room or department; what you borrowed, when, and when it is due back; the emails sent to you about it (a receipt, reminders, reservation notices and a return receipt, with one receipt for things from the same checkout brought back together), in the language chosen for you; your signature where the venue asks for one; any reservation you make, whether it needed approval, its dates and status; an extension request or problem report you send; and when each item came back, in what condition, with any note or photo the team takes. An equipment item can also hold a serial number, replacement value, purchase and warranty dates, venue-defined custom fields, maintenance history and stock-take dates. We also keep equipment status changes and their times for utilization reports. If a team member chooses warranty reminder emails, we keep their choice for that venue and a record of each delivery attempt, linked to the item, warranty date and team member. These records are deleted with the venue; item-linked records are also deleted when the item is deleted. These records are never shown publicly: the venue’s team and our platform administrators can see them. The AI provider below only ever sees a photo of the equipment a venue adds, never who borrowed it. When authorised venues in one customer group move an item, vFound also records its owning, source, destination, service and custody venues, locations and codes, transfer status and times, operational notes and which team members performed each step. Borrower and staff history from the source venue is not shown to the destination through the transfer.

If you visit a venue that uses vFound Visitors: your name, who you came to see and when you arrived and left (including whether you were signed out automatically); if you or the venue give them, your email address, company and the reason for your visit, your answers to questions the venue sets, a time you are expected, the dates your pass is valid and whether it repeats; the language of your emails and the invitation sent to you; whether the venue approved or denied the visit; any short reply your host sends to the desk; and, where the venue has visitor terms, a copy of them, that you agreed, and your signature where the venue asks for one. During a roll call the venue also records whether it marked you safe or missing, when, and which team member did it. Your pass is a private page whose long random address is the only key to it. Once the venue has approved the visit it may show arrival information the venue chooses to share, and the venue’s Wi-Fi details while you are signed in. Printed badges carry only a short desk code, never the pass address. A venue can optionally require a private visitor photo, which its authorised team and our platform administrators can see and which can appear on the printed badge. A venue can also require a staff member to record that they visually checked a physical photo ID; we keep who checked it and when, but no image or number from the ID. vFound does not verify document authenticity, compare faces or run a watch list, and visitor photos are not sent to vFound AI. If the venue’s team pastes or forwards a meeting invite with vFound AI switched on, the AI provider below reads it to suggest the expected visits (names, email addresses, companies, host and time), with links, passcodes, phone numbers and place lines removed first; the team checks each visit before it is created. An invite forwarded by email is kept for up to 30 days. Visit records are never shown publicly: the venue’s team and our platform administrators can see them. The visit, its optional photo and its staff check record follow the same 7 to 365 day retention chosen by the venue or visitor type. When you sign in, the person you came to see is emailed your name and, if given, your company and reason. A Slack, Microsoft Teams or Google Chat channel the venue connects is told only the name of the person you came to see.

If a venue enables invitation preregistration, you can use your private visitor pass to provide your company, answers to the venue's visitor questions, a visitor photo when requested, and your agreement to the venue's current visitor terms before arrival. We keep these details and the completion time with your original visit. If a venue enables event signup, we also record which event you registered for, with your name, email address and visit details. A venue may publish written visitor induction instructions. If it enables induction acknowledgements, we keep the version you acknowledged, the acknowledgement time and its expiry with your visit. A valid acknowledgement can be reused for repeat arrivals on the same private pass; we do not transfer it to another pass merely because its email address matches. Acknowledgement records what you confirmed reading; it is not a test or certification. The venue's authorised team can view these records, subject to the support and provider access described elsewhere in this policy. Anyone you share a private pass with can use its preparation form. Invite-only event signup links may also be forwarded; they do not verify an email identity.

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.

If a venue enables visitor delegation, a host may name up to ten people already on that venue’s people list as delegates. We record the host and delegate references, when the delegation was made and, if ended, when and how it ended. A current delegate can use their private My vFound link to see the names and expected or sign-in times of that host’s approved, confirmed visits and send an arrival reply. The page also shows the host’s name and the current arrival reply, but not the visitor’s contact details, company, purpose, photographs or answers. The visit history records the delegate’s name and identifier when they reply. A delegate cannot approve a visitor’s entry. Hosts and delegates can end a delegation, and the venue’s owners and managers can end it or switch delegation off. Switching it off ends existing delegations permanently.

If a venue enables unanswered-arrival escalation, we keep its waiting-time setting and optional backup-person reference. We show overdue unanswered confirmed arrivals to the venue’s authorised team and record who marked an arrival followed up and when. A delegate notice emails the host and venue names, the sign-in time and a private link; an escalation email names only the host and venue. We keep arrival, delegation and recipient references and notice-attempt status to prevent duplicate attempts. Replies and follow-up stop pending escalation, but a message already being sent cannot be recalled. An interrupted or uncertain attempt is not automatically resent.

If a venue creates visits from calendar invitations: we receive the organizer and attendee names and email addresses, the meeting identifier, sequence and times. We discard the meeting description. The pending invitation details are encrypted in our database. If the sending mail server cannot be verified, no visitor is emailed until the organizer confirms a signed link, and a change to an invitation already confirmed is kept apart, unused, until then.

If you run a venue: your name, work email, business name, venue code, password (stored only as a hash), team members you add, your chosen workspace language, the address guest replies should go to, and your activity in the workspace (including an audit record of security-relevant actions such as sign-ins, staff changes and claim decisions). Owners and managers can download their venue’s audit record for any period we keep it, up to 20,000 events in one file: when, which team member (or vFound support), what happened and which record, never addresses, passwords or guest contact details. When you sign up for a new venue, that record also holds the internet (IP) address the sign-up came from and the one your email verification link was opened from, each with an approximate city, region and country derived from it. Only vFound's platform administrators see them; we use them to spot fake or abusive sign-ups. Basis: our legitimate interest in protecting the service.

Before your card is confirmed: when you send the sign-up form we do not create a sign-in, a venue, a venue code or an account. We keep a pending sign-up while you are in Stripe Checkout: your name, email, business name, the products, venue code and currency you chose, your password (stored only as a hash), the internet (IP) address and browser the form came from and the language of the page. The personal parts are encrypted in our database, and nobody can sign in with it. When Stripe confirms your card, your account is created from it and the pending sign-up keeps only the link between your Stripe subscription and your venue. If no card is confirmed within 24 hours, the pending sign-up is deleted. Basis: steps you asked for before entering a contract.

When a team member signs in or uses the workspace, we record the time (not the page, address or device) so we can see how venues use vFound, support them and improve the service; only vFound's platform administrators see it. The last sign-in time and the last activity time are kept for as long as the person's account exists, and go when the account is deleted. They belong to the person, so for someone who works at several venues they reflect their activity across all of them.

If your organisation groups several venues: we keep the group name, the venues and optional region assigned to each one, group members and their group or regional roles, group policy templates, and an audit history of group, access, venue and policy changes. The command centre returns aggregate operational counts and account health for venues within that person's group and region, and lists the open work of each product open at those venues: item titles, claim status, the title, category and date of open lost reports, parcel recipients and units, checkroom ticket numbers and guest names, equipment and who has it, and visitor and host names, as that venue's own team sees them. These lists never include a guest's email address, phone number, borrower reference, checkroom room or message, nor the name, address or photo of the person who reported a loss. A person receives any other record detail only after opening a venue they are authorised to use. To answer a request from a guest, a group owner, manager or regional manager can enter that guest’s full email address or phone number to see which of their venues with Lost & Found open hold a lost report, claim or finder record with it; the result shows only the venue, the kind of record, its reference and date. The search is recorded in the group’s activity without the address or number.

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 the venue’s own lost and found page, including the internet (IP) address it came from and the approximate place derived from it. Matching across a group’s venues is off unless the group’s owner switches it on. While it is on, each open lost report is compared with the found items at the group’s other venues. People in the group who have a role at both venues, within their region, can see what was lost and found, where and when, and the two venues. The matches do not show the reporter’s name, email address, phone number, the address the report came from or any photo; opening a record shows only what the person’s role at that venue already shows. Private details recorded on a report or item may be used to order the matches but are not shown in them. Guests are not told about matches at other venues. A venue that leaves the group stops appearing in them at once.

Enterprise service reports contain platform status samples and incident notes, plus aggregate support request counts (from Help & support in the workspace and the contact form while signed in) and first take-up times. We match a request to a group when submitted only if it was sent while signed in to vFound as an active owner or manager of exactly one active group, from that login’s own address. Other requests are excluded. Membership changes do not reassign earlier requests. Messages and contact addresses are not included in the report.

If you contact vFound support: from the contact form while you are not signed in to a workspace, or with the Enterprise topic, we keep your name, email address, organisation, the topic you choose, the number of sites you give and your message as an enquiry record in vFound. A person on our team answers it by email, from our Google Workspace mailbox (section 4) or from vFound. Each enquiry and each support request has its own reply address at vFound, which our emails about it use: your replies to them, and the replies our team sends from the company mailbox to that address, are kept with the conversation in vFound. We keep its stage and notes our team writes for itself, which are never sent to you. Copies of the conversation, including copies of replies we write in vFound, may be delivered to our company mailbox. If you email someone at vFound directly, we may forward that email into vFound, where it becomes an enquiry record in the same way. Attachments in an enquiry conversation, and attachments our team sends, are passed on by email, up to 10 MB in total; vFound keeps only their names, types and sizes. If you send the contact form on another topic while signed in to a workspace, or use Help & support in the workspace, it becomes a support request for the venue you are working in: we keep your sign-in name and email address, the topic, subject and message, and that venue, its products and the page you came from (Help & support shows these before you send; the contact form names the venue). Your later messages in the workspace, verified replies to our support email and our replies are kept with the request in vFound’s support records, together with notes our team writes for itself, which are never sent to you. In the workspace, a venue’s owners and managers can read all of that venue’s requests and other team members see only their own. A reply by email joins the conversation only when it comes from the email address the enquiry or request was sent from, or, for a workspace request, from the current sign-in of its sender who still has access, or an owner or manager of the venue. A reply from our company mailbox joins it only when it comes from that mailbox’s own address. We check that the delivering mail server is authorised to send for that address’s domain. When a message reaches a valid ticket address but fails our checks, we send the reason and up to 10,000 characters of plain text, without attachments, only to vFound’s owner notice mailbox for review. It is not added to the ticket thread. The admin ticket shows a count of these held emails; the notice record keeps no sender address or message text. Messages over the daily limit are also held for owner review. Unknown ticket addresses, automatic replies, delivery reports and duplicates are ignored without an email response. We keep each support conversation, with our replies and notes, for 24 months after its last message or change, then delete it together with the record of any held emails (section 6). Enquiries from the contact form, with their stage and notes, are kept for the same period. The metadata of a held forwarded email that creates no enquiry is deleted after 24 months. Copies of enquiry emails in our company mailbox (Google Workspace), with our notices about them and our replies, are kept there until we delete them.

Enterprise venues may define custom attributes on all five products. We keep field labels, types, choices and the values staff enter, plus workflow checklist labels, answers, notes, staff identity and completion times. They are available to authorised venue staff and platform administrators, and through the private API, configured webhooks and exports. Required fields and checklists never block guests, kiosks or self-service. Values follow their product record retention; orphaned completions are removed nightly. Claim guest erasure removes its completed checklists. Venue definitions go with venue deletion; group definitions are deleted 24 months after group closure. Enterprise expiry deletes none of these records and stops checklist requirements.

If a group configures operating policies: we keep the policy name, permanent numbered versions, their rules and service-level targets, venue assignments, local exception reasons and optional expiry dates, acknowledgements, aggregate breach counts and alert-notification times. Reports and escalation emails contain counts, policy and venue names, not claimant, visitor, parcel or other operational record details. Assignment and escalation notices go to active group owners and managers who are authorised for the affected venue; a regional manager receives them only for their region. Replies go to the group manager who performed the assignment or the group owner. These records do not make operational decisions or change payment access.

Items your team logs: photographs, descriptions, storage location, internal notes and return records. Photographs and descriptions your team publishes are public on your venue page and, if your customer group turns it on, the titles and photographs of those items also appear on the group’s organisation page with your venue’s public label; internal notes and claimant details never are. When venues in one customer group send a found item from one venue to another (a terminal desk to a central store, for example), vFound also records both venues, where it was kept and where it goes, an optional note, the times and which team members sent, received or took it back. The item, its photos and its history then belong to the receiving venue, and a hotel stay linked at the sending venue is removed from it. While it travels it is on neither venue’s public page. An item with a claim is never sent, so a guest’s claim stays with the venue they claimed from.

If your venue uses email to inventory: each venue has a private address that its own team can email or forward photos to. Only mail that a team member’s own mail system really sent is accepted; mail from anyone else is dropped and not kept. For each accepted photo we keep a draft with the photo (saved again without the location or other details the phone added), the sender’s email address, the subject and the first 500 characters of the message, until someone logs or discards it. The photo file is deleted as soon as the draft is logged or discarded, and with vFound AI on, the AI provider below reads the photo to suggest a description. Every draft, with its sender, subject and note, is deleted 30 days after it arrived, whether or not it was logged.

If a venue connects its people directory: we receive the name, email, room or department, reference, language, active status and external identifier the venue sends. A CSV link is encrypted in our database; we also keep its host, sync mode, last run time and row counts. Automatic provisioning creates people-list entries only, never staff accounts. A person's signed My vFound link shows the parcel, visitor-host and equipment records linked to that person. If the venue enables its private Equipment catalogue, the link also lets its holder browse that venue's equipment names, categories and photographs and request individual items, category quantities or a saved kit for selected dates. We link the request to the existing borrower record and keep its selected equipment, dates, group membership and approval status with the venue's Equipment reservations. An availability preview does not reserve equipment. Anyone holding the current link can open it, so keep it private. Each link works for 60 days, and each new service email carries a fresh one. Earlier links stop working when the person’s email changes, when they are deactivated or removed, or when an owner or manager resets their link. A venue’s owners and managers see each person’s full email address; other team members see it masked. Deactivation also stops new records from being assigned to that person. It does not erase open operational records; owners and managers can review their counts until the venue resolves them.

If the venue enables equipment specifications, its team can write technical descriptions for borrowers to read in the private equipment catalogue. Staff should not put personal information, internal notes, item values or serial numbers in those descriptions. If the venue separately enables reservation history and change requests, the holder of your current private My vFound link can view your reservation or group, recorded status changes and requested changes. We record proposed dates, equipment quantities, an optional note of up to 1,000 characters, the request time, and the staff decision and time with the reservation. Authorised venue staff can review these records; platform support access, hosting, service providers and backups follow the arrangements described elsewhere in this policy. A request does not itself change or approve the booking. Staff may accept or decline it; acceptance checks availability and booking rules again. Do not include identity documents, payment details or sensitive personal information in a note. No attachments are accepted.

Card validation and payments: Stripe validates the card for a trial and handles vFound subscription billing. We store the customer, Checkout and subscription or payment references, amounts and status, not your full card number. A venue may record that it collected a Checkroom fee as cash or through its own external POS or card terminal, but vFound receives no guest payment or card details.

Technical: application logs of errors and events, which can include an IP address and the page requested, kept to keep the service running and secure. Our web server keeps no access log. To notice an email link that stops working, we keep a count per day of how each kind of link in our emails ended (opened, ended or not found), with no address, token, IP address or person attached, for 90 days. A paired kiosk (for visitor sign-in, parcel arrivals, equipment self check-out or checkroom self check-in) keeps a random, encrypted token in an essential cookie and we keep its venue, device name, permitted actions and last-seen time. The kiosk never stores a people list in the browser.

If you turn on browser alerts: the browser’s push address, public encryption key and authentication token, its stated expiry (if any), recent delivery result, and the account, pass, ticket or service-email record that authorised it. The address and keys are encrypted in our database. We do not receive a device identifier, contact list or the other sites you visit.

If a venue enables private Checkroom ticket conversations, we store message text, whether it came from the guest or desk, and its sending time, linked to the venue and ticket. Anyone holding the private ticket link can read retained messages while the feature and venue’s Checkroom access remain available, and can send messages while the ticket is pending, checked in or left behind. Authorised venue members can read messages; owners, managers and staff can reply. Existing platform support and service-provider access arrangements apply. Message text is encrypted in the application database. Messages stop appearing after 30 days and are deleted by routine pruning, or when the ticket or venue is deleted sooner. Turning conversations off hides retained messages and prevents new messages; it does not immediately erase them. Existing backup retention applies. For checked-in or left-behind tickets, staff can request an email containing a private-ticket link without conversation text. Replies go to the venue’s configured reply address and are not automatically added to the conversation. Do not send identity documents, payment details or sensitive personal information. Keep the ticket link private.

Accepted-terms copies are on unless the venue turns them off; an existing saved off choice is preserved. Your current eligible private visitor pass can show a printable copy of the visitor terms stored as accepted for that visit, their SHA-256 digest and recorded acceptance time. This uses the stored text, not the venue's replacement terms. Anyone holding the private pass link may access the copy while access remains available. Access ends when the relevant option is disabled, the link is revoked or expires, the venue or Visitors access is unavailable, or the visit is deleted. A copy you print or save remains under your control.

If your venue enables visitor feedback, you may choose to give one rating from 1 to 5 and an optional comment of up to 1000 characters linked to your visit record after signing out, including between sessions on a recurring pass. Feedback does not affect entry or approval. Authorised venue members with access to visit records and vFound platform administrators operating or supporting the service may read the response. Existing service-provider and backup access described in this policy also applies. Do not include identity documents, payment details or sensitive personal information. A feedback invitation email is sent only when the venue allows it and you request one through your private pass, using the email address and pass token present when you requested it. Changing either clears the active email choice and requires a new request. The email contains the venue name and a private feedback and preferences link, not your response. You may turn that email choice off before sending starts or opt out of feedback for that visit. A message already being sent cannot be recalled.

Optional public website analytics

If you accept analytics on our public marketing website, Google Analytics receives the public page path, language, broad traffic and device information, an analytics cookie identifier and clicks on trial and demo links. Google receives your network address when your browser contacts it. We strip URL query strings and fragments, send only the origin of the referring website, and send no form answers, names, emails, account IDs or private record links. Analytics is excluded from signed-in pages, venue websites, registration, claims, guest passes, kiosks and administration. A trial-link click measures interest, not a completed signup or a paid subscription.

When a venue records who handed in a found item, we keep the name, email, phone, affiliation and request for an unclaimed-item notice that its team enters, with the receiving team member and time. These details are available to the authorised venue team and platform administrators supporting the venue, and are never shown on public item pages. Staff can send a hand-in receipt or an unclaimed-item notice to the supplied email address; no unclaimed-item notice is sent automatically. Owners and managers can erase the finder’s contact details and notice preference while keeping a history entry without those values. Details otherwise remain with the item until the item or venue data is deleted; protected backup copies age out under the existing backup periods. When venues in one customer group send a found item from one venue to another, the finder’s details recorded with it go with the item. At the receiving venue they are available to its authorised team and platform administrators supporting it, can be erased by its owners and managers, and are kept and deleted under that venue’s rules. Between venues that are not in the same customer group, items are never sent. Erasing finder or claimant personal details also replaces the venue’s stored retry responses with an empty-data refusal, including responses containing identification-check notes. Staff-contact and finder emails share limits of 50 per venue and 3 per recipient address per venue-day, including confirmed resends. Coded recipient, date and count records enforce these limits even after an item or claim is deleted; they contain no email address and remain until venue data is deleted. Unclaimed-item notices are checked again before sending and dropped if the preference, address, venue or unclaimed holding state no longer permits them. Queued staff-contact and finder emails are dropped if their reserved venue-day has ended.

A venue’s team can enter a possible owner’s name and email to open a private claim and send that person an invitation to discuss collection, including for an item whose photo is private. This is a possible match, not a decision about ownership. The claim follows the existing claim access, correction, deletion and retention rules. At handover, staff may record the type of identification they checked and a short note; they are instructed not to enter identification numbers. Release receipts show the identification type, the handover and any recorded pickup signature or shipment tracking, but exclude finder contact details, internal item notes and the identification-check note.

3. Why we use it, and our legal basis

• To provide the service: publishing items, routing claims, sending service email, taking payment. Basis: performance of a contract.
• To keep it secure: bot protection, rate limiting, fraud and abuse detection, audit logs, backups. Basis: legitimate interests in protecting our service, our venues and their guests.
• To help a venue assess a claim or a lost-item report: including the submitting IP address and approximate city, region and country. Basis: the venue’s legitimate interest in not handing property to the wrong person.
• To meet legal duties: accounting and responding to lawful requests. Basis: legal obligation.
• To answer your enquiries. Basis: legitimate interests, or consent where you gave it.
• To send optional browser alerts you request. Basis: your consent, which you withdraw by turning them off on that device. Email continues independently.

We do not carry out facial recognition or biometric identification, and we never identify a person from an image. When a venue uses vFound AI, it compares descriptions and photos of items, never of people, to suggest possible matches and to help staff check a claim. These are suggestions only: we make no decisions about you by automated means that produce legal or similarly significant effects, and a person at the venue decides every claim. Nothing vFound AI suggests is applied to a record or sent to a guest until a person at the venue confirms it. The suggestions themselves are kept so the team can see them again: item descriptions and search words, match verdicts for lost reports, claim checks, weekly insights and the wording of the daily summary. See section 6 for how long.

To improve our public website and understand demand: optional analytics uses your consent. Rejecting it does not affect the service. You can withdraw through Analytics preferences on a public page.

4. Who we share it with

Your claim is visible to authorised staff at the venue handling your item, and to our platform administrators who operate and support vFound. If the venue connects other services, such as Slack, Microsoft Teams, Google Chat or its own systems through our API and webhooks, the details that service receives go there on the venue’s instruction. A member of the venue’s team can also add a private calendar link to the calendar app they choose; that app then reads upcoming visits, equipment due times, luggage collection times and booked pickups, including the names shown with them. A directory, published CSV or hotel property system a venue connects is chosen and controlled by that venue; it is not our service provider. Property-system and coworking-member connections store their credentials and settings encrypted and read only the minimal stay or member context described below. The same is true of an AI assistant a venue owner or manager connects to vFound by signing in (for example through its connector for our MCP server): it receives the records its tools return, only within the permissions the venue chose and for the products the venue has open, and its provider handles them under the venue’s own agreement with it. We keep a record of each connection (the assistant’s name, the address it returns to, who connected it and when it was allowed, renewed and disconnected) and store only fingerprints of its codes and tokens. Beyond that we share data only with the providers below, for the purposes shown:

• OVHcloud: hosting of the application, database and uploaded files, in Singapore. Photos a venue’s team emails to vFound, and replies to our support and enquiry emails, arrive at our own mail server on this hosting.
• Resend: sends our service email, such as claim, parcel, visitor, account and support emails, 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.
• Stripe: trial card validation, vFound subscription payments, payment contact details and receipts. We store payment references and status, not full card numbers.
• Cloudflare: Turnstile bot protection on every public form that asks for it: sign-in, registration, password reset, contact, claims, claim and report lookup, lost reports, photo search, found-item messages, the lost-item chat, checkroom self check-in, visitor self sign-in, visitor registration and the luggage reservation form.
• ipapi.co: converting the IP address a claim, a lost-item report sent from a venue’s lost and found page or a new venue sign-up came from into an approximate city, region and country. Private and internal addresses are never sent.
• OpenRouter (OpenRouter, Inc.): an AI gateway used when a venue keeps AI assistance switched on: to read a found item's photo and suggest its details and search words; to read a parcel's label photo and suggest who it is for, the carrier and the tracking number; to suggest a name for equipment a venue adds, from its photo; to compare what a guest describes, and any photo they choose to add, with found items to rank possible matches, when they report a loss and again when the venue logs a new item or looks for matches to their report; to help the venue's team check a claim against their record of the item, including its private description and internal notes, and any proof photos the claimant uploaded; to translate messages between guests and the team and draft the team's replies; and to turn a guest's lost item chat into a report; to turn what a team member types in Ask vFound into a suggested action (phone numbers are removed first, and the records it finds are never sent); to tell whether a photo taken with the workspace camera shows a found item or a parcel label and read it (QR codes and barcodes are read on the device and not sent); to read a meeting invite the venue pastes or forwards and suggest the expected visits; to compare a description of a checkroom item with that night's item photos and item types, never ticket notes or a guest's name, email address or room; to cut a photo that shows several items into one photo per item; to compare a newly logged item's photo and description with up to three earlier items to flag a possible duplicate; to word the daily summary on the workspace home page and the checkroom's end of night summary, from counts only, never names; and to write a weekly read of the venue's numbers, from the venue's name and aggregate counts, rates, item categories and the places guests said they lost things, never a guest's name or contact details. That weekly read is shown on the dashboard and emailed every Monday to the venue's owners and managers unless the venue switches the email off. A guest's search photo is used for that one search and not kept by vFound; a photo a guest adds to a lost report is kept with the report, as described above. Photos of items already flagged as showing personal details (an ID, a card, a lit screen) 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: the AI is only told that an answer was given. Proof photos a claimant uploads are the exception: when AI is on for the venue they are sent as supplied, because nothing can tell what they show first, so please do not upload identity documents or cards. The lost item chat never asks for a guest's name or contact details, and the form that collects them is not sent to the AI. AI suggestions never decide a claim: the venue's team makes every decision. OpenRouter passes the request to the AI model's provider: Google, with an OpenAI model as a backup run by OpenAI or Microsoft Azure. Every request asks for zero data retention, so it only reaches a provider that keeps no copy and does not use it to train models, and OpenRouter itself keeps no copy of the content and does not train on it. These providers may process the request in the United States or other countries. Venues can switch AI off at any time.
• Google (Google Workspace): our support mailbox, armaan@vfound.io, which receives the messages and requests people send us, and our own notices about venue accounts: sign-ups, trials, payments, cancellations and closures, and when a private walkthrough is opened, played or finished: the walkthrough and the name of the person or organisation it was prepared for, the time, the type of device and, if you pressed Allow, how far it was played. These emails stay in that mailbox until we delete them.
• IndexNow (used by Bing and other search engines): the addresses of our public pages and venue pages listed in our sitemap, when they are new or changed, so search engines find them sooner. Only those public addresses are sent, nothing from private records.

We may also disclose data where the law requires it, to protect our rights or someone’s safety, or to a buyer as part of a merger or sale of assets (you would be told beforehand). We never sell personal information.

Customer-configured CRM destinations: Selected webhook events may be sent to systems a venue chooses, such as its CRM. Extra report contacts are sent only after a separate explicit choice, and the source record and transport are checked again before each send. 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.

Google Analytics: consented public marketing measurements only, under Google's analytics processing terms. Advertising personalisation, Google signals and user-provided data collection are disabled. Google may process this information in the United States and other countries. It is separate from the records we process for a venue under our DPA.

5. Where your data is held

Our application, database and uploaded files are hosted by OVHcloud in Singapore. An encrypted copy of our backups is kept in Canada, where we are based. Our AI, payment, bot protection, email delivery and support email providers may process data in the United States and elsewhere. Where personal data is transferred out of the EEA or the UK, we rely on an adequacy decision where one applies (such as for Canada), or on Standard Contractual Clauses (with the UK Addendum where relevant) together with appropriate safeguards.

6. How long we keep it

• Items and claims: for as long as the venue keeps them, under the retention and disposal policy the venue sets. Items expire from public view on the venue’s schedule. A venue can delete a guest’s details from a finished claim at any time. The record of a found item sent between venues is kept with the item and deleted with it.
• Support conversations: an enquiry from the contact form (with its stage) or a request from Help & support in the workspace, every later message, our replies and our team's notes are kept for 24 months after the conversation's last message or change, then deleted, together with the record of any emails held for review. Enterprise service reports count only requests that are still kept.
• Parcels: while a parcel waits, and for 12 months after it is collected or returned; then the record, its label photo, pickup photo and any signatures are deleted. Wrong-recipient reports and parcel-notice scheduling and attempt records are kept with the parcel while it waits and for 12 months after collection or return, then deleted with it, or sooner when the venue's data is deleted. Unresolved waiting parcels keep these operational records. Venue notice-hour and recipient-reporting settings remain until venue deletion. Setting-change security audit records follow the existing audit retention period. Copies in backups follow the existing backup retention period. Finished outgoing parcels follow the same 12-month period. Expired delegate codes and served desk-arrival rows are deleted after 30 days. A venue can remove a person from its list at any time, which also removes their name from parcels already collected or returned.
• People and directory settings: a venue keeps people until it removes or deactivates them. Connected-directory details and people-list entries are deleted with the venue account after the 90-day closure period. Removing or deactivating a person, changing their email or resetting their link immediately invalidates their earlier My vFound links, and each link expires after 60 days. Open parcels, equipment checkouts, reservations and visitor records keep their normal retention periods and remain available to the authorised venue team for resolution.
• Checkroom tickets: deleted, with their piece records, hand-back proofs, photo and any signatures, 90 days after all the things are handed back; a ticket left at closing is kept 12 months from that closing. A self check-in nobody handed anything over for is deleted after two days. An event is deleted 12 months after it ends once no ticket refers to it. Station names, number ranges and storage locations stay until the venue deletes them or closes its account.
• Luggage reservations: deleted 30 days after the end of the reserved time window, whether you came, cancelled or did not come. Time windows nobody reserved are deleted 30 days after they end.
• Equipment: while the item is out, and for 13 months after it comes back or is marked lost; then the record, any photo taken on its return and any signature are deleted. Collected or cancelled reservations and completed stock-takes are also deleted after 13 months. Completed equipment-transfer records, including their venue, custody, location, status and note history, are deleted after 24 months. The items a venue hands out, with their photos, asset details and maintenance history, stay until the venue closes its account.

  Reservation change requests and recorded status history are deleted with their related reservation. Collected or cancelled reservations are removed after 13 months without an update. Removing the borrower from the venue’s people list deletes their change requests and recorded reservation history sooner; venue deletion also removes them. Turning the feature off hides these records but does not erase them. Copies in protected backups follow the existing 30-day backup retention.

• Hotel stays: a stay with no linked item or parcel is deleted 13 months after its last known date (its departure, or if it has none its arrival, or if it has none the time it was last updated), whether or not the source ever marked it departed or cancelled. If an item or parcel still refers to it, its minimal context follows that record and is removed after the record no longer needs it. All remaining stay context is deleted with the venue account after the 90-day closure period.
• Visits: the venue chooses 7 to 365 days for the venue, 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. That period starts when the visit ends (you are signed out, or an invitation is cancelled or not used); then the visit, its optional visitor photo, its staff visual-check record, its sessions, roll-call entries, courier link and any signature are deleted. Calendar invitation details with no visit are deleted after 30 days. Anyone still signed in after the day ends, in the venue’s time zone, is signed out automatically once they have been signed in for 12 hours.
• Lost reports: watched for 90 days, then kept with the venue’s records. The address a report was sent from, its approximate place and any photo the guest added are kept only as long as the report and are deleted with it, and also when the guest’s details on a claim made from the report are deleted, or when an owner or manager deletes the guest’s details from the report. Alerts (set before 7 October 2026; no new ones are made): 60 days from the day they were set, then deleted 30 days after they end.
• Reports recorded by staff: 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 the venue’s data is deleted.
• Found-item messages: deleted 30 days after they arrive if the venue’s team does not deal with them, 7 days after the team declines one, and 30 days after the team logs the item. The message’s own copy of the photo is deleted as soon as the team logs the item or declines the message; a logged item keeps its photo like any found item, and none of your contact details.
• Customer groups: active group membership, venue-region mappings and policy templates remain while the group is active. Group activity records are deleted after 24 months. Closing a group removes group access immediately; its remaining membership, venue mapping, operating-policy versions, assignments, exceptions, acknowledgements and alert and completed equipment-transfer records are deleted 24 months later. A venue’s owner can take their venue out of a group at any time, which ends group access to it at once. Removing a venue from a group stops its policy assignments, exceptions and open alerts. Removing a venue or closing the group does not delete that venue's account or operational records.
• Matches across venues: kept only while the group has matching switched on. Switching it off, erasing the report or deleting either venue removes the stored matches, and they are deleted with the group’s records 24 months after the group closes.
• A sign-up whose card is never confirmed: a pending sign-up is deleted 24 hours after it was made if Stripe has not confirmed a card by then; no sign-in, venue or account was ever created for it. A venue created before 15 October 2026 that has not started its trial through Stripe Checkout 48 hours after sign-up, never opened Checkout and holds no records, is deleted with its sign-in and its audit record (including the sign-up addresses). You can sign up again at any time.
• After an account is closed: the venue’s owners and managers can still sign in for 90 days to download the exports listed in the Data Processing Agreement, or ask us to reopen it. After 90 days we permanently delete the venue’s data, except billing records, the venue code, which stays reserved so a printed QR sign can never lead to someone else’s venue, and the sign-in of an owner who still has another venue (kept with this venue’s details emptied, and deleted when that other venue is deleted); copies in backups are deleted within 30 days after that.
• Billing records: kept as long as applicable Canadian law requires, normally six years.
• Connector sync history: when a venue connects a hotel property system or a people directory, the time, outcome, counts and any error message of each sync run are deleted 90 days after the run.
• What vFound AI wrote for the team: item descriptions and search words, match verdicts for lost reports and weekly insights are deleted 13 months after they were written, like the records of AI use; the wording of the daily summary is deleted after 30 days. A claim check is kept with its claim and is deleted when the guest’s details on that claim are deleted or when the venue’s data is deleted.
• Whether an email was delivered: for each email we send, whether it was delivered, bounced or marked as spam, with the provider’s reason (any email or IP address removed), the recipient’s domain and a one-way hash of the address, never the address itself; deleted 90 days after the email was sent, or sooner with the venue’s data.
• Photos emailed to a venue’s address: the draft, its sender, subject, note and photo are deleted 30 days after they arrive, logged or not; the photo file goes sooner, as soon as the draft is logged or discarded.
• Logs: the logs our application, PHP and mail server write 7 days (the server’s system journal, which records service start and stop messages, is kept by the operating system under its own limits and is not part of that 7 days); the audit record of security-relevant actions 24 months (including the sign-up addresses described in section 2); records of AI use 13 months; meeting invites forwarded to vFound Visitors 30 days; encrypted copies of the webhook deliveries a venue sends to its own systems 30 days; answers kept so an API request can be retried safely 24 hours; background tasks that could not finish, with the details they were working on, 30 days; the record of an AI assistant connection 90 days after it is disconnected; error reports 90 days after the error was last seen. An error report records a fault in vFound itself (on our server or in vFound’s own code in a browser): its type, where in our code it happened, the page’s address with any record numbers removed, and how often it happened. Before a report is stored, email addresses, numbers, codes and any quoted text are removed from its error message, and a database error keeps only the database’s reason, not the values being saved. It does not read what was submitted or your account. A report sent by a browser is counted against its sender’s address for 24 hours, so one sender cannot flood the reports; that count is kept under a keyed one-way hash and the address itself is never stored with a report. A plain-language reading of each new report, from the same AI providers named in section 4, is added for the owner. A private calendar link stops working when its owner replaces or removes it or leaves the team, and is deleted after 180 days without use.
• Browser alert addresses: until you turn alerts off on that device, the browser expires the address, the account or private record that authorised it is deleted, a host’s My vFound link is reset, their email changes or they are deactivated or removed (for alerts about their visitors), or delivery keeps failing. A failed address is deleted after 30 days. Access to the related venue and product is checked again before every alert.
• Private walkthrough records: each record of a page load, with anything you allowed us to note about watching, is deleted 12 months after the page was opened. A marker that an email about a walkthrough was sent (which walkthrough, which kind of email and its date, with no device or playback detail) is kept without a time limit so the same email is never sent twice. Copies in backups are deleted within 30 days after that.
• Backups: daily backups are kept for 30 days, so deleted data can remain in them for up to 30 days. Archives made when we moved vFound to new servers in September 2026, on our server, are kept only in case the move has to be undone, and are deleted once we confirm it is complete.

Delegation relationships, including ended delegations and their timestamps and revocation record, remain until the host or delegate is deleted from the people list or the venue’s workspace is deleted. Ended relationships disappear from the workspace’s recent-delegation list after 30 days; this does not erase the stored relationship. Pausing a person removes their access but retains the relationship. Arrival follow-up records, notice references and statuses, and delegate reply attribution are kept with the visit and deleted when that visit is deleted under its retention rules. Ending a delegation or deleting a person stops delegated access but does not erase historical reply attribution from a retained visit. Copies in backups follow the backup retention described in this policy.

Website analytics: identifiable event and user data retention is set to 14 months without extending it on new activity. This setting does not delete Google's aggregate reports. Consent choices are remembered in local browser storage for 180 days. Analytics cookies expire after 180 days without renewal by our tag configuration; withdrawal removes them from this browser and stops further collection, but does not erase earlier reports.

Optional enterprise identity records: we keep the customer’s provider settings, encrypted client secret, domain-ownership proof and provider subject/email linked to a staff login. New provider settings saved while single sign-on is required are kept encrypted until a sign-in through them succeeds or the owner keeps the current ones. Authenticator secrets are encrypted; recovery codes are stored only as fingerprints. Sign-in challenges work for 10 minutes and are deleted after 24 hours past expiry. Account authenticator records go with the login. Venue identity settings and linked provider identities go with the venue’s deletion. Group settings follow its 24-month closure retention, with provider access disabled and its client secret and any waiting provider settings removed on closure. Settings and sign-in audit events are retained for 24 months.

Your organisation’s identity provider authenticates you under your organisation’s agreement. vFound validates its signed response and restricts access to existing venue memberships. Creating staff at first sign-in starts off and grants staff access only in configured venues. Provider MFA follows your organisation’s policy; it can also require a vFound authenticator after single sign-on. A designated break-glass owner keeps password and authenticator access if the provider is unavailable.

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.

Preregistration details, event association and induction acknowledgements follow the existing retention period for the related visit and are deleted with it. An acknowledgement expiring does not by itself delete its record. Event signup configuration and induction text versions remain until the venue account is deleted. Turning these optional features off stops their forms but does not shorten the existing retention period. Copies in backups follow the backup retention periods described in this policy.

Visitor feedback, its submission time, the opt-out time, the active feedback-email choice time and its email/pass fingerprint, and the invitation-attempt time are kept with the related visit under its existing retention period and are deleted with that visit or with the venue's data. Choosing “Opt out and remove my feedback” clears the live rating, comment, submission time and active email choice (including its fingerprint), prevents further feedback for that visit and retains the opt-out and any invitation-attempt time until visit deletion. Turning email off, opting out or changing the visit email or pass token clears the active email choice and its fingerprint. Turning the venue setting off hides the feature but does not erase retained data. Expected or signed-in visits use their existing arrival or valid-date window for private follow-up access; visits marked signed out permit 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 backup, application-log, email-delivery and failed-task retention periods continue to apply. Encrypted invitation jobs may contain visit and venue references and a recipient/pass fingerprint; they contain no feedback comment. Deleting a visit prevents a new invitation attempt, but cannot recall an already-started send, delivered mail, saved copies or protected backups awaiting scheduled expiry.

7. How we protect it

Traffic is encrypted with HTTPS. Passwords are stored only as salted hashes, and sign-in is rate limited. Instead of the password, a person can ask for a one-time sign-in link by email: it works once, for 15 minutes, only on the address where it was asked for, and to check it we keep only a one-way hash, deleted 24 hours after the link is used or expires. Access is restricted to those who need it: every request is checked against the person’s venue or customer-group membership, group access is narrowed to an assigned region when applicable, every record query is limited to an authorised venue, and automated tests check that one venue or region cannot reach another’s records. Group summaries and their summary downloads contain counts and venue settings. Separate open-work lists and their CSV downloads contain the limited operational details described in section 2, scoped to the venues and regions the person may see, without email or phone fields. Security-relevant actions are recorded in an audit log, including the reads and refused changes a platform administrator makes while supporting a customer (the page and who, never the content). Directory CSV links are encrypted in the database, every redirect is checked again and downloads are limited to public HTTPS addresses and 10 MB. Daily backups are kept on our server with access limited to administrators, an encrypted copy is kept off the server, and restores are rehearsed. Public forms are protected against automated abuse. No system is perfectly secure, but if a breach affects your personal data we will notify the relevant supervisory authority and affected people as the law requires and without undue delay.

Every photo sent to vFound is checked on our own server by an automated image check for sexually explicit content before it is kept. The photo is not sent anywhere for this check, and the check keeps no copy. A photo it flags is refused and not kept; we keep only a record that a photo was refused, its score and when.

8. Cookies

We use essential cookies: vfound_token keeps you signed in for a limited time; vfound_session and XSRF-TOKEN protect forms against forgery and last two hours; vfound_lang remembers the language you pick on public and guest pages for a year. Your workspace language is also saved on your account and remembered in a separate language cookie, vfound_ui_lang, for a year. A paired visitor kiosk, which a venue can allow to sign visitors in and out, record parcel arrivals, hand out equipment for self check-out and take in coats and bags for self check-in, also uses one essential, revocable cookie, vfound_kiosk, for up to 400 days, renewed when the kiosk is used.

We also keep a few things in your browser’s own storage, which is not a cookie. Local storage stays until you clear it: vfound_legal_seen remembers that you dismissed the notice of an updated legal page, vfound_analytics_consent_v1 your analytics choice (for 180 days), vfound_sessions and vfound_install_hint how many visits you have made and whether the install hint was shown, and vfound_label_format the label size a team member chose, and vfound_walkthrough_consent that you pressed Allow on a private walkthrough (only if you did; Stop removes it). Session storage is cleared when you close the tab: vfound_venue remembers which venue you are working in, vfound_session_counted that this visit was counted, vfound_fab_closed that you closed the trial prompt, and vf-workspace-reload stops the workspace reloading itself twice for your language.

Optional Google Analytics cookies are used only after you accept analytics on the public marketing website. Accept and reject are equally available. Use Analytics preferences on a public page to change your choice. We do not enable advertising cookies or advertising personalisation.

Optional identity-provider sign-in also uses the essential vfound_sso cookie, encrypted, HttpOnly and lasting 10 minutes. It ties the response to the browser that started sign-in and is cleared when the attempt finishes. It uses SameSite=None with Secure for a cross-site SAML response; signed assertions, state and replay checks protect that route. When you choose single sign-on on the sign-in form, vfound_sso_email keeps the email you typed, encrypted and HttpOnly, for up to five minutes so the next step can find your organisation’s provider; that step clears it. When single sign-on also asks for your authenticator code, vfound_mfa (HttpOnly, 10 minutes) names that sign-in step so it never appears in the page address; it is cleared when the code is accepted. When you sign up, vfound_signup (HttpOnly, 24 hours) lets only the browser that filled in the form return from Stripe Checkout to its new workspace or try Checkout again; it is cleared when the workspace opens and the pending sign-up it names is deleted after 24 hours if Checkout was never completed.

9. Your rights

Depending on where you live, you may have the right to access your data, correct it, delete it, restrict or object to its use, receive it in a portable format, withdraw consent, and not be discriminated against for exercising these rights.

If your data relates to a claim, contact the venue handling it: the venue can correct, export or delete a guest’s details in vFound itself, and we will assist them. Otherwise write to armaan@vfound.io. We respond within 30 days and may need to verify your identity first. There is no charge unless a request is manifestly unfounded or excessive.

You can also complain to a regulator: the Office of the Privacy Commissioner of Canada, or in the EEA/UK your local supervisory authority or the UK Information Commissioner’s Office. We would rather you raise it with us first.

10. Children

vFound is not intended for children. Venue accounts are for adults acting for a business. We do not knowingly collect data from a child; if you believe a child’s data has reached us through a claim, contact us and we will work with the venue to remove it.

11. A note for guests making a claim

Treat the private claim link we email you like a password: anyone with it can see that claim. Do not send passwords, card numbers or identity documents through a claim message or a general enquiry. Submitting a claim does not confirm ownership; the venue decides. The private link to a lost-item report works for 30 days; every email about the report carries a fresh one, and while the report is open the venue page can email a new one to the address it was made with.

12. Changes and contact

If we make a material change we will update the date above and tell account holders by email or in the product. The previous version, dated 4 October 2026, is available on request. For any privacy question or request, email armaan@vfound.io, or use our contact page. See also our Terms of service and Data Processing Agreement.