Privacy Policy

1. Who is responsible for what

Threatera is a threat intelligence platform. The data it holds falls into two categories with two different legal answers, and telling them apart is the most important thing on this page.

Your account — we are the controller

The data needed to give you a login and keep the service secure — your email address, your password hash, your MFA secret, your role, and the audit record of what you did — is processed by us as controller within the meaning of Art. 4(7) GDPR. Sections 3, 4, 5, 10 and 11 describe it.

What you analyse — we are the processor

The files, URLs, indicators, rules and notes you submit are yours, as is anything that arrives in a reporting mailbox you connect (Section 7). We process them on your instructions, as a processor under Art. 28 GDPR, in order to run the analysis you asked for. We do not decide what you upload, we do not use it for our own purposes, we do not use it to train anything, and we do not sell or share it.

2. Controller

The controller for the account data described in this policy, and the processor for customer content, is:

Philipp Wudernitz
Stockerauer Straße 31a
2100 Korneuburg, Austria

Email: privacy@threatera.eu

We have not appointed a Data Protection Officer. The conditions in Art. 37(1) GDPR are not met: the platform's core activity is the analysis of technical artefacts, not the regular and systematic monitoring of people, and it does not process special categories of data on a large scale as a core activity. Data protection enquiries reach us at the address above.

3. Account data

To give you access to the platform we store:

Legal basis: Art. 6(1)(b) GDPR — processing necessary to perform the contract under which the platform is provided to you.

We do not ask for your name, telephone number, postal address, date of birth, or any payment details in the application. Accounts are created by invitation from an administrator in your organisation, not by public self-registration.

4. Sign-in, sessions and MFA

When you sign in successfully, the platform issues a signed session token (a JSON Web Token) which your browser stores in localStorage and sends with each request. It expires after 24 hours, after which you sign in again. Signing out deletes it from your browser.

The platform also stores your light/dark theme preference in localStorage. It sets no cookies of its own, and it runs no analytics, tracking, profiling, advertising or session-recording of any kind.

Multi-factor authentication is based on time-based one-time codes (TOTP). The QR code shown during enrolment is generated inside the platform; it is not fetched from an external service, so your MFA secret is never sent anywhere to be rendered.

Legal basis: Art. 6(1)(b) GDPR (performing the contract) and Art. 6(1)(f) GDPR (our legitimate interest in securing accounts). The browser storage described here is strictly necessary to provide a service you explicitly requested, and therefore requires no consent banner under § 165(3) TKG 2021 / Art. 5(3) ePrivacy Directive.

5. Invitations

An administrator can invite a colleague by email address. We store that address, a single-use invitation token, the intended role, and the expiry and acceptance times, so the invitation can be validated and so an administrator can see and revoke pending invitations.

The invitation email is sent through our mail provider, netcup GmbH (Emmy-Noether-Straße 10, 76131 Karlsruhe, Germany), acting as a processor on our behalf under an Art. 28 GDPR agreement. They necessarily see the recipient address and the content of the invitation. No other party is involved in delivering it.

Legal basis: Art. 6(1)(f) GDPR — the legitimate interest of your organisation in provisioning access for its staff.

6. Content you submit for analysis

The platform stores what you give it to work on:

• Uploaded files — the complete file, kept in object storage and addressed by its SHA-256 hash, together with its size, type and the filename it was uploaded under.
• Analysis results — antivirus and YARA matches, extracted strings, static structure, capability analysis, and any indicators (domains, IPs, URLs, email addresses, hashes) extracted from the file.
• The contents of archives you upload. When a zip, tar, 7z or rar is analysed, its members are stored as files in their own right so they can be examined and pivoted from, each recorded as having been extracted from the archive it came out of. They are subject to the same access control, retention and deletion as anything you upload directly — deleting your organisation removes them with everything else.
• Indicators you add, with your tags and notes.
• URLs you submit for sandboxed rendering, and the results described in Section 8.
• Detection rules (YARA, Sigma) and comments you write, together with the username that wrote them.

Uploaded files are kept in full and are not redacted, because an altered sample is not the sample. Please treat every upload as a disclosure: if a file contains personal data, that personal data enters the platform and stays in it until deleted. This applies with particular force to material that may contain special categories of data under Art. 9 GDPR — health records, identity documents, and similar — which is a realistic possibility for exfiltrated data recovered during an incident. Your organisation's own policy on handling such material governs whether it should be uploaded at all.

Legal basis: we act on your instructions as processor (see Section 1). Your organisation is responsible for the lawful basis for the content itself, ordinarily Art. 6(1)(f) GDPR read with Recital 49.

7. Reported email

Where your organisation switches it on, the platform connects to a mailbox you nominate — ordinarily the phishing@ address your staff already forward suspicious messages to — and analyses what arrives in it: the headers, the body, the links, and any attachments.

What is stored

• The complete message, as it was received, kept as a file in its own right like any upload. Nothing is stripped: an analyst reading a phishing report needs the headers exactly as they arrived.
• The header summary — sender address and display name, recipient, Reply-To, subject, date, and the Message-ID — held as searchable columns so a campaign can be traced across reports.
• The authentication result the receiving mail server recorded (SPF, DKIM, DMARC), read from the message and never recomputed. Re-checking would query the sending domain's infrastructure, which is both unreliable after the fact and audible to whoever operates it.
• The findings — why the message was judged as it was: a mismatched Reply-To, a display name claiming a brand the address does not, a link whose text and target disagree, a lookalike sender domain.
• Attachments, stored as files recorded as having been extracted from the message, so they can be examined and pivoted from exactly as an archive's members are. They are subject to the same access control, retention and deletion as anything uploaded directly.
• The sender's domain and the host of every link, recorded as indicators so they are searchable and can be matched against the platform's threat feeds.

What is deliberately not done

• Nothing is deleted from your mailbox. Messages are marked as read and left where they are. The mailbox is yours.
• No reply is ever sent — not to the reporter, and certainly not to the sender.
• Links are not opened automatically. A phishing message carries dozens, most of them tracking pixels that would confirm to the sender that the message was read. They are recorded as indicators; opening one is a deliberate act by an analyst, and it then happens as described in Section 8.
• Nothing is sent to a third party. The only outbound connection is to the mail server you nominated, to read your own mailbox (Section 12).

Credentials

The mailbox password is encrypted at rest and is never displayed again after it is entered. Each organisation's mailbox is separate: one installation-wide mailbox would put one customer's reported phishing, with their staff named in the forwarded thread, into another customer's platform.

If it was your message that was reported

If you wrote to someone whose organisation uses Threatera and they reported your message as suspicious — which happens to legitimate senders regularly — your message and your address are held in that organisation's instance. They are the controller of it, not us. Contact them; if you contact us we will pass the request on without undue delay, as Art. 28(3)(e) GDPR requires (Section 15).

Legal basis: we act on your instructions as processor (Section 1). For your organisation, this is ordinarily Art. 6(1)(f) GDPR read with Recital 49, which recognises network and information security as a legitimate interest. Because this data is not collected from the people it concerns, Art. 14 GDPR applies to your organisation as controller — including the question of whether an exemption under Art. 14(5) is available. It generally is for the sender of a phishing message, where notification would defeat the purpose of the processing; it is a weaker argument for third parties quoted in a forwarded thread. That assessment is yours to make and to document, and it is the reason this feature is not enabled for anyone by default.

8. The sandbox

When you submit a URL, the platform opens it in an isolated headless browser and records what happens. Two consequences are worth stating plainly.

The site you scan sees the platform, not you

The request comes from our infrastructure. The operator of the scanned site learns that the page was fetched, and sees our server's IP address and the sandbox browser's user agent — not yours, and not your organisation's address. That is deliberate. It does mean the site's operator may be able to infer that someone is looking at it.

What the scan stores

• a screenshot of the rendered page, the page title, and the final URL after redirects;
• the list of network requests the page made, which becomes the indicators the scan contacted;
• cookies and browser storage the page set — recorded by name, domain, flags and value length. The values are deliberately not stored, because a session cookie is a live credential and keeping it would put it in our database and in every exported report;
• whether the page tried to fingerprint the browser, and whether any form on it asks for a password or payment details and where it sends them.

A rendered page can of course contain personal data — a profile, a message, a document behind a link. Where it does, it is stored as part of the scan result and is governed by Section 1.

Files can also be detonated in an isolated environment. Detonation is confined to file types the platform can actually run; where it cannot, the action is disabled rather than silently doing nothing.

9. Verdicts and scoring

The platform assigns verdicts to files and reputation scores to indicators. These are assessments of technical artefacts — a binary, a domain, an address — not of people, and they are computed only from evidence this installation already holds.

Every score is broken down into the named signals that produced it, each shown with the evidence behind it, so an analyst can disagree with the number. An indicator about which nothing is known is reported as unknown, never as benign.

No automated decision-making producing legal effects on a person, or similarly significantly affecting a person, within the meaning of Art. 22 GDPR, takes place. The platform's output informs an analyst; it does not decide anything about anyone.

10. Audit log

Security-relevant actions — signing in, uploading, submitting a scan, inviting or removing a user, changing rules — are recorded with the username that performed them, the action, what was acted on, and the time. Administrators in your organisation can read this log.

This is a security control, and it is also what makes the platform accountable: without it, nobody could establish who did what. It records usernames and actions; it does not record your IP address.

Legal basis: Art. 6(1)(f) GDPR — the legitimate interest of your organisation and of ourselves in the integrity, traceability and security of a system that holds malware and incident data. Art. 32(1) GDPR requires appropriate security measures, of which this is one.

11. Technical and server data

Rate limiting. To defend the sign-in endpoint against password guessing, the platform counts recent requests per IP address in an in-memory store. The counter is keyed by IP address and expires automatically after the length of the counting window, currently 60 seconds. It is not written to the database and not used for any other purpose.

Server logs. The web server and the ingress record ordinary request data — timestamp, requested path, status code, IP address, user agent — for the operation, debugging and security of the service. These logs are retained for 7 days and then deleted — long enough to investigate an incident that has just occurred, short enough that no long-term record of individual access is built up.

Legal basis: Art. 6(1)(f) GDPR — our legitimate interest in a secure, functioning service. Art. 32 GDPR obliges us to protect it.

12. What leaves the platform

This is a closed list, and the platform is designed to keep it short.

Outbound connections are limited to these:

Geolocation and network-operator enrichment, capability analysis, YARA and Sigma matching — including rules imported from the packages above — passive DNS, threat-feed matching and reputation scoring all run locally, against databases stored on our own infrastructure and against your own observations. Looking an indicator up involves no outbound query at all.

The distinction that matters here is direction. Downloading a signature set, a GeoIP database or a public blocklist reveals nothing — it is the same file everyone else receives, and it is fetched on a schedule, not when you look something up. Reading your own mailbox reveals nothing to anyone but you. Asking a third party about an indicator is different, because the question itself discloses what you are investigating. Only two features in this platform do the latter — RDAP and active DNS resolution — and on this installation both are on. They are named here rather than left to be inferred, because this is the fact in this section a reader most needs before deciding whether our configuration suits them.

Of the two, active DNS is the one to weigh. RDAP asks a domain's registry, which is a neutral party and learns only that somebody is curious. Active DNS asks the domain's own authoritative nameserver, and for a command-and-control domain that server belongs to the adversary — so the lookup tells them you are looking. Both can be switched off; switching active DNS off costs you only freshness, because the platform falls back to addresses it observed during your own scans.

We do not transfer personal data to third countries outside the EU/EEA. We do not sell personal data, and we do not use customer content to train machine-learning models. Disclosure to a public authority would occur only where we are legally obliged, and we will inform you unless prohibited from doing so.

13. Hosting and location

The platform and all of its data stores — database, object storage, search index and queue — run on infrastructure operated by netcup GmbH, Emmy-Noether-Straße 10, 76131 Karlsruhe, Germany, acting as our processor under an Art. 28 GDPR agreement. The servers are located in Austria.

Being European is a design constraint of this product, not an incidental fact about where a server happens to sit. The controller, the hosting provider and the servers themselves are all within the EU, and the data is held in the same country as the supervisory authority responsible for it. No part of the service runs on a non-EU cloud provider, so it is not exposed to a foreign jurisdiction's access powers.

14. Retention and deletion

Account data is kept while your account exists. When an administrator deletes your account it is removed; audit entries recording actions already taken are retained, because a log that can be edited by deleting its subject is not a log.

Invitations expire automatically and can be revoked before they are accepted.

Reported email (Section 7) is retained on the same terms as anything else your organisation holds here, which is worth stating separately because it is the one store that fills with data about people who never chose to be in it. If you enable a mailbox, agree a deletion period for it in the data processing agreement. Deleting your organisation removes the messages, their attachments and the mailbox configuration with everything else.

Content submitted for analysis — samples, scans, indicators, results — is retained for as long as your organisation's retention period says, so that historical investigations remain reproducible and so that an indicator seen today can be matched against a sample seen last year. That is the point of a threat intelligence platform, and it is also a genuine tension with the principle of storage limitation in Art. 5(1)(e) GDPR. The period is yours to choose, which is where that tension is resolved.

Rate-limiting counters expire within a minute. Server logs are kept for 7 days (Section 11).

15. Your rights

In respect of the data for which we are the controller — your account and the audit record of your actions — you have the right to:

• access your personal data (Art. 15)
• rectification of inaccurate data (Art. 16)
• erasure (Art. 17)
• restriction of processing (Art. 18)
• data portability (Art. 20)
• object to processing based on legitimate interests (Art. 21)
• withdraw any consent you have given, with effect for the future

To exercise any of these, contact privacy@threatera.eu. Note that the right to erasure is not absolute: audit entries needed to establish the security and integrity of the system may be retained under Art. 17(3).

If your data is inside content someone uploaded or reported — because your details appeared in a document recovered during an incident, or because a message you sent was reported as suspicious (Section 7) — we are the processor, not the controller, and we cannot lawfully act on your request ourselves. Contact the organisation that operates the Threatera instance, which is the controller. If you contact us instead, we will forward your request to them without undue delay, as Art. 28(3)(e) GDPR requires of us.

You also have the right to lodge a complaint with a supervisory authority. In Austria this is the Data Protection Authority (Österreichische Datenschutzbehörde), dsb.gv.at.

16. Security

Measures under Art. 32 GDPR include:

• encrypted transport (TLS/HTTPS) for all access to the platform;
• passwords stored as Argon2 hashes and never in recoverable form;
• optional time-based multi-factor authentication, enforced at sign-in;
• API keys stored as hashes, revocable individually;
• mailbox credentials encrypted at rest and never displayed again after entry, since IMAP requires the original password back and it therefore cannot be hashed;
• role-based access control separating analyst and administrator rights;
• an audit log of security-relevant actions (Section 10);
• rate limiting on authentication to bound credential-guessing (Section 11);
• URL scanning restricted by an outbound request guard, so a submitted URL cannot be used to reach internal infrastructure;
• sample detonation confined to an isolated environment;
• refusal to start with insecure default secrets in a production deployment.

No system is perfectly secure. Where a personal data breach occurs we will notify the supervisory authority under Art. 33 GDPR and, where the breach is likely to result in a high risk to individuals, those individuals under Art. 34. Where we act as processor, we will notify the controller without undue delay under Art. 33(2).

If you believe you have found a security vulnerability in Threatera, please report it to security@threatera.eu.

17. Changes

We may update this policy to reflect changes to the platform or to legal requirements. Where a change materially affects how personal data is processed — in particular any addition to the list in Section 12 — we will inform account holders rather than relying on this page alone. The current version, with its date, always applies and is published here.