DORA Art. 30 pack
DORA (Regulation (EU) 2022/2554) applies to financial entities, not to their vendors directly. TestingBot is an ICT third-party service provider under DORA and is not a designated critical ICT third-party provider (CTPP). What DORA requires of your contract with us is set out in Art. 30(2) and, where TestingBot supports a critical or important function, Art. 30(3). This page states our position clause by clause, provides the data your Register of Information filing needs, and links every supporting document.
Legal entity
Norento BV (trading as TestingBot)
EUID (KBO/BCE): BE 0842.864.474
Service type (ESA taxonomy)
S17 Cloud services: SaaS
Not a designated CTPP
Provided from
Belgium, Germany
Data stored in Belgium, Germany, Ireland
Governing law
Belgium
Version 1.0, reviewed July 27, 2026
Art. 30(2): every ICT contract
The clauses DORA makes mandatory in every contract between a financial entity and an ICT provider, and TestingBot's position on each.
| Clause | Requirement | TestingBot position | Status |
|---|---|---|---|
| 30(2)(a) | Clear service description; whether subcontracting of a critical or important function is permitted and under which conditions | The service is described in the Order Form and product documentation. Subcontracting is permitted only per the live sub-processor register on this site, with 30 days advance notice for material changes affecting critical or important functions and a 14-day objection right under the DPA. | In place |
| 30(2)(b) | Locations (countries) where the service is provided and where data is processed and stored, with advance notice of changes | Provided from Belgium and Germany; data stored in Belgium, Germany and Ireland; data processed in Belgium and Germany. Changes are announced via the sub-processor notice mechanism before they take effect. | In place |
| 30(2)(c) | Provisions on availability, authenticity, integrity and confidentiality of data | TLS 1.2+ in transit, AES-256 at rest, role-based access control with enforced invariants, audit logging with CSV export, log redaction. Detailed in the TOMs and Security Whitepaper. | In place |
| 30(2)(d) | Access, recovery and return of data on insolvency, resolution, discontinuation or termination | Test artefacts and account data export over the REST API at any time; on termination, data return and deletion per the DPA. The exit summary below describes the transition path. | In place |
| 30(2)(e) | Service level descriptions, including updates and revisions | Published service level description (sla.pdf on this site) covering the availability target, the external measurement method and the operational indicators; versioned and incorporated into the addendum. | In place |
| 30(2)(f) | Incident-related assistance at no additional cost or at a cost determined ex ante | Assistance with incidents affecting the TestingBot service is provided at no additional cost. Assistance with customer-side incidents where TestingBot is not the cause is available at a rate fixed in the contract. | In the addendum |
| 30(2)(g) | Full cooperation with the competent authorities and resolution authorities of the customer | TestingBot contractually commits to full cooperation with the customer's competent and resolution authorities, including access to information on request. | In the addendum |
| 30(2)(h) | Termination rights and minimum notice periods, per competent-authority expectations | The DORA addendum grants the Art. 28(7) termination grounds with a minimum notice period stated in the Order Form. | In the addendum |
| 30(2)(i) | Participation in the customer's ICT security awareness programmes and digital operational resilience training | TestingBot participates in customer security-awareness and resilience training on request. | In the addendum |
Art. 30(3): critical or important functions
Additional clauses that apply where TestingBot supports a critical or important function of your institution.
| Clause | Requirement | TestingBot position | Status |
|---|---|---|---|
| 30(3)(a) | Full service level agreements with precise quantitative and qualitative performance targets | The published service level description defines the 99.9% availability target, its external measurement method and the operational indicators (session provisioning success rate, p95 queue-to-start, API error rate); monthly published figures begin with the first full month of external probing. | In preparation |
| 30(3)(b) | Notice periods and reporting obligations, including notification of developments that may materially impair service | The incident notification commitment below, including material-impairment notification and a fixed update cadence sized to the customer's Art. 19 reporting clocks. | In the addendum |
| 30(3)(c) | Obligation to implement and test business contingency plans and maintain ICT security measures | A business continuity and disaster recovery programme with tested restores is being built; the first dated DR test report will be published to this site on completion. | In preparation |
| 30(3)(d) | Participation in the customer's threat-led penetration testing (Arts. 26-27), including pooled testing | TestingBot commits to participate in customer TLPT, including pooled testing under Art. 26(4)-(5). | In the addendum |
| 30(3)(e) | Unrestricted access, inspection and audit rights for the customer, its appointee and the competent authority; alternative assurance levels may be agreed | TestingBot grants unrestricted audit and inspection rights to the customer, its appointee and the competent authority. As alternative assurance matures (independent penetration test, certification), Art. 30(3)(e)(ii) alternative assurance levels can be agreed. | In the addendum |
| 30(3)(f) | Exit strategy with an adequate transition period | Exit is low-complexity by construction: standard test protocols, no proprietary formats, REST API export. The addendum grants a transition period stated in the Order Form during which the service continues under the same terms. | In the addendum |
Incident notification commitment
Your Art. 19 clocks start when you classify an incident, and you cannot classify what you do not know about. Our notification commitment is therefore sized to sit inside your reporting windows, with a fixed update cadence so your 72-hour intermediate report has our hour-6 and hour-24 updates to draw on.
| Severity | Definition | First notice | Update cadence |
|---|---|---|---|
| SEV1 | Confirmed breach of confidentiality or integrity of customer data, or full unavailability of the service | Within 4 hours of declaration | Updates at least hourly until resolution |
| SEV2 | Partial unavailability or significant degradation of the service | Within 24 hours | Updates at least every 8 hours |
| SEV3 | Minor degradation with a workaround, where customer-affecting | Within 72 hours | Daily updates until resolution |
The vendor chain, by legal consequence
Three tiers. Sub-processors receive customer content or personal data and appear in the sub-processor register with a 14-day objection window under the DPA and 30 days advance notice for material changes affecting critical or important functions. Operational vendors run our business but never receive customer content. Customer-connected integrations are onward transfers you initiate with your own account or API key. The full machine-readable chain, with per-vendor countries of provision, storage and processing and chain rank per RTS (EU) 2025/532, is served live at /subprocessors.csv.
Sub-processors (customer content or personal data)
| Vendor | Purpose | Provision / storage / processing | Supports CIF |
|---|---|---|---|
| Sentry | Error tracking | US / EU / EU | No |
| Cloudflare | CDN, security and object storage (R2) | US / EU / US | Yes |
| Unix-Solutions | Hosting | BE / BE / BE | Yes |
| Hetzner | Hosting and object storage | DE / DE / DE | Yes |
| Amazon Web Services, Inc. | Storage (S3, EU region) | US / IE / IE | Yes |
| Google LLC (Google Cloud) | Geolocation Testing + AI Testing | US / EU / EU/US | No |
| Stripe Inc. | Payment processing | US / US / US | No |
| Paddle.com Market Ltd | Payment processing (merchant of record) | GB / GB / GB | No |
| Bright Market, LLC (FastSpring) | Payment processing | US / US / US | No |
| Vonage America, LLC | SMS delivery (two-factor authentication and alerts) | US / US / US | No |
| ActiveCampaign, LLC (Postmark) | Transactional email delivery (Postmark) | US / US / US | No |
| Intercom | Customer support | US / US / US | No |
|
OpenAI, L.L.C.
Opt-in feature |
AI Testing | US / US / US | No |
|
Anthropic, PBC
Opt-in feature |
AI test failure analysis (AI Insights) | US / US / US | No |
Operational vendors (no customer content)
These vendors support our internal operations and are not sub-processors of customer content or customer personal data.
| Vendor | Purpose | Location |
|---|---|---|
| New Relic | Application performance monitoring | USA |
| PagerDuty | On-call alerting for our engineers | USA |
| Google reCAPTCHA | Bot protection on public forms | USA |
| MaxMind | IP geolocation and fraud signals | USA |
| OpenCage | Geocoding | Europe |
| ipinfo.io | IP address metadata | USA |
| Discourse | Community forum hosting | USA |
| AWS Marketplace | Marketplace billing channel | USA |
| Shopify | Merchandise storefront | USA |
| Wix | Partner app distribution channel | USA |
| HubSpot | Marketing site analytics | USA |
| Semrush | Partner app distribution channel | USA |
Customer-connected integrations
Destinations you connect and control with your own account or API key. Data flows to them only when you configure the integration; legally these are onward transfers you initiate, not sub-processing by TestingBot.
| Vendor | Purpose |
|---|---|
| Atlassian (Jira, Trello, Opsgenie) | Issue tracking and alerting integrations |
| GitHub | Issue tracking and CI integrations |
| Microsoft (Azure DevOps, Teams) | Issue tracking and notification integrations |
| Asana | Issue tracking integration |
| Slack | Notification integration |
| Discord | Notification integration |
| Google Firebase | App distribution integration |
| Bugsnag (SmartBear) | Error reporting integration (customer API key) |
Exit and substitutability
There is no proprietary test format to migrate away from. Tests written against TestingBot use standard Selenium WebDriver, Appium, Cypress and Playwright protocols and run unchanged against any compatible grid. Test artefacts (video, screenshots, logs) export at any time over the REST API, and storage is S3-compatible.
The DORA addendum grants a transition period of up to 90 days during which the service continues under the same terms, with data return and deletion per the DPA at the end of it.
Supporting documents
- pdf Data Processing Addendum (DPA)
- pdf Security Whitepaper
- pdf Technical & Organizational Measures (TOMs)
- xlsx TestingBot CAIQ
- pdf Datacenter ISO 27001 certificate
- pdf Bitsight Report
- pdf Service Level Description (SLA)
- pdf Register of Information Data Sheet
- pdf Exit Plan
- pdf Incident Notification Commitment
Document history
-
Initial publication of the DORA Art. 30 pack and Register of Information data sheet.
Questions from your vendor-risk or compliance team? Contact info@testingbot.com. See the full TestingBot Trust Center for security and compliance documentation.