Jump to section
1. Data controller
Audulate (“Audulate”, “we”, “us”, “our”) is the data controller for personal data processed through this website (audulate.com) and the Audulate platform (app.audulate.com).
You can contact us by email or by post about anything in this notice — full details are in section 13 below.
When you use Audulate to scan your websites and process your compliance data, Audulate acts as a data processor on your behalf and you are the controller. That relationship is governed by our Data Processing Agreement (DPA), available on request.
2. Data we collect
2.1 Data you provide directly
- Account data — full name, work email address, company name, and job title. Passwords are handled by our authentication provider (Supabase Auth) and stored as bcrypt hashes; we never see or store plaintext passwords.
- Profile data — optional profile picture, timezone, and communication preferences.
- Billing data — billing name, company, and address. Payment card details are processed and stored by Stripe; we never see or store raw card numbers or CVVs.
- Communications — messages sent via our contact form, support tickets, and any feedback you submit. If you subscribe to our newsletter, we store your email address for that purpose.
- Compliance workspace data — URLs you add for scanning, GitHub repository connections, GDPR module data (RoPA entries, DSR records, DPIA assessments, vendor details, breach records), and any notes or evidence you upload.
- Infrastructure connections — when you connect a cloud account (AWS, Google Cloud, Azure, DigitalOcean), a managed-database provider (Supabase, Neon, PlanetScale, MongoDB Atlas, Aiven), or a PaaS / edge provider (Vercel, Cloudflare) for infrastructure scanning, you provide access credentials. These are encrypted before storage (see Security measures) — we retain only a short key hint (the last few characters of the access key ID) in readable form, alongside the provider and default scan region. Each credential is scoped either tenant-wide or bound to a single website you have added; the scope governs which scans it is used for and which reports its findings appear in.
- Site ownership attestation — to scan a website you confirm you own it or are authorised to scan it. We record that confirmation (the acting user, timestamp and IP address) and a verification token, and we perform DNS/HTTP look-ups against the domain you ask us to verify. This is kept as audit evidence of authorisation and is not used for any other purpose.
2.2 Data we collect automatically
- Log data — IP address, browser type and version, operating system, referring URL, pages visited, time and duration of visits.
- Usage analytics — features used, scans triggered, reports generated, and other product interaction events. Within the application these are captured via our own server-side logs only — no cookies, no cross-site tracking, no third-party analytics services. (Marketing-site analytics are covered separately in section 9.)
- Device data — screen resolution and language settings used to optimise the interface.
- Audit logs — a record of all actions taken in your account (who did what, when) for security and compliance purposes.
2.3 Data from third-party integrations
- Code repositories (GitHub, GitLab, Bitbucket) — when you connect a code host, we receive repository metadata, pull request diffs, and file contents for the purposes of compliance scanning. We do not store full repository contents; brief code snippets may appear in finding evidence to illustrate the issue.
- Identity providers (Okta, Microsoft Entra ID, Google Workspace) — when you connect an identity provider, we read your directory of users and groups (email, name, administrator status, account status, last sign-in, multi-factor-authentication enrolment / enforcement, and organisational unit) to evidence your access-control and people-security controls. Read-only.
- HR systems (Rippling, BambooHR, Gusto) — when you connect an HR system, we read your employee roster (email, name, employment status, start / end dates, role, and department) and, where the provider exposes them, the completion dates of NDA signature and background checks. The underlying documents are not processed.
- Device management / MDM (Jamf, Microsoft Intune) — when you connect an MDM, we read your managed-device fleet (device name, platform and OS version, disk-encryption and compliance status, the assigned owner's email, and last check-in time) to evidence device-security controls. Read-only — we do not access the contents of any device.
- Security telemetry (CrowdStrike, Snyk) — from a connected EDR we read host inventory and protection status (hostname, hardware serial, platform / OS, agent version, whether the sensor is running, and last-seen time); from a connected vulnerability scanner we read each project's open-vulnerability counts by severity. We do not read endpoint file contents or your source code.
- Ticketing (Jira, Linear) — when you connect a ticketing system, we read change-management ticket metadata (summary / title, type, status, priority, the assignee's name, and due / created / resolved dates) to evidence change-control. Read-only — we do not modify your tickets.
- Stripe — we receive subscription status, plan type, and payment event webhooks. No raw payment data is stored on our infrastructure.
- Cloud infrastructure (AWS, Google Cloud, Azure, DigitalOcean) — when you connect a cloud provider, we use your stored credentials to read infrastructure configuration and security settings (for example storage, network, IAM, encryption and logging configuration) in order to run the compliance checks you trigger. We store the resulting findings, scores and evidence; we do not copy or store the contents of your data stores, databases, or workloads.
- Managed databases (Supabase, Neon, PlanetScale, MongoDB Atlas, Aiven) — when you connect a managed-database account, we use your stored API token to read project / cluster metadata (region, network access list, authentication settings, backup configuration, branch-protection state). Read-only — we never modify project settings, schema, or data. We do not read or store the contents of your databases.
- PaaS & edge (Vercel, Cloudflare) — when you connect a PaaS or edge provider, we use your stored API token to read project / zone metadata (serverless function regions, environment-variable types, preview-deployment protection state, R2 bucket public-access flags, Worker binding types, DNSSEC status, Access policy structure, WAF managed-rules deployment). Read-only — we never modify any project, environment variable, Worker, bucket, zone, Access app or WAF rule. We do not read the value of any encrypted or sensitive environment variable / secret binding; the provider APIs do not return those.
2.4 How we use AI on your data
The AI uses worth calling out by name:
- Compliance Copilot (AI assistant) — the in-app chat assistant. When you send it a message, it reads your own workspace's compliance data through read-only tools (findings, controls, policies, GDPR/ISO 27001/SOC 2 records and similar) and sends the relevant results plus your question to the model to compose an answer. It is strictly read-only — it cannot create, edit, delete, or trigger anything — and only ever sees your own tenant's data. Credentials, API keys, and other secrets are never exposed to it. Usage is capped per tenant (daily and monthly), and conversations are stored in your workspace and logged for safety and cost accounting.
- Compliance summaries & remediation guidance — when you open a finding, we may run an AI summary that takes the finding's rule, severity, and evidence (the same fields visible to you in the UI) and produces a plain-language explanation. No raw account, billing or third-party-integration secrets are sent to the model. AI cost is capped per tenant per month.
- Industry classification — we classify your tenant's industry from the public website URL and the business description you provide during onboarding. The classification runs once per tenant and is stored alongside a confidence score. It is used to apply industry-aware severity overrides (for example, treating a breach-notification finding as CRITICAL rather than HIGH for fintech and healthtech); these overrides only take effect when the confidence score is at least 0.5. You can edit or clear the inferred industry at any time from Settings → Business Profile.
- PR code review — when you opt in by installing the GitHub App, snippets of your code diff are sent to the model for analysis of GDPR-sensitive patterns (PII leaks, insecure logging, hardcoded secrets). Results are written back to the PR as comments and stored as findings. Whole files are not sent.
We use enterprise-grade model providers that do not train on customer inputs. AI responses are logged for safety review and cost accounting; the log is retained according to the same retention schedule as other workspace data.
2.5 Outbound notifications
Audulate sends notifications to addresses or endpoints you configure under Settings → Notifications:
- Email — to the addresses on your account and any additional addresses you list, via our email sub-processor (Resend). Subject and body are derived from event data — never include passwords, raw credentials, or full PII payloads.
- Slack — to an incoming-webhook URL you supply. We verify the URL is publicly reachable but otherwise pass through whatever Slack workspace you point us at.
- Webhook — to a URL you supply. We refuse to send to private-network destinations (RFC 1918, link-local, etc.) to prevent server-side request forgery via your webhook configuration.
- Event types — scan completed, critical finding detected, regulation update, PR review completed, infra scan completed, sub-processor changes, and (new) volume-spike. The volume-spike event fires when open-finding counts cross thresholds the score formula caps; the email body contains aggregate counts and a link back to the dashboard but no individual finding payloads.
You can disable any event type or any channel from Settings → Notifications at any time.
3. How we use your data
| Purpose | Data used | Legal basis |
|---|---|---|
| Provide and operate the platform | Account, workspace, integration data | Contract (Art. 6(1)(b)) |
| Process payments and manage subscriptions | Billing data, Stripe webhooks | Contract (Art. 6(1)(b)) |
| Send transactional emails (receipts, alerts, DSR notifications) | Email address | Contract (Art. 6(1)(b)) |
| Run AI-powered compliance summaries and remediation guidance | Scan results, findings (anonymised where possible) | Contract (Art. 6(1)(b)) |
| Improve the product and fix bugs | Usage analytics, error logs | Legitimate interests (Art. 6(1)(f)) |
| Detect and prevent fraud, abuse, and security incidents | Log data, audit logs, IP addresses | Legitimate interests (Art. 6(1)(f)) |
| Comply with legal obligations (VAT, accounting records) | Billing data | Legal obligation (Art. 6(1)(c)) |
| Send marketing emails and product updates | Email address | Consent (Art. 6(1)(a)) — withdraw at any time |
| Respond to support requests | Communications data | Legitimate interests (Art. 6(1)(f)) |
4. Legal bases for processing
Under UK GDPR and EU GDPR (Article 6), we rely on the following legal bases:
- Contract performance (Art. 6(1)(b)) — processing necessary to provide the service you have signed up for, including account management, scanning, and billing.
- Legitimate interests (Art. 6(1)(f)) — processing for purposes such as fraud prevention, security monitoring, product analytics, and improving service quality. We have conducted legitimate interests assessments (LIAs) and determined our interests are not overridden by your rights in these contexts.
- Legal obligation (Art. 6(1)(c)) — where processing is required to comply with applicable law (e.g., retaining financial records for HMRC purposes).
- Consent (Art. 6(1)(a)) — for optional activities such as marketing communications. You may withdraw consent at any time by clicking “Unsubscribe” in any marketing email or by emailing [email protected].
6. Data retention periods
| Data category | Retention period | Reason |
|---|---|---|
| Account data | Duration of account + 3 years after closure | Legal disputes, audit |
| Scan results & findings | Per plan retention window (30 days – 2 years) | Service provision |
| Evidence files (PDFs, screenshots) | Per plan retention window | Service provision |
| Infrastructure connection credentials | Until you disconnect the integration or delete the account | Service provision |
| Billing records | 7 years from transaction | HMRC / VAT obligations |
| Audit logs | Duration of workspace + tenant-purge sweep on request | Security & fraud detection, ISO 27001 / SOC 2 audit defensibility |
| Support communications | 3 years from last interaction | Service quality |
| Marketing consent records | Until consent is withdrawn + 1 year | Compliance with consent obligations |
| Server access logs | 90 days | Security monitoring |
6.1 Account deletion & the 30-day grace period
The account owner can request deletion of the workspace and all of its data at any time from Settings → Danger zone (a typed confirmation is required). When a deletion request is submitted:
- The requesting account is immediately signed out of every device and session, and a confirmation email stating the exact deletion date is sent to the workspace owner and administrators.
- A 30-day grace period begins. The data is retained but the account is pending erasure. We send a reminder email before the grace period ends.
- Signing in again at any point during the 30 days automatically cancels the deletion and retains all data — no further action is needed, and a cancellation confirmation email is sent. This is intentionally fail-safe: any sign of account activity stops the erasure.
- If no one signs in for the full 30 days, the workspace and all associated personal data (scans, findings, reports, data-subject requests, cookies, data inventory, integrations and audit logs) are permanently and irreversibly erased, and member identities that belong to no other workspace are deleted from our authentication provider. Erased data cannot be recovered.
After erasure, only records we are legally required to keep (e.g. billing/VAT records, and audit evidence of the deletion itself) are retained for the periods stated in the table above; these contain the minimum data necessary and are not used for any other purpose.
7. International data transfers
The majority of your data is stored and processed within the EU/EEA. Where sub-processors are based outside the EU (notably Stripe, OpenAI, Anthropic, and GitHub, which are based in the USA), transfers are protected by:
- Standard Contractual Clauses (SCCs) — approved by the European Commission under Article 46(2)(c) GDPR.
- UK International Data Transfer Agreements (IDTAs) — for transfers subject to UK GDPR.
We do not transfer data to countries without an adequacy decision or appropriate safeguards in place. Copies of our transfer impact assessments are available to Enterprise customers on request.
8. Your rights under GDPR
Under UK GDPR and EU GDPR (Articles 15–22), you have the following rights:
- Right of access (Art. 15) — request a copy of the personal data we hold about you and information about how we use it.
- Right to rectification (Art. 16) — request correction of inaccurate or incomplete personal data.
- Right to erasure (Art. 17) — request deletion of your personal data where there is no legitimate reason for us to continue processing it.
- Right to restrict processing (Art. 18) — request that we limit processing while a dispute about accuracy or lawfulness is resolved.
- Right to data portability (Art. 20) — receive your data in a structured, machine-readable format (JSON) to transfer to another provider.
- Right to object (Art. 21) — object to processing based on legitimate interests or for direct marketing (which will always be honoured immediately).
- Rights related to automated decision-making (Art. 22) — Audulate does not make decisions that produce significant legal effects using fully automated processing.
To exercise any right, email [email protected] or use the data export and account deletion options in your account settings. We will respond within 30 days. Where a request is complex or numerous, we may extend this by a further two months with notice.
We will not charge a fee for reasonable requests. If requests are manifestly unfounded or excessive, we may charge a reasonable fee or refuse.
10. Security measures
We implement the following technical and organisational measures to protect your data:
- Encryption in transit — all data transferred over TLS 1.2 or higher (HTTPS enforced everywhere).
- Encryption at rest — database volumes encrypted using AES-256.
- Connected-credential storage — credentials for connected cloud accounts (AWS, Google Cloud, Azure) are additionally encrypted at the application layer with AES-256-GCM before being written to the database. Only a short, non-sensitive key hint is stored in readable form, and the credentials are used solely to run the scans you initiate.
- Password storage — passwords are handled by our authentication provider (Supabase Auth), which stores them as bcrypt hashes; plaintext passwords are never seen or stored by Audulate.
- Multi-tenant isolation — strict row-level security (RLS) policies in PostgreSQL ensure one tenant can never access another's data.
- Access controls — internal access to production systems is restricted by role and logged in our audit system.
- Penetration testing — we commission independent third-party penetration tests on an annual cadence and remediate findings within agreed SLAs.
- Vulnerability management — we monitor dependency vulnerability advisories from our package registries and prioritise critical security updates.
- Incident response — we maintain a documented incident response plan. Breaches affecting your rights will be notified to you and the relevant supervisory authority within 72 hours (Art. 33/34 GDPR).
Despite these measures, no system is 100% secure. If you discover a security vulnerability, please report it responsibly to [email protected].
11. Children's privacy
Audulate is a business-to-business service intended for organisations and their employees. We do not knowingly collect personal data from individuals under the age of 16. If you believe a child has provided us with personal data, please contact us immediately at [email protected] and we will delete it promptly.
12. Changes to this policy
We may update this Privacy Policy from time to time to reflect changes in our practices, technology, legal requirements, or other factors. When we make material changes, we will:
- Update the “Last updated” date at the top of this page.
- Display an in-app banner notifying you of the change.
- For significant changes affecting your rights, send an email notification at least 30 days before the change takes effect.
Your continued use of Audulate after a policy update constitutes acceptance of the revised policy.
13. Contact & supervisory authority
For any privacy-related questions, requests, or complaints:
You also have the right to lodge a complaint with a supervisory authority. In the UK: the Information Commissioner's Office (ICO). In the EU: the supervisory authority in your country of residence or the Irish Data Protection Commission (DPC) if your complaint relates to a cross-border processing activity.
We would always prefer the opportunity to address your concern directly before you approach a supervisory authority, but you are entitled to contact the authority at any time.
© 2026 Audulate.