Security at PlentyLabs

PlentyLabs is built and operated in the European Union. This page describes how we protect your data, who can access it, and which third parties are involved. If your security team needs detail beyond what is here, write to us — we would rather answer a specific question than have you guess.

Looking for the plain-language version? Our Trust Center covers content ownership, licensing and privacy without the technical detail.

1. Data residency

Your account data, your projects and all your media are stored and processed in the European Union. Our production environment runs in Google Cloud's europe-west1 region in St. Ghislain, Belgium, with the web application's own server routes in Stockholm. Specifically:

• The primary database (Cloud SQL for PostgreSQL) holding your account, workspace and project data
• All uploaded and generated media, stored in an EU-resident Google Cloud Storage bucket
• Our application and API services, on Google Cloud Run
• The web application's own server routes, which run on Vercel and are pinned to its Stockholm (arn1) region — also in the EU, but a different provider and region from the list above
• Back-ups — managed by Google Cloud and held in the same region as the resource they protect
• Application logs, traces and metrics — collected in-region and not exported to a third-party logging provider
• AI tracing — the prompts and model outputs we retain for debugging and quality work go to our AI observability provider's EU data plane, pinned in our deployment configuration rather than left to a default
• Product analytics, hosted on an EU instance rather than the US default
• Support access — PlentyLabs staff access production from within the EU environment. There is no offshore support tier and no third-party support vendor with access to your workspace data

The exceptions, stated up front rather than buried. First, AI model inference does not happen in the EU. When you generate an image, video, audio track or text, your prompt and any reference images you attach are sent to the provider running that model, and those providers are outside the EU — including the default video model, which runs on infrastructure in Singapore. Second, the third-party service that queues and retries our background generation jobs holds those job payloads, which can include prompts, and it processes in the United States. Those are the only two, and both are named in our sub-processor register, which we provide on request (section 11). We will tell you exactly where a specific model or provider processes if you ask.

Google is a US-headquartered provider; we rely on its EU regional infrastructure and its own transfer safeguards. Content delivery uses a global CDN, so cached copies of your media sit at the edge location nearest a viewer — inherent to content delivery rather than a choice about where your data lives. Access to cached media is gated behind a signed credential.

2. Encryption

• In transit: all traffic between your browser and PlentyLabs is encrypted with TLS. Session cookies are set Secure, HttpOnly and SameSite, and we send HTTP Strict Transport Security.
• At rest: AES-256 encryption on both the database and object storage, via Google-managed keys.
• Connected account credentials: the OAuth tokens that let PlentyLabs publish to your ad accounts receive an additional layer of application-level AES-256-GCM encryption, with separate keys per integration. A database compromise alone would not yield usable credentials for your advertising platforms.
• Passwords are hashed with scrypt. We never store them in a recoverable form and cannot see them.

3. Secrets and infrastructure access

Every production credential is held in Google Secret Manager and injected at deploy time. None are stored in our source code or in container images. Our deployment pipeline authenticates to Google Cloud using Workload Identity Federation, so there are no long-lived service-account keys that could be leaked or stolen.

4. Access control

All data in PlentyLabs is scoped to a workspace, and every API request is authorised against that workspace before any data is returned. There are three roles:

• Owner — full access, including billing, workspace settings and member roles.
• Member — a contributor within the workspace. Members can invite and remove other members; only an owner can change a member's role or delete the workspace.
• Guest — invited to specific sessions rather than the workspace. A guest can only reach the sessions they have been granted, and cannot change workspace settings, membership or invitations. Guests can create content inside a session they have been invited to, including AI generations, which draw on the host workspace's credit balance — invite accordingly.

Our authorisation rules are covered by an automated test suite that asserts, across every permission in the system, that each role can reach only what it should and that any unrecognised permission is denied by default.

5. Authentication

PlentyLabs supports email and password, Google sign-in, one-time email sign-in links, and single sign-on. Sessions expire after 7 days.

• Multi-factor authentication. Users can enrol an authenticator app (TOTP) and are issued single-use backup codes. A workspace owner can require MFA for the whole workspace: a member without a second factor is refused access until they enrol. Administrators can reset a user's second factor, which also ends that user's active sessions.
• Single sign-on (OIDC). We support OIDC single sign-on against your identity provider — Okta, Entra ID, Google Workspace and Keycloak all work. Providers are registered per verified email domain, and a provider can only create or link accounts on a domain it has proved control of. A workspace can be set to require SSO. Where your IdP enforces its own MFA, we can configure that to satisfy our second-factor requirement.

What we do not have: SAML (we support OIDC only), and SCIM automated provisioning and deprovisioning. SSO setup is done by our team during onboarding rather than self-serve in the app — tell us your provider and domain and we will configure it.

6. Application security

• Static analysis. Our entire codebase is scanned nightly with GitHub CodeQL, which traces untrusted input through the code to detect injection, cross-site scripting and similar classes of vulnerability.
• Secret scanning. Every proposed code change is scanned for accidentally committed credentials before it can be merged.
• Dependency management. Third-party dependencies are monitored continuously for known vulnerabilities and updated on a weekly cadence.
• Code review. Changes are reviewed and must pass automated type, lint and test checks before reaching production.
• Browser hardening. We send security response headers including HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy.

7. Vulnerability management

We operate a written vulnerability management policy with remediation times fixed by severity. Findings from code scanning, dependency monitoring, secret scanning, internal review and external researchers are triaged within 2 business days and fixed or mitigated within:

• Critical — 24 hours to fix or mitigate, 7 days to full fix
• High — 7 days to fix or mitigate, 30 days to full fix
• Medium — 30 days to fix or mitigate, 90 days to full fix
• Low — 90 days

Severity starts from the CVSS base score and is adjusted for how the code is actually reached in our deployment, with the reasoning recorded. Anything that cannot be fixed in time needs a time-bounded, approved exception before the deadline, not after it. We do not yet run container image scanning or dynamic (DAST) testing. The policy is available to customers on request, along with a summary of open findings by severity.

8. Incident response and breach notification

We maintain a written incident response plan covering detection, triage, containment, notification and post-incident review, with a defined severity scale and named roles. It is built so that a customer subject to NIS2 can meet their own Article 23 reporting deadlines from what we send them, and so a controller can meet GDPR Article 33.

For any incident affecting your data, measured from the point we become aware of it, we will send you:

• Within 24 hours (target: 12 hours for the most severe) — an initial notification: what happened, when we became aware, which of your data is or may be affected, whether we suspect a malicious act, whether cross-border impact is possible, what we have done, and a named contact. This is what feeds your NIS2 24-hour early warning.
• Within 72 hours — an assessment update: initial severity and impact, the categories and approximate volume of records affected, indicators of compromise where we have them, and containment status. This carries what a NIS2 incident notification and a GDPR Article 33 notification both require.
• On request, at any point — an intermediate status update, so you can answer a request from your own authority.
• Within one month — a final report: detailed description, severity and impact, root cause, mitigations applied and any known cross-border impact. If the incident is still ongoing at that one-month point, you get a progress report then instead, and the final report within one month of the incident being handled — the sequence NIS2 requires, so you are never left without a filing on the date your own deadline falls.

Notification goes by email to the security and privacy contacts you name at contracting, with a phone call in addition for the most severe incidents. Where you have not named contacts, we notify the workspace owner — so name them.

One honest note. This plan was formally documented in August 2026. The practices it describes — on-call, detection, rollback — were already in place, but the first tabletop exercise against the written plan is scheduled rather than completed. We would rather tell you that than let you assume otherwise.

9. AI transparency and the EU AI Act

PlentyLabs generates advertising creative using AI, which brings obligations under Article 50 of the EU AI Act. We have implemented these ahead of the August 2026 deadline:

• Machine-readable provenance. All AI-generated media carries standard IPTC provenance metadata identifying it as AI-generated or AI-modified. This is applied to everything we generate, without exception.
• Visible disclosure. AI disclosure labelling is available in the app, on exports, and burned into published creatives, controlled by a workspace setting so you can meet your own obligations as a deployer.

We can tell you which AI models were involved in producing a given asset.

10. AI providers: training and retention

No provider in our pipeline uses your content to train models under the commercial API terms we operate on, for those providers whose terms we have confirmed — Anthropic, OpenAI, Google and fal.ai. We use paid commercial API tiers, not consumer products or free tiers, and we do not opt in to any data-sharing or model-improvement programme.

We are deliberately not making that a blanket statement across every provider. We use a number of specialist image, video and audio model providers, and for several of them we have not yet obtained written confirmation of their training and retention terms — including the default video model. fal.ai has confirmed that it does not train on your content; its retention window is still to be established. We are working through them, and we will not claim more than we can evidence. If you need a specific provider confirmed — or excluded — before contracting, ask us and we will give you a straight answer on that provider.

Google is a specific case worth stating exactly. Google's Vertex AI terms exclude customer data from training. Its Gemini API does too — but only on the paid tier; the free tier may be used to improve Google's products. We are on the paid tier, verified against the billing configuration rather than assumed, which is why Google is in the confirmed list above.

Prompts and model outputs are also captured as telemetry for debugging and quality work. Both the product analytics and the AI tracing behind this are EU-hosted, as set out in section 1. Neither trains models on your content.

11. Sub-processors

PlentyLabs relies on third parties to operate. The principal categories, and the providers we use today:

• Infrastructure: Google Cloud Platform (EU region — compute, database, storage), Vercel (application delivery, EU region), Fastly (content delivery)
• AI model providers: Anthropic, OpenAI, Google, fal.ai, ElevenLabs and BytePlus/ByteDance, depending on the model selected
• Payments: Stripe
• Operations: transactional email, product analytics, error monitoring and customer support tooling

A complete, current sub-processor register — including what data each one receives and where it processes — is available to customers on request. Write to privacy@plentylabs.com for a Data Processing Agreement, or if you need to review a specific provider before contracting.

12. Privacy, retention and your data rights

We process personal data in accordance with the GDPR and applicable Swedish law. You can delete your account and associated data from within the application at any time. For the full detail on what we collect, why, and the rights you have, see our Privacy Policy.

The retention windows we commit to today:

• Account, workspace and media data — retained while your account is active
• On an account deletion — your database records, then your uploaded and generated media, then the account record itself, erased in that order on a durable pipeline so that a stage which fails can be replayed rather than leaving the account half-deleted. Your analytics profile is anonymised
• If you remove the Meta connector — the active connection and OAuth credentials are removed immediately; Meta-derived information already incorporated into other records follows those records' retention periods
• Authentication sessions — expire after 7 days

What deletion reaches, and what it does not. Deletion now removes your generated and uploaded media from our media store — the gap this page previously said we were fixing. It does not propagate to AI tracing records, back-ups, or the limited retention held by the third parties in section 11; each of those expires on its own schedule. If you need certified erasure across all of it, contact us and we will handle it as a request rather than let this page imply it is automatic.

A more granular retention schedule, including post-termination windows for workspace data and back-up expiry, is being written and is not yet published. Ask us if you need specific windows in a contract.

13. Certifications and independent assurance

PlentyLabs does not currently hold SOC 2 or ISO 27001 certification, and has not completed an independent penetration test or third-party security assessment. We would rather say so plainly than imply otherwise. We are working through the underlying controls and will pursue certification from that foundation.

What we can provide in the meantime, on request: this overview, our incident response plan, our vulnerability management policy, our data residency and sub-processor register, our authorisation test evidence, and our scanning configuration. If your procurement process requires a certification we do not yet hold, contact us and we will be straight with you about timing.

14. Reporting a vulnerability

If you believe you have found a security vulnerability, email security@plentylabs.com. We acknowledge reports within 3 business days and provide an initial assessment within 10. Full details, including scope and researcher guidelines, are in our Vulnerability Disclosure Policy.

15. Contact

Plenty Labs AB (Org.nr: 559454-1855)
Vastgotagatan 2, 118 27 Stockholm, Sweden

For security questionnaires, vulnerability reports, or any question this page does not answer: security@plentylabs.com

For Data Processing Agreements, our sub-processor register, and data-protection questions: privacy@plentylabs.com