Data Processing Summary

A short, factual description of the personal data Vera Croft processes on a customer's behalf, who else is involved and where it sits. It is meant to be enough for a security or procurement review to proceed without a call.

It sits alongside the Privacy Policy (what we do with your own account data) and the Terms of Service. It describes practice; it does not certify compliance with any particular regime.

• The customer organisation determines the purposes of processing personal data in its project content. Its authorised project administrators express its instructions through the product. We process that content on its behalf. Holding an owner role in the application does not by itself make an employee a separate legal controller.
• VERA GRP LLC, a Delaware limited liability company, at 1895 Tyler Street, Suite 404, Hollywood, Florida 33020, United States, provides Vera Croft (“we”, “us”) and determines the purposes of account administration, billing, security, support and website enquiries and subscriptions. We remain responsible for the personal data we process for those purposes. The Privacy Policy covers it.
• The customer chooses the connected Dropbox or Google Drive account. Its storage account holder controls that account on the customer's behalf; that technical role does not override the customer's legal responsibilities or individuals' rights. See section 5 for legacy Storage files and processing in transit.

• Store it, and serve it back to the members of the project who hold a role that permits it.
• Attribute records to their author, and keep an activity log that a project owner can review.
• Send the transactional emails the product needs: confirmation, password reset, project invitations, and the billing notices sent to a workspace's billing administrators whether or not the workspace has a subscription — trial, plan-transition, complimentary-period, subscription, renewal, payment, refund and export notices.
• Make a workspace complimentary when an account that has confirmed an email address our staff offered one to creates it while the offer is open, or when our staff apply the offer to a workspace that account administers. Making the offer sends nothing to the offered address; once the workspace is complimentary, its billing administrators, the account that confirmed that address among them, receive the complimentary-period notices above.
• Read and write files in the storage owner's connected provider account on request.
• When a budget or estimate import cannot be mapped by the local parser, send a masked sketch of the sheet to an inference gateway, which answers with a column mapping. Every amount, cost code, number and date is replaced by a placeholder token before the request leaves our server, which refuses to forward a sample that still contains one; email addresses, phone numbers and street addresses are stripped from the remaining text, which is otherwise the row labels as your team wrote them. Nothing is sent where no gateway key is configured.
• Record each new account's acceptance of the Terms of Service and acknowledgement of the Privacy Policy, and, where it is switched on, check the sign-in, sign-up and password-reset forms for bots through Cloudflare Turnstile.
• Diagnose failures and investigate abuse.
• We do not profile users, train models on customer content, sell data, or use it for advertising.

New project files are stored in the connected Dropbox or Google Drive account under a VeraCroft folder, and downloads are fetched from there. File contents can pass through our server functions during uploads, downloads and migrations. Older project attachments, documents, project images and avatars also remain in Supabase Storage in our United States project. Those legacy objects are an exception to the connected-account arrangement; database backups contain their metadata, not their file bytes. Our database holds only the metadata — name, path, size, type, uploader, timestamps and the provider's file id. On Google Drive our access is limited to the drive.file scope, which reaches only files the application itself created; the Dropbox grant is broader — read and write over the connected account's files — though the application only ever touches its own VeraCroft folder. The account holder can delete provider-hosted files directly, and authorised product operations can delete files while the connection and permissions allow it. Account deletion alone does not instruct us to erase a customer's project files. Requests concerning project files or legacy objects must be handled with the responsible customer. We do not maintain an independent backup of files in the connected provider account. Disconnecting a provider deletes the account holder's connection to it from our database, together with the access tokens stored with that connection, but it does not withdraw the account holder's grant to our application at Dropbox or Google, and neither does deleting their Vera Croft account: the account holder removes our application in their provider's own settings — the connected apps of their Dropbox account, or the third-party apps with access to their Google Account.

The database, authentication and functions run in the United States (Supabase region us-east-1). The interface is delivered from Vercel's edge network. New project files are wherever the connected provider account keeps them; legacy Supabase Storage files remain in our United States project. Website enquiries and confirmed subscriptions also reach the Russia-hosted CRM described in section 6. Our current commercial offering is limited to United States businesses; this summary does not establish an EU or UK international-transfer mechanism. If your users are outside the United States, using Vera Croft transfers their account data there.

• Row-level security on every table, with project membership and role checked in the database rather than in the interface.
• Privileged operations (account deletion, role changes, ownership transfer, revealing an access code, reading a teammate’s last-seen time) run through server-side functions scoped to the caller, not through open table permissions. The columns those functions guard — an access code’s password, a person’s last-seen time — are withheld from browser requests outright, so the function is the only way to them.
• Storage provider tokens encrypted with AES-GCM before storage, decrypted only inside a server function.
• A project export, available to the project's owner and administrators, carries the project's invitations without the token that joins one, and of its direct messages only the conversations the person exporting took part in.
• HTTPS everywhere. Enforced response headers: framing by any other site refused, MIME-type sniffing off, a strict-origin-when-cross-origin referrer policy, and a permissions policy that denies camera, geolocation, payment and USB outright and allows the microphone only to the application itself, for voice notes on daily logs. A Content-Security-Policy is delivered alongside them in report-only mode, so as things stand it reports what it would have blocked rather than blocking it — worth knowing rather than counting as a control.
• Passwords hashed by Supabase Auth, reachable by no console. The platform console reaches every profile, a roster of every project with its owner, its members and their email addresses, its record counts and its budget totals, the offers of a complimentary workspace with their email addresses, and the administrator audit log — but not the content of a project, which row-level security withholds from an administrator exactly as it does from any non-member. Platform administrators can also export a project's data from outside it; each such export is written to the audit log and carries none of the project's direct messages. At most two protected administrators can additionally grant administrator access and permanently delete a project with all of its rows.
• A per-project activity log that is append-only for a member: they may add entries attributed to themselves and can neither edit nor delete any. A project owner or administrator can amend or delete an entry, but not re-attribute one — the actor's id and name on a row are pinned by a database trigger. Membership and role history is written only by server-side functions and cannot be altered from a client at all, and administrator actions go to a separate platform audit log with the same property, readable only by platform administrators.

• Deleting a record in the product deletes the row.
• A person’s stored “last seen” timestamp stops being shown thirty days after the moment it records and is cleared from the database the next time anyone signs in, and it is deleted immediately when the account is deleted.
• Deleting an account relabels the profile to “Deleted user” and clears its optional fields; replaces the person's name with “Deleted user”, and removes their email address, in every record that links the name to the account by its id; removes every membership, every pending invitation and the person's own notifications; withdraws an open complimentary-workspace offer for the person's confirmed address and removes that address from every offer that holds it; then deletes the authentication account and the avatars we hold. Authored records stay with their project. Relabelling and removing direct identifiers does not guarantee anonymisation; retained ids and free text can remain personal data.
• Text that nothing ties to the account can still carry the person's name: notifications other people received that quote it, a task's assignee text and task owner, some RFI assignee text, the summaries and details of log entries, a workspace named after the person, the address in text not linked to the account, and what people typed. Privacy Policy section 9 lists them.
• An offer of a complimentary workspace holds its email address and its note while it is open, at most a year after it was made, and for 30 days after it is withdrawn or lapses; both are removed then, the address sooner when the offer is used, and both at once on request. Neither is copied into the audit log. A used offer keeps its dates, the length of the free period, its note, the account that used it and the workspace it became, with that workspace's billing records.
• The record of a person's acceptance of the Terms and the Privacy Policy at sign-up survives the deletion of their account, and cannot be changed or deleted through the application: an id, the sentence, the two documents' dates, how, where and when — no name or email address.
• Account deletion is refused while the person is the sole owner of an active project, while their connected storage holds the files of a project other people are still using, or while they are the only billing administrator of a workspace that others still use or that has a live subscription.
• A workspace's billing records — orders, amounts, dates, Stripe references and the consent accepted at checkout — survive the deletion of the person who placed them, under the name “Deleted user”, together with the copies of Stripe's payment events we keep, which account deletion does not change. When a subscription or trial ends, or a free workspace reaches the date by which a plan is needed without one, the workspace stays readable and exportable for thirty days, then is blocked and scheduled for deletion from active systems within the following thirty days, apart from those records and anything the law requires to be kept.
• Provider-hosted files can be deleted by the storage account holder or through authorised product operations. Legacy Supabase Storage objects require their applicable deletion process; the account-deletion process removes identifiable legacy avatars, not all project files.

Residual records — what an account deletion leaves behind — are kept for up to seven years after the account is deleted. Those that belong to a project can go sooner: a member whose role allows it can delete them inside the project, and they are deleted with the project when a platform administrator deletes it or its workspace is purged. The database is backed up once a day and each backup is kept for seven days, so a backup may still contain deleted database data for up to seven days after it is deleted. This is not a backup or deletion schedule for provider-hosted files, legacy Storage file bytes, the CRM or mailboxes. A specific legal retention obligation or documented legal hold can require longer retention, restricted to that purpose.

We offer a data processing agreement to a customer who needs one, on request. Requests and questions go to info@veracroft.com. This summary is not itself a signed data processing agreement. Mandatory security, assistance and notification duties apply regardless of whether a separate agreement has been signed. Under a customer data processing agreement we notify the customer of a personal data breach affecting their data without undue delay, and no later than 48 hours after we become aware of it, or earlier where applicable law requires. We provide information available at the time and supplement it as the investigation continues; the initial notice is not delayed until every fact is confirmed. Any other commitment — on audits, or on notice before a subprocessor changes — would live in that agreement rather than on this page; nothing here should be read as one.