1. Information We Collect
Vivid Risk collects minimum viable data to provide our assurance services. This includes organizational metadata, technical telemetry for risk assessment, and user identity information provided during registration. Outside assessments, the only web pages we read are public company website pages, one page at a time, as section 6 describes. Section 6 covers people who are not our customers: the business contact details we hold about them and where those come from.
2. How We Use Your Data
Data is used to quantify risk, generate remediation roadmaps, and support audit-readiness. Some features send the content you enter to Google's Gemini models on Vertex AI to produce draft text — the cross-mapper and the AI-assisted narrative sections. Under Google Cloud's Service Specific Terms, section 18 (Training Restriction), Google will not use that content to train or fine-tune any of its models without our prior permission or instruction — and we give neither. Google may retain it briefly for abuse monitoring under their own policy. If you would rather not send content to a third-party model, avoid the features that are labelled as AI-assisted; nothing else on the platform sends your data to them.
3. Data Protection & Storage Location
Your data is encrypted at rest and in transit by Google Cloud, and each tenant's assessment data is isolated from every other tenant's by Firestore security rules. Evidence Vault entries record what you type about a document — title, description, type and source — and, where you attach one, the document itself. Files are held in Google Cloud Storage in europe-west1 (Belgium), encrypted at rest by Google, and are served back to you only through links our server generates on request and which stop working after five minutes. Nothing reads the contents: your files are not scanned, parsed, indexed, or used to train anything, and the relevance check described below sees only the words you typed. Cryptographic hash verification of vault artifacts is not implemented.
On storage location, we would rather be exact than reassuring. Your assessments, vendor records, incidents and audit history are held in Google Cloud Firestore in europe-west1 (Belgium), and our application servers run in the same region. Evidence files you upload are held in Google Cloud Storage in the same region, and our server reads the bucket's own location from its metadata rather than taking it from configuration, once per server instance and before it will store anything — it refuses to store anything in a location it cannot confirm is in an EU member state. One thing sits outside that, and we would rather name it than let the first sentence stand for the whole picture. Account identity — your email address and sign-in records — is held in Firebase Authentication, which Google does not offer as a region-configurable service: it appears nowhere in Google's own data-residency terms, neither among the services whose location a customer can set nor among those that hold no customer data at rest. So we cannot choose or confirm where it is stored, and there is no EU setting for us to have missed.
AI-assisted features used to sit outside it too, and no longer do. Since 17 September 2026 the text you submit goes to Google's Gemini models on Vertex AI. Since 12 October 2026 the text the assistant and the AI features write is generated through Google's EU multi-region endpoint (eu), and the embeddings the evidence cross-mapper uses to find matching controls are made ineurope-west1. Google's AI/ML Data Location terms commit it to performing that processing only within the EU multi-region for the models we use. That settles one subprocessor. It does not settle the question, and we are not going to let it read as though it did.
Because of account identity, and because the payment and email subprocessors named in section 4 both process in the United States, please do not rely on this platform to satisfy a data-residency requirement or a GDPR Chapter V transfer obligation, even though the database itself is in the EU. We would rather tell you that than let you assume otherwise. If residency is a condition of your using us, write to support@vividrisk.ai and we will tell you exactly where each of these stands rather than sell you a guarantee we cannot give.
4. Third-Party Sharing
We do not sell your personal or organizational data to anyone. It is shared only with the subprocessors we need to run the service, each under a data processing agreement. Those are, in full: Google Cloud (hosting, database, authentication and the AI-assisted features described in section 2), Stripe (payments) and Resend (transactional email). If we add one, we will update this list.
That is the short form. The full register is at vividrisk.ai/subprocessors — one row per service rather than per company, because the answers differ by service, with what each one receives, where it processes it and the safeguard its transfer rests on. If you are using Vivid Risk on behalf of an organisation and need to tell your own customers who touches their data, that page is the list to hand them.
Because naming a recipient is not the same as saying what reaches it: Stripe receives your email address, our internal account id for you, and the plan tier you chose. Your card details go to Stripe directly from the checkout page and never touch our systems; whatever else Stripe needs to take a payment, it collects itself under its own privacy policy. Resend receives the address a message is sent to, and where a confirmation email repeats back what you typed into a form — your name, your company, and the framework focus you named — it carries those too. Neither receives your assessment answers, your evidence records, your vendors or your incidents.
Both of them process it in the United States, and we checked that against each company's own data processing agreement rather than assuming it. Stripe's says you transfer personal data to Stripe, LLC in the United States, and that Stripe may then move it "on a global basis" to its affiliates and sub-processors in other jurisdictions. Resend's says its "primary processing operations take place in the United States". Neither agreement offers a European option — the word "residency" does not appear in either document — so this is not a setting we have left unchosen.
Those transfers are lawful, and they rest on the safeguards Chapter V of the GDPR requires rather than on your data staying in Europe. You are entitled to know which, so: Resend relies on the EU Standard Contractual Clauses and on its certification under the EU-U.S. Data Privacy Framework. Stripe relies on its Data Transfers Addendum, which applies the Data Privacy Framework, the EEA Standard Contractual Clauses or the UK addendum as the case requires. Google covers Firebase Authentication under its Cloud Data Processing Addendum, which requires Standard Contractual Clauses or an equivalent for any transfer outside a country the European Commission has found adequate. You can ask us at support@vividrisk.ai for a copy of any of them.
Google Workspace connector, and how we use what it reads
If your administrator connects your Google Workspace, we request exactly one permission — admin.directory.user.readonly — and we ask Google's Directory API for seven fields per account and no others: whether two-step verification is enrolled, whether the account is an administrator, whether it is a delegated administrator, whether it is suspended, whether it is archived, and when it last signed in. We never request or receive a name, an email address, a user id, a phone number, a recovery address or any message, file or calendar content. No Gmail scope and no Drive scope is requested, and none will be added without your administrator granting it explicitly.
What we keep is not a copy of your directory. Each check produces counts — how many accounts have two-step verification, how many are administrators, how many have not signed in — and one sentence describing what was counted. Those numbers are stored against your account and shown to you beside the questions they are evidence for. They do not answer those questions: you do. A count is evidence for your answer, never evidence of it.
Vivid Risk's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.
Concretely, and going further than that statement requires: no data obtained through the Google Workspace APIs — raw, aggregated, anonymised or derived — is sent to any AI or machine-learning model, ours or anyone else's. The connector's output is counted and displayed; it reaches no prompt, no model and no training process, and it is not transferred to any third party. The AI-assisted features described in section 2 operate on the assessment answers and documents you enter yourself, and are served by Google Cloud's Vertex AI, whose Service Specific Terms state that Google will not use customer data to train or fine-tune its models without the customer's instruction. We give no such instruction. We use no other AI provider, and no AI gateway, aggregator or model hub.
Disconnecting removes our stored credential. It does not revoke the grant at Google — only your own administrator can do that, from your Google account's permissions page — and we say so in the product rather than implying the access is gone.
Microsoft 365 connector, and how we use what it reads
If your administrator connects your Microsoft 365, we ask Microsoft for three read-only permissions, each of which only an administrator of your organisation can grant: User.Read.All, AuditLog.Read.All and RoleManagement.Read.Directory — plus offline_access, which lets the connection keep working without signing in again and reads no data. From Microsoft Graph we ask, for each account, only whether it is enabled, whether it is a guest account, and when it last signed in; and, for each active administrator role, the internal identifiers of its members. We never request mail, files, calendars, chats or sites.
One read cannot be narrowed. Microsoft's multifactor registration report returns each account's name and sign-in address with its registration status, and offers no way to ask for less. We reduce each row, in memory and before anything else uses it, to two facts — whether multifactor is registered, and whether it is a guest account — and keep neither the names nor the addresses.
What we keep is counts, as for Google Workspace: how many accounts have registered multifactor, how many hold administrator roles, how many have not signed in for 90 days — and one sentence describing what was counted, shown beside the questions they are evidence for. The checks run when your administrator asks and once a day while connected. We also keep the credential Microsoft issues, encrypted; Microsoft replaces it at each run and we store the new one. Nothing read through Microsoft Graph — raw, aggregated, anonymised or derived — is sent to any AI or machine-learning model, or to any third party.
Disconnecting removes our stored credential. It does not withdraw the consent in Microsoft Entra — only your administrator can do that, under Enterprise applications — and the product says so.
Microsoft Azure connector, and how we use what it reads
If someone in your organisation connects Azure, we ask Microsoft for one permission, Azure Service Management user_impersonation, plus offline_access. Microsoft offers no read-only version of it: it lets our connection act with whatever Azure roles that person holds. The limit is ours: our code sends only read requests, and only to Azure Resource Manager. Connect with an account that holds only the Reader role, so Azure enforces the same limit.
For each subscription that person can see, we read the role assignments (to count who holds Owner), each storage account's settings for public blob access, minimum TLS version and HTTPS-only traffic, and whether the activity log is exported. We read no data inside any storage account, database or virtual machine.
What we keep is counts — how many principals hold Owner, how many storage accounts allow public access or weak transport, how many subscriptions export their activity log — and one sentence describing what was counted, shown beside the questions they are evidence for. The checks run when you ask and once a day while connected. We also keep the credential Microsoft issues, encrypted. Nothing read from Azure — raw, aggregated, anonymised or derived — is sent to any AI or machine-learning model, or to any third party.
Disconnecting removes our stored credential. It does not withdraw the consent in Microsoft Entra — only an administrator can do that, under Enterprise applications — and the product says so.
Google Cloud connector, and how we use what it reads
If someone in your organisation connects Google Cloud, we ask Google for one permission, cloud-platform.read-only. It lets our connection read, never change, whatever that person's own Google Cloud roles let them see. Connect with an account that holds only Viewer or Security Reviewer, so the reach is no wider than the checks need.
For each project that person can see, we read its IAM policy (who holds Owner, whether any role is granted to allUsers or allAuthenticatedUsers, and whether Data Access audit logs are on) and, for each Cloud Storage bucket, whether public access prevention is enforced. We read no data inside any bucket, database or virtual machine.
An IAM policy names its members, usually by email address. We count them in memory and keep neither the names nor the addresses.What we keep is counts (how many principals hold Owner and how many of those are user accounts, how many buckets do not enforce public access prevention, how many projects record Data Access audit logs) and one sentence describing what was counted, shown beside the questions they are evidence for. The checks run when you ask and once a day while connected. We also keep the credential Google issues, encrypted. Nothing read from Google Cloud (raw, aggregated, anonymised or derived) is sent to any AI or machine-learning model, or to any third party. The Limited Use statement above applies to this connector as it does to Google Workspace.
Disconnecting removes our stored credential. It does not revoke the grant at Google; only that person can, from their Google account's permissions page, and the product says so.
Privacy Principle
"Our business model is based on assurance, not data monetization. We succeed when you are secure, not when your data is exposed."
5. Your Rights
If you are in the EU, the EEA or the UK, the GDPR and the UK GDPR give you the right to access the personal data we hold about you, to have it corrected, to have it erased, to restrict or object to our processing of it, and to receive it in a portable format. These rights apply regardless of what this platform does or does not automate.
Two things survive a deletion request, because the law requires us to keep them: invoices and payment records, which tax law obliges us to retain for years after you leave, and our security audit log, which is how we can demonstrate who did what on the platform. Neither is used to contact you or to rebuild your account. Everything else goes.
You can delete your account yourself, at any time, from Settings — it removes your assessments, reports, evidence records, vendors, incidents, support history and profile, and signs you out. If an organisation gave you access to its workspace — for example as a client user invited by a partner practice — the evidence you uploaded there, the progress notes you wrote there, and the records you created in its registers (vulnerabilities, incidents, assessments, suppliers, AI systems, CRA reports, cyber threats, technical controls, assets, essential services, saved cross-mappings, supplier incident notices and DORA aggregated costs) are that organisation's records, not yours. Deleting your account does not delete them: we keep them with your name and email address removed, and remove you from any remediation record assigned to you there. Evidence, incident, assessment, CRA report, cyber threat, supplier incident notice and DORA aggregated cost records keep the internal ID of your deleted account, because a stored file's location, or our report integrity chain, is built from it, and text you typed into a record is not edited. Our audit log and report integrity chain are kept, as they are for every account. To ask for those records to be changed, contact the organisation. For anything else — a copy of your data, a correction, or a restriction — email support@vividrisk.ai. We will respond within one month, as Article 12(3) requires. There is no self-service export button yet; we assemble those by hand, and we would rather say so than point you at a screen that does not exist. An export includes the evidence files you uploaded, alongside your records. You also have the right to complain to your supervisory authority — in Ireland, the Data Protection Commission.
6. Prospects and Business Contacts
This section is for people who are not our customers: people we may contact about Vivid Risk for business reasons, and people who have written to us through a form on our websites. If an email from us said we found your work contact details through Apollo.io, this is the section it links to. The controller of these details is Vivid Risk LTD, a private company limited by shares incorporated in Ireland under company registration number 818204, having its registered office at 15 The Meadows, Portlaoise, Co. Laois, Ireland.
Where your details come from
We look for organisations that may need a cyber-risk and compliance product, and for the people there whose work it is, through Apollo.io, a database of business contacts. From Apollo we take your name, job title, seniority, the email address Apollo holds for you at work and whether Apollo has verified it, the address of your LinkedIn profile, and your country; and, about your employer, its name, web domain, website, industry, approximate number of employees, country, and the titles, links and dates of jobs it is advertising. We do not ask Apollo for personal email addresses or phone numbers. We also read one public page of your employer's website, at the address Apollo gives for it, to understand what the organisation does. Our staff can also ask our system to read one page of an organisation's website at an address they give it, to draft a message to that organisation.
Other business contacts are in our records because you gave us your details, through a demo request, the partner-fit form or the chat on our websites, or because our staff added them by hand or imported them from a contact list.
We do not use LinkedIn's API, and nothing on our side collects data from LinkedIn. Our staff may open your LinkedIn profile from the link Apollo provides, and may send you a message there themselves.
What we use them for
To work out which organisations are likely to need Vivid Risk, to write to the people there about it, and to manage the sales relationship in our CRM: the organisation, the people we are in touch with there, any deal, and the stage it has reached. Our system ranks the people it finds with fixed rules: points for a job title that matches the roles we searched for, a sector our system reads from your employer's website, an open job in security, IT, risk or compliance, a company size in the range we searched for, and an email address Apollo has verified; and points off when the website is unclear about what the organisation does or could not be read.
It then drafts a LinkedIn message, and a first email where Apollo has verified your address, with Google's Gemini models on Vertex AI, through the EU endpoint described in section 3. To write them, the model is given your employer's name, the text of the page we read from its website, and which of the roles we searched for your job title matches; not your name or your email address. With each person we keep a short summary of that page, what our system read from it about the organisation (with the sentences it read them from), the drafts, and the score with its reasons. A member of our staff approves or rejects each person, with the drafts in front of them, before anything is sent; our system never sends a message on its own. The ranking decides which people our staff review; people outside each day's limit are not contacted and are deleted as described below. No decision that has a legal or similarly significant effect on you is made by automated means.
Our legal basis, and where we contact people
We rely on our legitimate interests (Article 6(1)(f) of the GDPR and of the UK GDPR) in telling organisations about a product that is relevant to their work, and we write to you only about your work. The safeguards in this section are how we keep that use within what you can reasonably expect. Our prospecting system looks for people only in Ireland and the United Kingdom: anyone Apollo places in another country is dropped before anything is drafted. The rules on electronic marketing in Ireland (S.I. No. 336/2011) and the UK (the Privacy and Electronic Communications Regulations 2003) also apply. Our cadence emails and our bulk sales emails come from Vivid Risk and carry an unsubscribe link.
Who receives your details
Apollo.io is the source of the details above. We send Apollo the search filters we choose (job titles, seniorities, countries, industries, company sizes and keywords) and, when we ask for a record, Apollo's own identifier for the person or the organisation, or the organisation's web domain. We send Apollo nothing else about you and write nothing back to it. Your details are stored by Google Cloud, which also runs the AI drafting; our emails are delivered by Resend, which receives your address and the message. These are the subprocessors named in section 4, with the transfer safeguards described there. If our staff message you on LinkedIn, LinkedIn carries that message under its own terms.
How long we keep them
If our system finds you and our staff do not approve you, including when they reject you, a daily job deletes your details once they are more than 30 days old. If our system drops you before anyone reviews you (for example because you are on our do-not-contact list, or outside Ireland and the UK), it keeps only Apollo's identifier for you, so that we do not look you up again, and the same job deletes that after the same 30 days.
If our staff approve you, your details become a contact in our CRM, and the record of what our system found and drafted is kept with it. We have not yet set a period after which CRM contacts and deals are deleted automatically. We will add one to this policy when we do. Until then you can ask us to delete your contact record at any time, as described below.
If you unsubscribe or object by email, we keep your email address on our do-not-contact list, with where the request came from and when, and with no end date: deleting it would let the address be emailed again. We use it only to stop messages to you. Our security audit log also records an unsubscribe made through the link.
Objecting, and your other rights
You can object to direct marketing at any time. This right is absolute (Article 21(2) and (3)). If we have your email address, we will stop: use the unsubscribe link in any cadence or bulk sales email, which puts your address on our do-not-contact list and stops any series of emails you were in, or reply to any email from us, or write to support@vividrisk.ai, asking us to stop, and our staff will add your address to that list. Our system checks the list before every cadence and bulk sales email, and before it drafts anything for a person it has found.
If we have contacted you only on LinkedIn, we may hold no email address for you to put on that list. Reply there or write to us and our staff will reject or delete your record. Because the list works by email address, our system may find you again in a later search; if you give us an email address to add to the list, our system drops you, before anything is drafted, whenever Apollo returns that address for you.
You also have the rights described in section 5: to a copy of the details we hold about you, to have them corrected or erased, and to restrict our use of them. Email support@vividrisk.ai and we will respond within one month. You can complain to the Data Protection Commission in Ireland or the Information Commissioner's Office in the UK.
Policy Updates
This policy is reviewed annually. Major changes will be notified via the platform dashboard and registered email accounts.