Answer a customer's security questionnaire

This guide is for the partner developer or solution architect who has been handed a merchant's security questionnaire and a deadline. By the end you have an answer for every area the platform publishes, a citation for each, and a short list of questions that only revenexx can settle.

The answers already exist, but they sit on a dozen pages and in the contract terms. This guide puts them in the order a questionnaire asks, and it is as strict about what you must not claim as about what you can.

Before you start

• The questionnaire itself, so you can work through it area by area.
• The contract terms, at revenexx.com/terms. Several answers are contractual, and they come from the terms, not from these docs. The terms are in German, so quote the clause number, such as § 18 (4), together with your own translation. This guide was checked against version v12 of the terms (July 2026) (as of 2026-09). Check the version on the page before you cite it.
• A picture of what the project uses. A storefront on the edge, an App, an AI feature and an Integration Studio workflow each have a different answer to some questions. The glossary defines the terms used below: a tenant is one merchant's store on the platform, an App is installable business logic, Cockpit is the admin interface, and ID is the platform's sign-in service.

1. Map each area to a source

Work down the questionnaire and give each area one row. Confirm with us means the platform does not publish the answer. Docs pages are not contractual. Rows that cite a clause are.

2. Collect what the platform already handles

None of these is a task on your side, which is often the whole answer to a questionnaire line. In short: TLS 1.2 or 1.3 and automatic certificates on every endpoint, and a managed firewall and DDoS filtering only on the domains you point at the edge; the per-tenant rate limit applies to api.revenexx.com only. The full table, with what each row covers, lives in Go live with a project.

api.revenexx.com is answered by the origin and is not behind the firewall or the DDoS filtering. Its protection is authentication plus the rate limit. A questionnaire line that says "the WAF covers all traffic" would be wrong for the API, so answer it as two lines.

For tenant isolation, three facts are published and each is checkable:

• Every request names its tenant, and the header selects the tenant but does not grant access to it. The gateway checks the credential against the tenant first.
• An API key identifies one tenant, so it cannot be pointed at a second. A key sent with the wrong tenant is refused with 403.
• The data layer scopes the tables an App declares to the tenant, so an App does not write its own tenant filter.

3. State data residency and its exceptions

The answer has a default and three exceptions. Give all four. A residency line that says "Germany" and omits the exceptions is the one that comes back at the audit.

The default. The terms commit the platform to operating in data centres within the European Union (§ 18 (4)). The docs describe one origin, in Germany, where a tenant's data (products, orders, customers, uploaded files) is stored. There is no region to choose. Only the EU commitment is contractual. Do not present "Germany" as a contractual promise.

The exceptions:

1. The edge. Four points of presence sit in front of your storefront and asset domains, in Nuremberg, Ashburn, Hillsboro and Singapore. Traffic to those domains is terminated and inspected there, so it is processed at those locations while it passes through. The points of presence also hold cached copies of content that was requested through them, including uploaded files served on those domains, until the entry expires (an hour, with no purge). They are not the place your data is stored. Name the locations, because a reviewer will read a US city as a residency problem, and put the compatibility with § 18 (4) on the confirm-with-us list. The API is not fronted by them. See Edge network.
2. AI features. Some processing runs outside Germany but inside the EU. The terms commit revenexx to operating only AI models hosted in EU data centres, and to not sending customer data to models outside the EU (§ 18 (5)). Which AI features you can use today is on AI Studio.
3. The model behind your own tools. The commitment covers the models revenexx runs. It does not cover an AI assistant or a workflow node that you or the customer connect to a provider of your own choosing. What that provider does with the data is yours to document. See What an AI agent can change.

Backup location and support access from outside the EU are not published. Both are on the confirm-with-us list.

4. Separate training data and the AI Act from residency

These two are contractual and easy to get wrong, so give them their own answers.

Training on customer data. The terms allow revenexx to use irreversibly anonymised customer data to train and improve its models (§ 29). The customer can object at company level, at any time, and the objection takes effect within thirty days at the latest. It applies going forward: data already used in training cannot be withdrawn. It covers the whole company, not single users. The terms allow text form, such as an email, and also name a Datennutzung für KI-Training function in Cockpit. As of 2026-09 that setting is not available in Cockpit, so use the text-form objection. Tell the customer this before their reviewer finds it.

EU AI Act. The terms classify the standard configuration as a limited-risk AI system, not a high-risk one under Annex III, and name revenexx as provider and the customer as deployer (§ 28). Quote the clause when a questionnaire asks.

5. State which permissions are really enforced

This is the line most likely to be overstated, because a consent screen looks like a boundary.

An App declares the permissions it needs, and a merchant approves them when they install it. There are nine permission classes. As of 2026-09 the platform enforces three of them:

For the last two rows of the table (outbound and the five unproven classes), treat the consent screen as a statement of intent and not as a boundary. Do not quote it to a customer's security review as one. What an App may do inside the tenant is a weaker boundary than tenant isolation, and the answer must say so. The current state is tracked on Permissions.

A questionnaire will also ask about your own keys and users:

• API keys are scoped. A key carries capability keys or namespaces such as orders.*, plus a few platform scopes. These key scopes are a separate mechanism from the App permission classes above. Grant the narrowest set. Read-only means naming the read operations one by one. See API keys.
• A key is shown once, when it is created. Rotate by creating a new key, deploying it and revoking the old one. The docs state that a revoked key stops working within seconds.
• Keys do not expire on their own. Answer "rotation" as a process your team runs on a schedule, not as a platform feature.
• Multi-factor authentication is described as a tenant policy, set with your platform administrator, and not something an App switches on. See Multi-factor authentication. Which factors and which policy apply to the customer's tenant is a confirm-with-us item.

6. Describe the audit records and their limits

Say what exists, per domain, and say what does not. A reviewer who asks "who did what, and when" gets partial answers from several places, not one log.

Three limits belong in the answer:

• Reads are not audited. Nothing records that someone listed credentials or read an order. Every record above is a record of a change.
• No tenant-wide audit feed is documented (as of 2026-09) for API key use, sign-ins or administrative actions. Do not describe one. If the customer needs it, that is a confirm-with-us item, and the fallback is your own logging at the client, with the request ID you send on every call. See Debug a failed request.
• Log retention on the platform is not published (as of 2026-09) except for the Integration Studio default above. If the customer needs logs for a fixed period, keep them yourself. See Logs.

7. Send the rest to revenexx

Do not fill a gap with a guess. Send these questions to revenexx through your revenexx contact or support.revenexx.com before the questionnaire is due. Paste them as they are, with the tenant slug, the questionnaire and the deadline.

1. Is there an ISO/IEC 27001 certificate, a SOC 2 report, or another audit report, and can it be shared?
2. Are penetration tests done, how often, and can a summary be shared?
3. What is the platform-wide encryption at rest, and how are keys managed? Please send the technical and organisational measures annex, if it is not already retrievable in the platform.
4. Please send the data-processing agreement and the current sub-processor list, if they are not already retrievable in the platform.
5. Does terminating TLS and inspecting traffic at the points of presence in Ashburn, Hillsboro and Singapore fit the EU hosting commitment in § 18 (4)? Are authenticated or personalised responses cached there?
6. Where are backups stored, how often are they taken, and what are the recovery targets?
7. Is support access to customer data possible from outside the EU?
8. What is the process and the timeline for notifying an incident, and what is the security contact address?
9. What audit rights does the customer have, and on what terms?
10. Is there a tenant-wide audit record of API key use, sign-ins and administrative actions, and how long are audit records kept?
11. Which multi-factor policy and factors apply to this tenant?

Before you send the answers

• Every line of your answer cites a docs page or a contract clause.
• Nothing says certified, SOC 2, penetration-tested or encrypted at rest platform-wide unless revenexx has confirmed it in writing.
• Residency gives the EU commitment, the edge, and both AI exceptions.
• The permissions line names the three enforced classes and says the other six are intent.
• The audit line says what is not recorded.

Where to go next

• Go live with a project: the rest of what to settle before a launch.
• Choose where the logic goes: the placement decision that sets which permission classes your design relies on.
• Size a launch: the rate-limit and capacity facts a reviewer may ask about.
• What an AI agent can change: the fuller security-review section for AI use.
• Edge network: the points of presence and the single origin.
• Get help: where the confirm-with-us list goes.