Privacy Policy

1. Two roles, and why the distinction matters

For the personal data of the people who use our website and sign up for accounts — names, email addresses, sign-in activity — we are the controller. This policy describes that processing.

For the content your organisation puts into its workspace — proposal material, capability claims, pursuit records, CRM context, uploaded solicitation documents, and any personal data those happen to contain, such as the names of your staff in a past-performance narrative — we are a processor acting on your organisation’s instructions. Your organisation is the controller of that content, and our obligations over it are set out in the Data Processing Agreement, not here.

Questions asked of the in-app Guide, described in section 2, are an exception. We keep the stored copy of each question and answer for our own purpose of improving the product, so for that copy we are the controller, and this policy describes it.

2. What we collect

Account data. Your email address, display name, password (stored only as a bcrypt hash — we never hold the password itself), the organisation name you supply at signup, your role in the workspace, and the self-reported job function you may enter during onboarding.

Acceptance record. When you create a workspace we record which version of these documents you were shown, when you accepted them, and which user clicked. That record is what makes the agreement evidenced rather than assumed.

Authentication and security data. Sign-in successes and failures, the IP address and user-agent of sign-in attempts, account-lockout state, multi-factor enrolment status, and — where your organisation uses single sign-on — the identity your identity provider returns. This is kept because an account-takeover investigation is impossible without it.

Audit records. The platform records meaningful actions in your workspace — who changed a qualification, who approved a requirement, which agent called which tool — with actor, timestamp, and context. Reads are recorded as well as writes, because a forensic trail with only writes in it cannot answer who saw what.

Questions asked of the in-app Guide. Where the Guide is switched on for your workspace, we store each question you ask it, recorded against your account and your workspace, with the answer, the screen you asked from, the sources the answer used, its outcome, and whether you marked it helpful. Before the question and answer are stored, each name, title, description or note of four characters or more that the Guide read from your organisation’s records to answer that question is replaced, wherever it appears word for word, by a placeholder naming the field, such as <pursuit.buyerName>. A value the answer words differently is not replaced, and anything you type that the Guide did not read from your records is stored as typed. That is why the Guide asks you not to paste confidential content into it. The stored copies are readable by BidAngel platform administrators, and not by other members of your workspace. They are deleted 180 days after the question is asked, or sooner if the workspace is deleted.

To find the sections of our user guides closest to a question, we send Voyage AI, our embedding subprocessor, the question as you typed it, the name of the screen you asked from, and your previous question in the conversation as we stored it. Nothing the Guide reads from your organisation’s records is sent. This happens whichever AI provider your workspace uses for the answer. Voyage AI turns the text into numbers that we compare with our guides; we do not keep those numbers after the answer is given.

Operational data. Server logs needed to run and secure the service, and errors surfaced to our error-tracking tooling.

Enquiries. What you send us through the contact or demo-request forms.

Website visit measurements. On the public website, and on the sign-in and sign-up pages of the platform, we record which pages are viewed and two actions: a contact or demo request being sent, and a sign-up being completed. Each record holds the page path, the time, the host name of the site that linked to us (never its full address), and a random identifier that exists only in the memory of the open page and is discarded when the page is reloaded or closed. We do this ourselves; no analytics provider is involved. These records do not hold your name, your email address, your IP address or your browser’s user-agent, and nothing you type into a form. Your IP address and user-agent are read when the record arrives, to limit abuse and to discard automated traffic, and are not kept. Nothing is recorded once you are signed in.

Outreach codes. If we email you and you follow a link in that email, the link may end in a short code such as ?src=ab1-07. The code is tied to the message it was in, and we know who we sent that message to. Following the link therefore tells us that the link in a message addressed to you was opened and which pages were viewed afterwards in that visit, so the code is personal data about you even though the record itself holds no name. It cannot tell us whether it was you or someone you forwarded the message to, and email security software often opens such links automatically. Removing the code from the address before the page loads removes the association.

3. What we do not do

• We do not use your workspace content, or your personal data, to train models. We select AI subprocessors whose commercial terms exclude training on data submitted through their API, and we name each one in the Data Processing Agreement. Where your organisation supplies its own AI provider credential, that provider’s terms — not ours — govern what it does with the content, and your organisation chose it.
• We do not sell personal data.
• We do not run advertising or cross-site tracking, and we load no third-party advertising or analytics scripts on the public website. The only measurement of visits is our own, described in section 2.
• We do not put tracking pixels in our emails or record whether an email was opened.
• We do not read the content of your workspace except where you ask us to for support, where an operator impersonation session is used — which is itself recorded, tenant-visible, and restricted to a narrow set of routes — or where it remains in a stored Guide question or answer, described in section 2.

4. Cookies and similar storage

We use no advertising or analytics cookies. There are exactly two pieces of browser-stored state, both strictly functional:

• Your session. After you sign in, your session token and the identifier of the workspace you are viewing are held in your browser’s local storage — not in a cookie — and are removed when you sign out.
• bd_dir_sid on the public supplier directory. A random value, valid for 24 hours, that lets us apply a per-browser rate limit on top of the per-IP one. It carries no identity, no account, and no tenant binding, is not readable by JavaScript, and is sent only on directory requests.

Our website visit measurements store nothing on your device: no cookie, and nothing in local or session storage. They cannot recognise you on a later visit, or connect a visit to the website with a visit to the platform, other than through an outreach code carried in the link.

Because we set no non-essential cookies, there is no consent banner. If that changes, this section changes with it and a banner appears.

5. Why we process it, and on what basis

• To provide the platform to your organisation — performance of our contract with it.
• To authenticate you, prevent brute-force attacks and account takeover, and keep an audit trail — our legitimate interest in securing a multi-tenant system, and our own compliance obligations.
• To bill and meter usage — performance of contract.
• To respond to your enquiries — our legitimate interest in answering you, or steps toward a contract.
• To improve the service using aggregate, non-identifying operational measurements — legitimate interest.
• To read the questions people ask the in-app Guide, and its answers, so we can see where the Guide, our user guides and the product fall short and improve them — our legitimate interest in knowing where the product is hard to use. The Guide tells you this before you ask it anything. You can object by not using the Guide, and your organisation can ask us to switch the Guide off for its workspace.
• To learn which pages are read and whether the emails we send lead anyone to the website — our legitimate interest in knowing whether our website and our outreach are useful. You can object: a browser that sends Global Privacy Control or Do Not Track is not measured at all, and you can write to us to have records under an outreach code deleted.

6. Who else processes it

We use a small set of subprocessors — cloud hosting, object storage, AI inference, transactional email, single sign-on, and error telemetry. Each is named, with what it processes and why, in our Data Processing Agreement. That list is the authoritative one; we do not maintain a second copy of it here that could drift.

We also disclose personal data where we are legally required to, and to professional advisers where necessary. If we are ever compelled to disclose customer content, we will tell the affected customer unless we are prohibited from doing so.

7. How long we keep it

Account data is kept while your workspace is active. Audit records are retained beyond that, because their value is precisely that they cannot be quietly removed; retention periods and the deletion route on workspace closure are set out in the Data Processing Agreement. Authentication and security logs are kept for the period needed to investigate misuse. Enquiry correspondence is kept while it is useful and then deleted. Website visit measurements are deleted 12 months after they are recorded. Questions asked of the in-app Guide, and their answers, are deleted 180 days after the question is asked, or sooner if the workspace is deleted.

8. Where it is processed

The platform and its subprocessors may process data outside your country. Where personal data leaves the UK or the EEA we rely on the transfer mechanism stated for that subprocessor in the Data Processing Agreement. If your organisation has a data-residency requirement, raise it before you rely on the platform — tell us at [email protected].

9. Your rights

Depending on where you live, you may have the right to access, correct, export, restrict, or delete your personal data, to object to processing based on legitimate interest, and to complain to your data-protection authority. Write to [email protected] and we will respond within the period the applicable law allows.

If your request concerns content inside an organisation’s workspace, we will route it to that organisation, which is the controller of that content. We will not delete a customer’s record on the instruction of one of its members.

10. Security

Tenant isolation, role-based access control, an append-only audit ledger, and encryption of credentials at rest are described on our security page. Report a suspected vulnerability to [email protected].

11. Changes and contact

This policy carries a version identifier and a last-updated date at the top of the page. Material changes are notified before they take effect.

Controller: Brian Pasfield (ბრაიან ფასფილდ), Individual Entrepreneur registered in Georgia (the country), registration number 305874809, 1 Niko Nikoladze St, Tbilisi, Georgia. Privacy enquiries: [email protected].