Privacy Policy

1. Who we are

Volery is a multi-tenant venture-capital investment platform. Funds, their teams and the founders and investors they work with use it to source deals, run diligence, track portfolios and report to investors. Every customer organisation’s data is held separately from every other’s.

The platform is built and operated by SPR DLX STUDIOS PRIVATE LIMITED, a private limited company incorporated in India. Volery is the name of the product and volery.vc is the site it is served from; SPR DLX STUDIOS PRIVATE LIMITED is the company behind it. In this policy, “we”, “us” and “our” mean that company, and it is the controller of the personal data described here.

Operating company

SPR DLX STUDIOS PRIVATE LIMITED

Constitution

Private Limited Company, incorporated in India

Registered & principal place of business

Flat No. 506, Pride Homes, Empire Meadows, Ameenpur, Hyderabad, Sangareddy District, Telangana 502032, India

GSTIN

36ABPCS7741H1ZS

Privacy contact

hello@sprdlx.co

2. Who this policy covers

It covers everyone who uses the platform, in any of its roles: founders, general partners, limited partners, angel investors, analysts, and external collaborators invited into a single workspace, deal or meeting.

Where your organisation administers your account, it decides who inside it may see your work on the platform. This policy describes what we do with the data, not what your own organisation’s internal policies permit. For data your organisation puts into Volery about other people, your organisation decides the purpose and we act on its instructions.

3. Google Calendar: what we ask for

Connecting a Google account to Volery is entirely optional. Nothing on the platform requires it, and you can use every other part of Volery without it. If you do connect one — you may connect more than one — Volery asks Google for exactly two permissions:

• https://www.googleapis.com/auth/calendar.events — to read the events on your calendar so other people in your organisation can see when you are free, and to create, update and delete the events that Volery itself schedules for you.
• https://www.googleapis.com/auth/userinfo.email — to record which Google account you connected, so you can tell your accounts apart and disconnect the right one.

We do not request access to Gmail, Google Drive, your contacts, your calendar sharing permissions or your calendar settings. We do not ask for permission to create new calendars, and we do not read any Google product other than Calendar and the email address of the account you connected.

These two are the narrowest scopes that authorise what the feature does. We removed two broader ones we no longer needed rather than keep them in reserve, and we will not add a scope without saying so on this page first.

When you approve the connection, Google may attach one further item to the grant of its own accord: a basic sign-in identifier (openid), which Google adds whenever an application asks for your email address. It carries no calendar data and no profile information beyond confirming that you signed in. We neither request it nor use it, and we mention it here only so that what you see on Google’s consent screen matches what this page tells you.

4. Google Calendar: what we store

We still do not store the event’s description, its location, its attendee list, its organiser, its meeting link, its attachments or its notes. Those are read from Google in passing and discarded rather than written down, and no column holds any of them — so for everything other than the title, the structural guarantee is intact.

No calendar data, titles included, is sent to an artificial-intelligence or machine-learning model. Your imported calendar records are read by the calendar feature and by nothing else. Section 6 sets out what that means in detail.

Events you create inside Volery are different: you typed their title and description, so Volery holds them. Those are visible to the event’s owner and to the people invited to it, and to nobody else.

We also store the connection itself — which Google account is linked, its label if you set one, your calendar timezone, and the access and refresh tokens Google issues us, encrypted at rest.

5. Google Calendar: what we write back

A meeting you schedule in Volery is written to your own Google Calendar, so that the two stay in step. Its title, description, location and times go onto the Google event, because those are what you typed and what makes the entry useful to you.

For each person you invite who has themselves connected a Google account to Volery, the same event is written to that person’s own primary Google Calendar, using the access they granted us when they connected it. That is how an invited colleague sees the meeting on their calendar. We do not add attendees to the Google event and we do not ask Google to email anyone on our behalf, so nobody receives a Google invitation because of us — the entry appears because it was placed on that person’s own calendar under their own connection. Anyone you invite who has not connected a Google account sees the meeting inside Volery only.

If you later change or cancel the meeting in Volery, Volery updates or deletes the matching event on each of those calendars.

Volery never modifies or deletes an event it did not create. Events that were already on your calendar, or that you create in Google directly, are read for busy/free purposes and otherwise left exactly as they are.

6. Limited Use of Google user data

Volery’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically:

• we use the data only to provide and improve user-facing features that are prominent in the Volery interface — scheduling, availability and meeting management;
• we do not transfer the data to others except as necessary to provide or improve those features, to comply with applicable law, or as part of a merger or acquisition;
• we do not use the data for advertising of any kind, and we do not sell it;
• we do not allow humans to read the data, except with your explicit consent for a specific purpose, for security purposes (such as investigating abuse), to comply with applicable law, or where the data is aggregated and anonymised and used for internal operations.

We also do not use data obtained through these Google APIs to develop, improve or train generalised artificial-intelligence or machine-learning models, and we do not send it to one at all. The platform’s AI features operate on what you put into Volery.

Your imported calendar records — their titles included — are read by the calendar feature and by nothing else in the platform. No tool the in-product assistant is able to call reads them. The only calendar operation the assistant can perform is to draft an event or an acceptance from words you typed to it in chat, for you to confirm or discard; drafting one reads no calendar of yours, and a draft it has not been asked to make does not exist.

7. Other data we hold

The rest of what Volery holds is what you and your organisation put into it:

• Account details — your name, work email address, role, the organisation(s) you belong to, your profile photo if you upload one, and the password hash or Google sign-in identifier you authenticate with.
• The work you do on the platform — companies and deals you track, diligence questionnaires and findings, documents you upload, investments, valuations, capital calls and fund figures, investor reports, messages you send other members, meetings and their transcripts and summaries where you record them, and the questions you ask the platform’s AI assistant.
• Identity and compliance records where a fund asks you for them as a condition of investing.
• Operational records — audit entries for changes made to data, sign-in activity, and technical logs and error reports needed to keep the service running and secure.

8. Why we hold it, and on what basis

We use what we hold for four things and nothing else:

• To run the platform for you and for your organisation — which is what almost all of it is for.
• To keep accounts and data secure, to enforce the access rules your organisation sets, and to investigate misuse when we have reason to.
• To meet obligations that apply to us, and to support the record-keeping obligations that apply to the funds using the platform.
• To diagnose faults and improve the product — from error reports, and from how features are used, rather than from reading your deal content.

Where the law that applies to you requires a use to rest on a stated basis, ours are: performing the contract under which the platform is provided to you or to your organisation; our legitimate interest in keeping the service secure, available and working; your consent where you give it, which is how the Google Calendar connection works and which you can withdraw at any time by disconnecting it; and compliance with a legal obligation. We do not rely on consent for anything the platform needs in order to function, so withdrawing the Google consent costs you the scheduling features and nothing else.

We do not sell personal data, we do not use it for advertising, and we do not use your organisation’s content to train general-purpose AI models.

9. Who we share it with

We do not sell your data and we do not share it with advertisers. Within the platform, your data is visible to the people in your own organisation whose role gives them access to it, and to people you deliberately invite or send something to.

Outside the platform, we use service providers to run it. Each one processes data only on our instructions, under a written contract, for the function named and for no purpose of its own, and is required to keep it confidential and secure. By function, they are:

• cloud infrastructure, application hosting and compute;
• managed database hosting;
• object storage, for the files and documents you upload;
• transactional email delivery, for the messages the platform sends you;
• video meeting infrastructure, where you hold meetings on the platform;
• AI model providers, which process the text you submit to the platform’s assistant and the documents you ask it to analyse;
• error and performance monitoring, to detect and diagnose faults.

We describe these by function rather than by brand because the function is what determines what a provider can see, and because the specific set changes as the platform’s infrastructure does — a list of names on this page would be out of date before it was useful. If you need the identity of the providers handling your organisation’s data, for a vendor review or a due-diligence questionnaire of your own, write to hello@sprdlx.co and we will give you the current list.

We may also disclose data where we are legally required to, where we need to in order to establish or defend a legal claim, and to a successor entity as part of a merger, acquisition or sale of assets. If a change of control happens, the data stays subject to a policy no less protective than this one.

10. Where data is held, and transfers out of India

Volery runs on managed cloud infrastructure rather than hardware of our own. Some of that infrastructure, and some of the providers in the previous section, are located outside India: regions are chosen for latency and reliability, and AI model providers in particular operate outside India. So your data may be stored in or accessed from a country other than the one you are in.

Where data is transferred outside India, the transfer is made under contractual protections: the receiving provider is bound to process the data only on our instructions, to keep it confidential, to apply appropriate security measures, to tell us about a breach, and to return or delete the data when our contract with it ends. We do not transfer data to a provider that is not bound in that way, and we do not transfer it to a country where we are prohibited from doing so.

If you need to know the countries currently involved for your organisation’s data, ask us at hello@sprdlx.co.

11. How long we keep it

How long we keep something is decided by what we need it for, not by a single blanket period.

• While an account is active, we keep the data your organisation has put into the platform — that data is the service.
• After an account is closed, we keep it for up to 12 months and then delete it. The window is there so that an account closed by mistake or during a change of administrator can be restored, and so that a question raised shortly after closure can still be answered.
• Data imported from a connected Google Calendar — the times, the event titles and the Google event identifiers alike — is deleted when you disconnect that account: immediately, not on a schedule and not after a delay. The deletion is part of the disconnect itself: the rows are removed in the same database transaction that ends the connection, and the statement that removes them is restricted to that one connected account, so disconnecting one Google account cannot take another one’s records with it. See the next section.
• Records the law requires us to keep — our own financial, tax and accounting records, including invoices and books of account — are kept for the statutory period that applies to them under Indian law. For books of account that period is eight years from the end of the relevant financial year, under the Companies Act, 2013. These are records of our business relationship with your organisation; they are not your deal, diligence or portfolio content.
• Audit and security records may be kept for longer than the data they describe, where we need them to investigate an incident or to show who changed what. Each kind of audit record carries its own retention period, declared alongside the record in the platform itself rather than left to a reviewer’s judgement, and scheduled daily jobs delete the kinds they cover once rows are past it. Some of those periods are long on purpose: the record of what the in-product AI assistant was asked to retrieve is kept for seven years as a compliance record, holding a hash of the question rather than the question, and records that fund and investment-committee obligations attach to are kept for up to ten years.

You can ask us to delete something sooner than the periods above. Section 13 explains how, and what happens when an obligation prevents us from agreeing.

12. Your control over the Google connection

You can disconnect a Google account at any time from the Calendar page in Volery. When you do, Volery:

• stops the Google push-notification channel, so Google sends us nothing further. This happens first, deliberately: once the grant is revoked we can no longer prove to Google who we are in order to close the channel, and an unclosed channel would keep calling our endpoint for the rest of its life;
• revokes the token with Google, so our access ends at Google’s end too. Where a refresh token is held, that is the one revoked, because revoking a refresh token tears down the whole grant — revoking only a short-lived access token would leave the refresh token, and so our access, alive;
• deletes our stored copy of the credentials. The refresh token is emptied and the access-token field is overwritten with a marker that is not a token, in the same database transaction and immediately after the revocation that needed to read it. What stays behind is the record of the connection — the account’s email address and which permissions were granted — not anything that could be used to reach Google again;
• deletes the records imported from that account — the start times, end times, event titles and Google event identifiers described in section 4. Nothing we imported from that calendar survives the disconnect.

If you have connected more than one Google account, disconnecting one leaves the others and their records alone. Meetings you had already scheduled stay on the Google calendars they were written to; disconnecting stops future syncing, it does not reach back and empty your calendar.

You can also review and revoke Volery’s access directly in your Google Account’s security settings. Doing it there revokes the token but does not delete the records already imported, so if you want both, disconnect from within Volery.

13. Your rights

You can ask us to:

• give you a copy of the personal data we hold about you, and tell you where it came from and who we have shared it with;
• correct it where it is wrong, out of date or incomplete;
• delete it;
• stop or restrict a particular use of it, including while a question about that use is being resolved;
• withdraw a consent you gave us. For the Google Calendar connection you do not need to ask: disconnecting it withdraws the consent and takes effect immediately.

Write to hello@sprdlx.co. Tell us what you want and enough about yourself for us to find your records. We will acknowledge the request, act on it without undue delay, and tell you what we have done. If we need longer, or if we cannot do what you asked, we will tell you that and why. We do not charge for a request.

Where your organisation administers your account, some requests are its decision rather than ours — for example deleting a record a fund is obliged to keep, or data that belongs to the organisation rather than to you. We will tell you when that is the case and who to ask, and we will pass your request on.

If you are not satisfied with how we have handled a request, tell us first, at the same address, so we can try to put it right. If that does not resolve it, you may complain to the data-protection authority or other regulator with jurisdiction over you; we will cooperate with it. This section describes what we do — it is not a claim that any particular regulator has certified us.

14. Security

What we do, stated as what it is rather than as a badge. Each protection below names the mechanism behind it, because “encrypted” or “isolated” on its own tells you nothing about what is actually in place.

Data in transit

The platform is reachable only over HTTPS, so traffic to and from it is encrypted in transit using TLS. TLS is terminated at our edge with certificates that are obtained and renewed automatically, and a request that arrives over plain HTTP is redirected to HTTPS rather than answered over it. Responses carry an HTTP Strict Transport Security header (max-age=31536000; includeSubDomains), which tells your browser to refuse plain HTTP for this domain and its subdomains for a year, so a link that tries to downgrade the connection never reaches us. The same edge sets X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: no-referrer and a Content-Security-Policy of frame-ancestors ‘none’, so the application cannot be framed inside another site and the address you came from is not passed on. Calls we make to Google go to Google’s published HTTPS endpoints under the same transport security.

Data at rest

Google OAuth access tokens and refresh tokens are encrypted at rest using Fernet authenticated encryption — AES-128 in CBC mode, under a random initialisation vector, carrying an HMAC-SHA256 signature over the ciphertext. Because the signature is verified before anything is decrypted, a stored token that has been altered fails to decrypt rather than decrypting into something else. The key is dedicated to this one purpose: it is either configured for this purpose alone, or derived for it alone through HMAC-SHA256 under a purpose-specific label, so the key that protects calendar tokens is not a key any other part of the platform uses. Tokens are redacted from our application logs rather than written into them.

We do not claim that every stored field on the platform is encrypted by us. The sentence above is the encryption we implement in the application; where a managed infrastructure provider encrypts storage underneath us, that is its control and not ours to assert on its behalf.

Keeping one organisation’s data away from another’s

Each customer organisation’s data is isolated from every other organisation’s, and requests are scoped to the organisation they were made in. That isolation is enforced twice over, in two independent places:

• In the database. Tables that hold an organisation’s data have Postgres row-level security turned on, with a policy that compares each row’s organisation against the organisation the current database transaction has been set to. A query for another organisation’s rows does not return them, whatever the application code asked for. Every table behind the Google Calendar integration had that policy created in the same database migration that created the table, so none of them existed for a moment without it.
• In the application, on top of that. Each request resolves an isolation context — who you are, and which organisation you are acting in — and every read and write of organisation data carries that organisation’s identifier as an explicit condition. That column is indexed on those tables, and an automated check fails our build if a new table is added without the index. The internal helper for opening a database connection without an isolation context raises an error instead of handing back an unscoped one, so the unsafe shape fails loudly rather than quietly working.

Access control

Who can reach what is decided in three layers, each a different kind of check:

• At the route. Every interface the application exposes to a signed-in account is gated by a named permission guard, and all of those guards are declared together in one file rather than written inline wherever they are used — so what a given operation requires can be read in one place and reviewed. An automated check in our build fails an operation that takes a signed-in account without one.
• At the invitation. Someone invited into a single deal, diligence process or meeting, rather than given a role across an organisation, holds a scope record for exactly that surface and nothing else. The check reads that record on each request; a record that is absent, revoked or past its expiry refuses the request, and a failure to read the record refuses it too rather than letting it through.
• At the record. A per-record check then decides whether the particular item you asked for is one you are entitled to. Where it is not, the answer is an ordinary “not found”, worded identically to the answer for something that does not exist at all — so being refused cannot be used to work out that a record is there.

Authentication

Passwords are not stored. What we keep is a bcrypt hash under a random per-password salt; bcrypt is deliberately slow to compute, which is what makes a stolen hash expensive to attack, and the password itself cannot be recovered from it. A sign-in attempt for an address we hold no account for is checked against a placeholder hash so that it takes the same time as a real one, and so cannot be used to find out which email addresses have accounts.

Sign-in is rate limited, and repeated failures lock the account for a cool-off period — counted both per source address and across all source addresses at once, so an attempt spread over many machines against one account is caught as well as a single machine hammering it. Sessions are bearer tokens: signing out puts the token on a server-side revocation list that is consulted on every later request, so it stops working immediately rather than when it would otherwise have expired, and changing a password invalidates the sessions issued before it through the same mechanism. If that list cannot be reached, the request is refused rather than allowed through unchecked.

Audit

Several dedicated audit tables record who did what and when — the actor, the action and the time — across administrative actions, diligence, fund-intelligence changes, email delivery and the in-product AI assistant. Some of them also record the value before and after a change; not all of them do, and we would rather say so than describe every table as a full before-and-after audit trail. Each kind of record carries its own retention period, declared in the platform alongside the record itself rather than left to a reviewer’s judgement, and scheduled daily jobs delete the kinds they cover once rows are past it.

Every retrieval the in-product AI assistant performs is written to one of those tables, at the single point in the code where a tool call is executed — so a call made through a connected external assistant is recorded on the same path as one made inside Volery. That table is append-only, the record is kept for seven years, and it holds a hash of the question rather than the question itself.

Deletion

Disconnecting a Google account is a deletion, not a flag. Volery releases the push-notification channel so Google stops sending us anything further; revokes the grant at Google, using the refresh token in preference to the access token because revoking a refresh token tears down the whole grant rather than one short-lived credential; removes our stored copy of the tokens, emptying the refresh token and overwriting the access-token field with a marker that is not a token; and deletes the busy/free rows imported from that account. Those last two happen in the same database transaction, and the token is cleared only after the revocation that had to read it, so the two steps are ordered rather than merely adjacent. The row deletion is keyed to the specific connected account, so disconnecting one Google account leaves another connected account’s records untouched. Section 11 sets out the periods for everything else.

Operational access

Access to production systems is limited to the people who need it to operate the service. Production credentials and keys exist only in deployment-time configuration, never in our source code, and the application refuses to start in production when one of the settings that isolation depends on is missing or misconfigured — rather than starting in a state that looks healthy and quietly returns nothing.

We do not claim a security certification, an external audit or a compliance standard that we have not obtained, and you should treat any such claim made on our behalf elsewhere as unfounded. No system is perfectly secure.

If a breach affects your personal data, we will investigate it, take steps to contain it, and tell you and your organisation’s administrator without undue delay once we understand what happened and what it means for you — describing what we know, what we are doing, and what you should do. Where the law that applies to the breach requires us to notify a regulator, we will notify it within the time that law allows.

15. Children

Volery is a professional tool for investment organisations. It is not directed at children, we do not knowingly collect data from anyone under 18, and if we learn that we have, we delete it.

16. Changes to this policy

If we change what we collect or how we use it, we will update this page and change the “last updated” date above. Where a change materially affects you, we will tell you in the platform or by email before it takes effect. If a change adds a Google permission or alters what we store from a connected calendar, sections 3 to 6 will say so before it is in effect.

17. Contact

Email hello@sprdlx.co with anything about this policy, a request about your data, a security concern, or a question about the Google Calendar integration. Post reaches us at Flat No. 506, Pride Homes, Empire Meadows, Ameenpur, Hyderabad, Sangareddy District, Telangana 502032, India.

The Terms of Service govern your use of the platform itself.