Our role under GDPR
You are the controller. You decide which application to test, which environment to point us at, and what data exists in it. We are the processor. We act only on your instructions, expressed through your configuration and your test cases. We are a controller only for our own account data — the names and email addresses of your team members who log in, and billing information. A Data Processing Agreement covering Article 28 is available on request. Ask at privacy@vikingqa.io.Testing with realistic data
This is the most important section on this page, and the one we would ask you to read even if you skip the rest.Our recommendation
Do not copy production data into the environment you point vikingQA at. Use synthetic or anonymised data instead. We say this plainly because it is both the correct legal position and the most effective control available to you — and it removes an entire category of risk rather than mitigating it.Why this matters here specifically
To write a test that clicks the right button, our agent must read the page. It receives the structured text of the page and screenshots of it, and sends those to a model provider. Screenshots and video of the run are also stored as artefacts so you can debug a failure. So if your test environment holds a copy of production, then real names, email addresses, order histories and anything else visible on screen are processed by us and by our model subprocessor. That is not a vikingQA-specific problem. Copying production data into a non-production environment already sits uncomfortably with the GDPR principles of purpose limitation and data minimisation (Article 5), and it is a finding most auditors raise on its own. The exposure begins before we are involved.If production-like data is unavoidable
Some systems genuinely cannot be exercised without realistic data. If that is your situation:1
Put a DPA in place
Contact us before you begin. This is a legal prerequisite, not a formality.
2
Use pseudonymised data where you can
Realistic shape is usually what matters for a test — realistic values rarely are. A
generated dataset with the same structure exercises the same code paths.
3
Scope tests to the narrowest flow
A checkout test does not need a customer list on screen. Fewer records visible means less data
processed.
4
Use dedicated test accounts
Give the test persona the minimum privileges the test needs. Never reuse a real user’s account.
5
Shorten retention
Ask us to reduce your artefact retention below the standard 90 days.
6
Control who can view recordings
Videos and screenshots are visible to members of your organisation. Review your role
assignments.
What vikingQA gives you to make this easier
Test personas let you define who a test acts as, without embedding a real person’s identity. Variables and environments let the same test run against different data in different environments — so a synthetic dataset in your test environment does not force you to rewrite tests. Credentials are stored encrypted and never reach a model, so a test account’s password is not part of the exposure.Where your data is processed
Storage and execution are in the EU. Model inference is not, by default. We default to frontier models because capability is what decides whether a generated test actually works, and the most capable models available today are US-hosted. That is a default we have chosen, not a fixed property of the product. Transfers are covered by Standard Contractual Clauses in each provider’s data processing agreement. And if inference outside the EU does not suit you, we are open to other arrangements — see Other model options.One honest technical caveat. Our execution sandbox provider routes work to an EU region, but
documents that individual payloads larger than 2 MiB are still written to object storage in the
United States. We would rather state this than let you discover it later.
Subprocessors
We name the model providers, because which model reads your application is the question most security reviews turn on. For every other subprocessor we describe what it does, what it receives and where it runs, and we name it individually in our Data Processing Agreement. The model providers below are our defaults. They can be changed for your organisation — see Other model options.Processing your application’s content
Anthropic and OpenAI do not train their models on data submitted through their commercial
interfaces. This is a contractual commitment in their agreements, not a setting we opt into.
Three further specialised providers also handle your application’s content. All three run in the
EU:
- A cloud browser provider runs the browser the agent drives. It sees everything the browser sees, including the session video recording.
- A sandbox provider runs your generated Playwright tests in isolation. It receives the test script and the runtime environment it executes in.
- An agent observability provider stores diagnostic traces of agent runs, which include page structure and screenshots.
Platform and infrastructure
Underneath those, we use a small number of standard providers: application hosting, our database, the layer that streams live progress to your browser, background job orchestration, error monitoring, authentication, billing and transactional email. Some of these are in the path of your application’s content, and we would rather be explicit about that than let the heading imply otherwise. Hosting, the database and the streaming layer all carry it, and the database retains it for the periods set out under Data retention. Authentication, billing and email handle your team’s account details only. Application hosting, the database, the streaming layer and error monitoring are in the EU. Authentication, billing, background job orchestration and transactional email are United States providers, covered by Standard Contractual Clauses.Getting the full list
Every subprocessor is named individually in our Data Processing Agreement, and we will send you the current list on request at privacy@vikingqa.io — before you sign anything, if that helps your review. We will give you 30 days’ notice before adding a new subprocessor, and you may object.Other model options
Our defaults are a starting point, not a fixed position. If a different model suits your requirements better, we are open to it — talk to us at privacy@vikingqa.io and we will work it out with you. Teams usually raise this for one of a few reasons:- Data residency — you want inference to stay in the EU, or in a specific jurisdiction.
- An existing vendor agreement — you already have a contract, a DPA and a completed assessment with a model provider, and you would rather not add a new one.
- A private or self-hosted model — you run your own deployment and nothing may leave it.
Who runs it
Both arrangements work, and which one makes sense is mostly a question of where you want the contractual relationship to sit.
Neither is the “right” answer. Managing it yourself gives you a direct relationship with the
provider and keeps them off the list you inherit from us. Letting us manage it means one contract
instead of two. We are happy to discuss either.
What a model needs to be able to do
This is a capability question rather than a commercial one. The agent drives a real browser, so these are the things it genuinely cannot work without.The evaluation suite
We maintain a suite of graded scenarios that measures whether a model can actually author a working test: whether it explores an application sensibly, produces a script that runs, and does not invent selectors that do not exist. We run a candidate model against it before recommending it. This protects you more than it protects us. A weaker model does not fail loudly — it produces tests that look plausible, pass review, and then quietly miss regressions. We would rather tell you a model is not a good fit than let you discover it from a bug that reached production. Capability differences also show up in cost. Some providers support server-side tool search, which keeps unused tool definitions out of the model’s context; models without it receive the full tool list on every call and use more tokens for the same work. We will tell you what to expect.What changes for you
The model you choose replaces our default in the subprocessor table above for your organisation, and your data stops flowing to the provider it replaces. If you manage the provider yourself, it leaves our subprocessor list entirely and becomes your own processor. Either way, we will confirm in writing which subprocessors apply to your account, so your records of processing stay accurate.Your rights and your customers’ rights
As the controller, you handle requests from your own data subjects. We assist you as processor.
For your own team members’ accounts, deletion anonymises their personal data irreversibly.
Send requests to privacy@vikingqa.io.
Security incidents
If we suffer a personal data breach affecting you, we will notify you without undue delay and within 24 hours of becoming aware of it. That timing is deliberate: it is designed to leave you enough of your own 72-hour GDPR window, and enough of your NIS2 early-warning window, to act. Our notification will include what happened, what data was affected, what we have done, and what we recommend you do.NIS2
Is vikingQA in scope of NIS2?
Almost certainly not, and we think it is more useful to say so than to imply otherwise. The Network and Information Security Directive 2 applies to medium and large entities in listed sectors. We are below the size threshold, and we do not fall into any of the categories that are in scope regardless of size — DNS providers, top-level domain registries, qualified trust service providers, public electronic communications networks and public administration. We do not install, manage, operate or maintain your ICT infrastructure, so we are not a managed service provider.Why you are still right to ask
You are likely in scope, and Article 21(2)(d) makes you responsible for the security of your supply chain. Your obligation reaches us through your contract, not through our own regulatory duty. Here is how the relationship works:What we provide to support your obligations
The EU AI Act
vikingQA uses general-purpose AI models to author software tests. Testing your own software is not a high-risk use under Annex III of the AI Act, so the high-risk obligations do not apply. We meet the transparency expectations of Article 50 by telling you plainly which parts of the product are AI-driven — the agent that explores your application and writes tests — and which are not. Once a test is written, it runs as a deterministic Playwright script with no model involved. Our model providers carry the general-purpose AI model obligations for the models themselves.Certifications
We hold no SOC 2 or ISO 27001 certification today, and no independent penetration test has been completed. We would rather tell you than let you assume otherwise. What we offer instead: direct, technical answers to your security questionnaire, this documentation, and a call with the engineers who built the system. If a certification is a firm requirement for you, tell us — it is useful input to our roadmap.Contact
Neocap SRL, 231 Avenue Louise, 1050 Brussels, Belgium.