Security and data processing

Last updated 14 October 2026. Everything on this page describes what is running today.

What is here

Three things, for three readers. Security practices, for anyone who wants to know how the service is built. A data processing addendum, for an organisation that has to paper its GDPR position before it can sign. A service level, for an organisation plan that needs one. If you only want to know what personal data we hold and why, that is in the privacy policy.

Transport

The site, the terminal and every API endpoint are served over HTTPS only, with HTTP redirected and HSTS set. Market requests are made server side, so the upstream data vendors see our address rather than yours. There are two exceptions. Crypto prices are read by your browser straight from the exchange's public market data API, which sees your address and the pair being looked at. And when you install the browser extension, stock price requests are made from your own machine and your own IP, which is the point of it, and it is stated in the extension listing and in the terminal.

Storage and encryption at rest

Account records, saved research and alert subscriptions live in a managed Redis store operated by Upstash. Disk encryption at rest is provided by that operator and by our hosting provider, Vercel, under their own certifications. Market and commodity data, and the jobs that fetch it, run on one server we administer, rented from Hetzner in the EU. It holds market data, not account records: it reads an account only to check what a request may see, and it writes no request log.

Your saved work is written under a key derived from your account email and is read back only for a request that has passed authentication for that account. The browser keeps a working copy in local storage, which Sign out and clear this device on the account page removes.

Accounts and sessions

• Passwords are stored as a PBKDF2-SHA256 derivation with a per-user random salt and 600,000 iterations. A password stored under an older, lower count is re-hashed at the next sign-in. The plaintext is never written anywhere.
• Password comparison, token comparison and one-time-code comparison are constant time.
• A session is an HMAC-signed token in a cookie marked HttpOnly, SameSite=Lax and, in production, Secure. It expires after seven days and can be revoked by signing out.
• Sign-in, sign-up, password reset, checkout and alert registration are all rate limited per account and per address.
• A wrong email is run through the same password derivation as a right one, so a timing difference does not tell an attacker which addresses exist.
• Sign-in, sign-up and password reset each need a signed single-use proof of work solved in your browser. It costs a person nothing and a script a full CPU pass per attempt. It runs entirely on our own endpoints, so no captcha vendor sees who is signing in.

Two-factor authentication and single sign-on

• TOTP. Any account can enrol an authenticator app. Once enrolled, a sign-in needs the code as well as the password, and the enrolment can be removed only from inside an authenticated session.
• SSO. Organisations can sign in through their own OpenID Connect provider. We read the issuer's discovery document, and access can be restricted to a list of email domains you set, so an account outside your domain cannot use the connection. Google and GitHub sign-in are also available for individual accounts.
• SSO does not remove the need for TOTP on accounts that keep a password.

Keys and secrets

• Provider credentials, signing keys and vendor tokens are held as deployment environment variables. They are not in the repository and are not sent to the browser.
• API keys for the data endpoints are bearer credentials scoped to one account. Treat one like a password: it can read everything your plan can read. Keys can be rotated and revoked from the account page, and a revoked key stops working immediately.
• Web push uses a VAPID key pair. The private half stays on the server; a browser subscription is stored against your account and is deleted when you turn notifications off.
• Where a deployment is configured with no credential for a feature, the feature reports itself unconfigured rather than falling back to something less safe.

Data processing addendum

This section is the addendum. Where you are a controller under the GDPR and we process personal data on your behalf, it applies to that processing and forms part of the terms of service. It is written to satisfy Article 28(3). If your legal team needs it as a signed document, write to data@surossystems.com and we will sign it.

Subject matter and scope

Subject matter: providing the Suros research terminal. Duration: for as long as the account is open. Nature and purpose: hosting, storing and displaying the account holder's own research data. Categories of data subject: your users. Categories of personal data: account email, authentication material, session and request logs, and whatever your users choose to save in their own research.

a. Processing on documented instructions

We process personal data only on your documented instructions, which are these terms, the settings you choose in the product, and anything else you tell us in writing. If we are required by Norwegian or EU law to process it otherwise, we will tell you before we do unless that law forbids it. We will tell you if an instruction appears to us to breach the GDPR.

b. Confidentiality

Everyone with access to personal data is bound by a confidentiality obligation that survives the end of their engagement. Access is granted on need, is limited to production support, and is removed when it is no longer needed.

c. Security measures

The measures are the ones described above on this page: encryption in transit, encryption at rest by the storage operator, derived and salted password storage, signed session cookies, optional TOTP, optional SSO with domain restriction, rate limiting, and secrets held outside the codebase. We keep them under review and may replace a measure with an equivalent or better one.

d. Subprocessors

You give general written authorisation for the subprocessors listed below. We impose the same data protection obligations on each of them, and we remain liable to you for their performance. We will give you at least 30 days notice before adding or replacing one, by email to the account contact and by updating the table on this page. If you object on reasonable data protection grounds within those 30 days, you may terminate the affected part of the service and we will refund the unused period.

e. Assistance with data subject rights

We help you meet a data subject request. Account data can be exported and deleted from the account page without asking us. Where a request needs us, we answer within 5 working days, which leaves you the rest of the statutory month.

f. Assistance with Articles 32 to 36

We help you with security, breach notification, data protection impact assessments and prior consultation, so far as the information is available to us. We notify you of a personal data breach affecting your data without undue delay and within 72 hours of becoming aware of it, with what we know, what we are doing and who to speak to.

g. Deletion or return

On the end of the service you choose: we return your data through the export in the product, or we delete it. Absent an instruction we delete it within 30 days, except where EU or Norwegian law requires us to keep a copy, in which case we keep only that copy and only for as long as it is required.

h. Audit

We make available the information needed to demonstrate compliance with Article 28, and we support an audit. In the first instance that is this page, the subprocessor list, and the certifications and reports our infrastructure providers publish, which we will pass on. An on-site audit is available once a year on 30 days notice where a supervisory authority requires one, at your cost, subject to confidentiality.

International transfers

Several subprocessors are US companies, so data can be processed in the US. Each transfer runs on the EU-US Data Privacy Framework or the European Commission's standard contractual clauses. The safeguard for each one is listed in the privacy policy.

Subprocessors

Market data vendors are not subprocessors of your personal data. We call them from our server and send only the ticker being looked at, apart from the two browser-side exceptions under Transport above. The ones whose licence asks for a credit are named on the data sources page.

Service level for organisation plans

Beta and retail plans carry no uptime commitment. An organisation plan carries the following, from the date the plan starts:

• Availability target: 99.5% of each calendar month, measured on successful responses to the terminal and the data endpoints, excluding scheduled maintenance and excluding an outage caused by an upstream market data vendor.
• Credits. Below 99.5% in a month, 10% of that month's fee. Below 99.0%, 25%. Below 95.0%, 50%. Claim within 30 days of the month end by writing to us with the dates; the credit is applied to the next invoice.
• Maintenance windows. Scheduled work runs Sundays between 02:00 and 05:00 UTC, announced at least 48 hours ahead on the status page. Work outside that window is unscheduled and counts against the target.
• Incident notice. We post an incident to the status page as soon as we confirm one, and we write to the account contact within 72 hours with what happened, what we did and what changes.
• Support. One business day first response for an organisation plan, on European hours.

The status page measures from the visitor's own browser at the moment of the check, so it is a live signal rather than the record used to calculate a credit. The record is our server-side measurement, and we will show it to you when you claim.

Reporting a vulnerability

Write to security@surossystems.com. Tell us what you found, how to reproduce it and what you think it lets someone do. We acknowledge within 2 working days and tell you what we intend to do within 10.

• Test only against your own account. Do not touch anyone else's data.
• No load testing, no denial of service, no social engineering, no physical access attempts.
• Give us 90 days before publishing, and we will credit you when we fix it if you want us to.
• We run no paid bounty. Report a serious finding in good faith and we will not pursue you for it.

What we do not yet have

This page says what we do rather than what we plan to do, so it has to say this too.

• No SOC 2 report and no ISO 27001 certification. Neither audit has been started. Our infrastructure providers hold their own certifications, which is not the same thing as us holding one, and we will not present theirs as ours.
• No penetration test report to share. No independent test has been commissioned yet.
• No 24/7 on-call rota. Incident response is European hours plus best effort outside them.
• No signed uptime commitment below the organisation plan. A beta seat carries none.
• No customer-managed encryption keys and no single-tenant deployment. Every account runs on shared infrastructure.

If one of these blocks a purchase, say so when you write to us. We would rather know than have you read an implication into a page that does not state one.

Contact

Security reports: security@surossystems.com. Data protection, the addendum and anything about personal data: data@surossystems.com.