Security

This page describes the measures actually in place. It is written to be checked rather than to reassure, so where something is not in place it says so instead of reaching for a phrase like “enterprise-grade” that means nothing. If you are doing vendor due diligence and need more than this, write to security@bidhelm.com.

1. What We Hold, and What We Deliberately Do Not

The most sensitive thing we hold is not data - it is write access to your Google Ads account. So the honest place to start is with what is not held at all:

• No Google password. Access is by OAuth 2.0 token, granted by you and revocable by you at myaccount.google.com/permissions, taking effect immediately.
• No card numbers. Payment details go to the payment provider, which is a regulated institution and the Merchant of Record. They never reach our systems.
• No access to your Google billing. The scopes we request do not include it.
• No tracking on your own website. We place nothing on it.

2. Encryption

• In transit: TLS on every connection - browser to site, site to API, API to database, API to every third party. HTTP is redirected, not served.
• At rest: the database is a managed PostgreSQL service with encryption at rest enabled, in the European Union. Backups inherit the same encryption.
• OAuth tokens live only in that database, are never sent to the browser, and are never written to logs. Log output is filtered for credential-shaped values.

To be precise about a distinction vendor questionnaires often ask about: tokens are protected by encryption of the database and its backups, not by a separate application-layer cipher on the column. If your assessment requires column-level encryption with a customer-held key, we do not offer that today.

3. Access Control

• Sign-in and session management run through a dedicated identity provider, with multi-factor authentication available on every account. Use it.
• Inside an organisation, access is by role - owner, admin, member - and the permissions each role carries are visible and adjustable in your settings.
• Every request is scoped to the organisation it belongs to, enforced on the server rather than by the interface, so an account cannot read another's data by manipulating a request.
• Administrative access to production is limited to personnel who need it to operate the Service, and is separate from the customer-facing application.

4. What Limits the Damage an Automated Change Can Do

Security here is not only about who can read your data. It is about what the Service can do to your account. So:

• A kill switch stops every write to every Google Ads account, immediately, without a deploy. It has been exercised against production rather than assumed to work.
• Every automated change is recorded - what changed, when, and why - and is visible to you in the dashboard.
• Before a destructive change, the previous state is stored first. A landing page publish stores your ads' original destination URLs before touching them, so they can be put back.
• You can shorten the leash. Any category of change can be set to require your approval, and changes then wait as drafts.
• Nothing client-owned is deleted. The Service does not delete campaigns, ads, or assets that belong to you; it pauses, excludes, or supersedes them.

5. Application Security

• Input is validated against explicit schemas at the boundary, not trusted from the client.
• Landing-page form submissions are rate-limited per address and per page, with automated submissions rejected before they are stored.
• Dependencies are kept current, and the codebase is type-checked and linted on every change.
• Secrets live in the deployment environment, never in the repository.

6. Monitoring and Response

Application logs and errors go to a dedicated observability platform with alerting on failure conditions. Logs are retained for operational purposes and can incidentally contain identifiers such as an account ID or an IP address; they are not used for any other purpose.

A breach affecting a customer's data is notified within 48 hours, on the terms in Section 7 of the Data Processing Addendum. A breach affecting personal data we control is notified to the people affected and to the relevant authority within the deadlines the law sets.

7. Certifications - What We Do Not Have

We do not hold SOC 2, ISO 27001, or any comparable certificate, and we have not had a third-party penetration test. Saying so is more useful to you than a page implying otherwise. If a certificate is a procurement requirement for you, we are not the right vendor yet, and we would rather you knew that before you subscribed than after.

What we can give you instead: a straight answer to any security question, the measures above in writing, and the sub-processor and location detail on the Sub-processors page.

8. Reporting a Vulnerability

Send it to security@bidhelm.com. Include what you found and how to reproduce it. We aim to acknowledge within two business days.

We will not pursue legal action against anyone who reports a vulnerability in good faith - meaning you tested only against your own account, did not access, alter, or retain anyone else's data, did not degrade the Service for others, and gave us a reasonable chance to fix it before publishing. We have no bounty programme; we will credit you if you would like that.

9. What You Control

• Turn on multi-factor authentication.
• Set account-level budget caps in Google Ads. The Service does not override them.
• Review who has a seat in your organisation, and remove people who have left.
• Require approval for the categories of automated change you would rather see before they happen.
• Revoke our Google access at any time, without cancelling anything.

10. Contact

Security: security@bidhelm.com · Privacy: privacy@bidhelm.com