Security and data protection
Two separate jobs live on this page. One is keeping your own team's access tight. The other is the data-protection paperwork a German company running a shop cannot avoid. Both are boring until an auditor or an incident arrives.
Multi-factor authentication
Because sign-in is single sign-on, one credential opens everything a person has access to. That credential should not be a password on its own.
Each person enrols their own factors under Settings › Profile › Security, section Multi-factor authentication. Four are available:
| Method | What it is | Worth it? |
|---|---|---|
| Passkey | Biometric or security-key sign-in on the device (WebAuthn / FIDO2). Add passkey, then name it | Best. Phishing-resistant and faster than typing a code |
| Authenticator app | Six-digit codes from Google Authenticator, 1Password, Aegis and the like. Enrol shows the QR code | Good. The right fallback if passkeys are awkward on your fleet |
| SMS one-time code | A six-digit code by text, Enable / Disable. Needs a confirmed phone number | Weakest of the four. Use it only where nothing else works |
| Email one-time code | A six-digit code by email, Enable / Disable. Needs a confirmed email address | Only as good as the mailbox it goes to |
Push for at least one passkey or authenticator app for everyone with access to the Cockpit. Enrolment takes under a minute. Passwords are changed on the same screen under Change password, and a new email address or phone number has to be confirmed with a code before a factor can use it.
Sessions, and the policy you do not have
Settings › Team › Sessions lists every active sign-in across your organisation, with the factors each session used and when it expires, and lets you Terminate Session on any of them. That is your session control.
The practical compensation is the routine: review the session list monthly, terminate anything unaccounted for, and suspend departing colleagues on the day; see Users, roles and permissions.
The activity log
Settings › Profile › Activity shows account activity in three columns: Event, Client / Origin / Location, and Time, with a search box above.
Be precise about what this is, because the gap catches people:
- It is your own account's activity, not a tenant-wide trail of what your colleagues did.
- It shows recent entries. There is no date filter and no documented retention period.
DSGVO: what is yours and what is ours
For the personal data in your shop, your customers' contacts, their addresses, their order history, you are the controller (Verantwortlicher). revenexx processes it on your instructions. That split decides who owes what.
Get the Auftragsverarbeitungsvertrag signed. An AVV (data processing agreement) with revenexx is not optional under Art. 28 and it is the first document anyone will ask for. If you cannot find yours, that is today's task.
Keep your Verzeichnis von Verarbeitungstätigkeiten current. Your record of processing activities has to describe what the shop does with personal data. Two things here feed it directly:
- Your list of installed apps, each with its Access register: which data it touches and which external hosts it may reach. That is the closest thing you have to a sub-processor and data-flow inventory, and it changes whenever somebody installs something. Review it when you review the record.
- Your integrations. Every system you sync customer data to is part of the processing you have to describe.
Auskunft and Löschung need a plan, not a button. There is no one-click "export everything about this person" and no self-service tenant data deletion. What exists:
| Request | What you have today |
|---|---|
| Art. 15 access | Pull the person's contact, organization and order records, and export from the relevant screens. There is no single subject-export |
| Art. 17 erasure, messaging | The Mail area can erase everything sent to an address, and the unsubscribe links issued for it. Irreversible, by design |
| Art. 17 erasure, commerce data | Not self-service. Raise it as a request, and note that orders you must keep for tax reasons are a legitimate reason to retain, not to delete |
Write down the process before somebody sends a request with a 30-day clock on it. Knowing in advance who pulls the data and who signs the reply is the whole of the work.
Where the data lives
The binding statement about where your tenant's data is hosted, which sub-processors are involved and how long data is retained is the one in your contract and AVV with revenexx. Read it there before you write a privacy notice, and expect no switch in the Cockpit that moves data between regions. There is none, and none is planned as a self-service setting for now.
Individual apps and integrations can move data beyond the core service: an app declares any external host it reaches in its Access register, and a workflow you build sends data wherever you point it. Those are your decisions and belong in your processing record.
Isolation between tenants is enforced by the database, not by application code. Every record carries your tenant identifier and every query is filtered against the identity in the session before an app sees a row. An app cannot read another company's data even if it tries.
What to check
Quarterly, in fifteen minutes: everyone with Cockpit access has a passkey or authenticator app; the session list holds nothing you cannot explain; the member list contains no one who has left; your installed-app list matches what your processing record describes.