> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vikingqa.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance and subprocessors

> Our role under GDPR, where your data is processed, who processes it, and how we fit into your NIS2 obligations.

vikingQA is operated by **Neocap SRL**, 231 Avenue Louise, 1050 Brussels, Belgium
(VAT BE1004693336). We are established in the European Union, which means your contract is with an
EU company under EU law.

This page answers the questions we are most often asked in a security review. If something you need
is not here, email **[privacy@vikingqa.io](mailto:privacy@vikingqa.io)** and we will answer directly.

## Our role under GDPR

```mermaid theme={null}
flowchart LR
    DS["Your end users<br/>(data subjects)"] --> C["You<br/>CONTROLLER<br/>decide why and how"]
    C -->|"documented<br/>instructions"| P["vikingQA<br/>PROCESSOR<br/>acts on your behalf"]
    P -->|"authorised<br/>subprocessors"| SP["Model providers,<br/>hosting, execution"]

    style C fill:#0D9373,color:#fff
    style P fill:#55D799,color:#000
    style SP fill:#f2994a,color:#000
```

**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](mailto: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.

```mermaid theme={null}
flowchart TD
    Q{"What data is in your<br/>test environment?"}
    Q -->|"Synthetic or<br/>anonymised"| G["Recommended.<br/>No personal data is processed.<br/>The question disappears."]
    Q -->|"Copy of<br/>production"| A["Personal data is processed.<br/>You need a lawful basis,<br/>and the controls below apply."]

    A --> A1["Sign our DPA"]
    A --> A2["Scope tests to<br/>the narrowest flows"]
    A --> A3["Shorten retention"]
    A --> A4["Restrict who can<br/>view recordings"]

    style G fill:#0D9373,color:#fff
    style A fill:#f2994a,color:#000
```

### 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:

<Steps>
  <Step title="Put a DPA in place">
    Contact us before you begin. This is a legal prerequisite, not a formality.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Scope tests to the narrowest flow">
    A checkout test does not need a customer list on screen. Fewer records visible means less data
    processed.
  </Step>

  <Step title="Use dedicated test accounts">
    Give the test persona the minimum privileges the test needs. Never reuse a real user's account.
  </Step>

  <Step title="Shorten retention">
    Ask us to reduce your artefact retention below the standard 90 days.
  </Step>

  <Step title="Control who can view recordings">
    Videos and screenshots are visible to members of your organisation. Review your role
    assignments.
  </Step>
</Steps>

### 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

```mermaid theme={null}
flowchart TB
    subgraph EU["European Union"]
        W["Web application"]
        AW["Agent worker — Frankfurt"]
        GW["Realtime gateway — Frankfurt"]
        DB[("Database")]
        BR["Cloud browser"]
        SB["Execution sandbox"]
        S3[("Artifact storage")]
        LS["Agent diagnostics"]
    end

    subgraph US["United States"]
        AN["Anthropic — model inference"]
        OA["OpenAI — model inference"]
    end

    AW -->|"page content,<br/>screenshots"| AN
    W -->|"page content,<br/>screenshots"| OA
    AW -.->|"diagnostic traces"| LS

    style EU fill:#e8f5f1
    style US fill:#fdf0e3
```

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](#other-model-options).

<Note>
  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.
</Note>

## 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](#other-model-options).

### Processing your application's content

| Subprocessor            | Purpose                                           | What it receives                                                | Location      |
| ----------------------- | ------------------------------------------------- | --------------------------------------------------------------- | ------------- |
| **Anthropic**           | The model that explores your app and writes tests | Page structure, screenshots, chat messages. **No credentials.** | United States |
| **OpenAI**              | Assertion evaluation and assisted authoring       | Page content and screenshots for the assertion being evaluated  | United States |
| **Amazon Web Services** | Artefact storage (S3)                             | Screenshots, video, traces, console and network logs            | EU            |

**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](/security/data-protection#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](mailto: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](mailto: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.

|                                     | **We manage it**         | **You manage it**                       |
| ----------------------------------- | ------------------------ | --------------------------------------- |
| Provider account and contract       | Ours                     | Yours                                   |
| Appears in your subprocessor list   | Yes, as our subprocessor | No — the provider is your own processor |
| Who holds the DPA with the provider | We do                    | You do                                  |
| Setup                               | We configure it          | You give us an endpoint and credentials |

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.

| Requirement                                       | Why                                                                                                                         |
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Reachable over an API** from our infrastructure | We call the model from our agent worker. A hosted endpoint, your own gateway, or a private deployment we can reach all work |
| **Vision-capable**                                | The agent reads screenshots of your application to decide what to do next                                                   |
| **Tool calling**                                  | The agent works by calling tools — navigate, click, type, write the test script                                             |
| **Passes our evaluation suite**                   | See below                                                                                                                   |

### 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.

| Request                                 | How we help                                                         |
| --------------------------------------- | ------------------------------------------------------------------- |
| **Access** — what data do you hold      | We provide an export of your organisation's data                    |
| **Erasure** — delete this person's data | We delete on your instruction, and on contract termination          |
| **Rectification**                       | Correct the source and re-run the test                              |
| **Portability**                         | Your tests are standard Playwright scripts. Export them at any time |
| **Restriction / objection**             | Pause the project or delete the affected test cases                 |

For your own team members' accounts, deletion anonymises their personal data irreversibly.

Send requests to **[privacy@vikingqa.io](mailto: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:

```mermaid theme={null}
flowchart LR
    N["NIS2 Directive"] --> Y["Your organisation<br/>IN SCOPE"]
    Y -->|"Art. 21(2)(d)<br/>supply chain security"| V["vikingQA<br/>your supplier"]
    V -->|"security measures<br/>+ 24h incident notice"| Y
    Y -->|"Art. 23<br/>24h / 72h reporting"| A["Your national<br/>authority"]

    style Y fill:#0D9373,color:#fff
    style V fill:#55D799,color:#000
```

### What we provide to support your obligations

| Your NIS2 obligation                  | What we provide                                               |
| ------------------------------------- | ------------------------------------------------------------- |
| Supply chain security — Art. 21(2)(d) | This page, our DPA, and direct answers to your questionnaire  |
| Incident handling — Art. 21(2)(b)     | 24-hour breach notification, described above                  |
| Incident reporting — Art. 23          | Notification timed so you can meet your 24h and 72h deadlines |
| Access control — Art. 21(2)(i)        | Role-based access, organisation and project scoping           |
| Cryptography — Art. 21(2)(h)          | TLS in transit; AES-256-GCM for credentials at rest           |
| Business continuity — Art. 21(2)(c)   | Managed database with automated backups                       |

## 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

| Topic                                                | Address                                                 |
| ---------------------------------------------------- | ------------------------------------------------------- |
| Privacy, data protection, DPA, data subject requests | **[privacy@vikingqa.io](mailto:privacy@vikingqa.io)**   |
| Security vulnerabilities                             | **[security@vikingqa.io](mailto:security@vikingqa.io)** |
| Everything else                                      | **[support@vikingqa.io](mailto:support@vikingqa.io)**   |

Neocap SRL, 231 Avenue Louise, 1050 Brussels, Belgium.