Records of processing

An engineering-maintained record of what the platform technically processes, drafted to support the controller’s Article 30 records of processing. Deployment-specific entries (controller identity, sub-processors, transfer mechanisms) are completed per deployment.

Roles

Processing activities

1. Threat-indicator processing (attacker infrastructure)

Personal data: attacker IP addresses and CIDR ranges (personal data under the Breyer judgment, C-582/14); e-mail-address indicators; domains, URLs, hashes, ASNs, TLS fingerprints, certificate thumbprints, wallet addresses and file names, which are generally not personal data but may incidentally identify a person. Purpose: detection, correlation, scoring and distribution of threat intelligence. Legal basis: legitimate interest: network and information security (Art. 6(1)(f), Recital 49). Retention: aged indicators are hard-deleted 365 days after last observation, enforced by the retention job. Recipients: the customer’s analysts; enforcement systems via feed export (redistributable evidence only); the collective exchange (sanitised observables only).

2. Sensor attack telemetry

Personal data: attacker source IP; credentials captured in brute-force attempts; payload and transcript content, which may incidentally contain personal data. Purpose: attack analysis, tooling and technique fingerprinting, behavioural classification. Legal basis: legitimate interest. Retention: events 90 days, sessions 90 days, captured artifacts 180 days, configurable per class; events and sightings are stored by calendar month and deleted a month at a time. Safeguards: payloads are quarantined, never executed, never rendered live; only sanitised technique, tool and indicator intelligence is shared externally.

3. Breach-exposure monitoring (customer assets)

Personal data: masked account and one-way hash only; breach metadata. Data subjects: the customer’s account holders. Legal basis: processor, on the customer’s instruction. Retention: 365 days, configurable.

4. Ransomware leak-site monitoring

Personal data: victim name as posted, usually an organisation. Legal basis: processor. Retention: 365 days, configurable.

5. Platform accounts and security logging

Personal data: analyst and administrator usernames and e-mails; audit-log actor and source IP; refresh tokens. Legal basis: contract and legitimate interest. Retention: audit logs 365 days, configurable; tokens until expiry; accounts until deletion.

6. Brand-protection website screenshots

Personal data: screenshots of suspected phishing or brand-abuse pages, which may incidentally display personal data. Purpose: phishing and brand-abuse detection and takedown evidence. Legal basis: legitimate interest. Retention: 90 days after capture; the feature is off by default. Safeguards: capture runs through an SSRF-guarded, optionally proxied browser; the hostile page is never rendered to analysts as a live link; screenshots are deployment-local and excluded from outbound sharing by construction.

7. Anonymous public feed

Personal data: attacker source IP addresses only, the same data as §1 and §2, re-published through an unauthenticated read path. Consumers: anonymous by design; no per-consumer identity is created, only an aggregate counter. Mitigations, fixed and non-configurable: off by default (the route answers 404 until enabled); a 48-hour delay; a 1,000-row cap; IP addresses only; redistributable first-party evidence only; TLP:RED and TLP:AMBER+STRICT can never appear; a per-IP rate limit and an hourly ETag.

8. Fraud-infrastructure indicators

Personal data: indicators of the seven fraud types: IBANs and phone numbers (directly or readily identifying: an account or a subscription belongs to a natural or legal person), SMS sender IDs, social-media handles, mobile app package IDs, and BICs and card BINs (which identify an institution or a card range, not a person). A card BIN is six to eight digits and nothing longer is accepted: no card number is ever stored, logged or exported. Data subjects: the account holders and subscribers behind mule accounts and fraud numbers (a mule is often a person recruited or deceived into lending an account); operators of fraudulent apps and social accounts; incidentally, a person whose number or account was spoofed or mis-reported. Purpose: fraud prevention and customer protection: recognising the accounts, numbers, senders, apps and profiles used in fraud against the customer’s own clients, and sharing them with the parties that can block them. Legal basis: legitimate interest (Art. 6(1)(f)): preventing fraud (Recital 47) and network and information security (Recital 49). Retention: the indicator lifecycle, as §1; no new retention class. Recipients: the customer’s analysts; downstream systems through the STIX/TAXII and MISP exports, as context for a fraud team and never marked for IDS in MISP; the collective exchange (sanitised observables only). The nginx, Suricata and RPZ blocklist formats refuse these types. Data-subject rights: the access and erasure tooling finds an IBAN or phone number however a request spells it.

9. Page-canary hits

Personal data: only for a render of the brand’s login page outside its legitimate hosts: the hostname it was rendered under, the referrer host, the client address truncated to a /24 (IPv4) or /64 (IPv6) and never kept whole, first and last seen, and a count. A render under a legitimate host stores nothing, and the beacon sets no cookie. Data subjects: phishing victims whose browsers loaded the login page through an attacker’s reverse proxy; the operator of the phishing host. Purpose: detecting reverse-proxy (“adversary-in-the-middle”) phishing against the customer’s clients, and turning the hostname into an indicator for takedown and blocking. Legal basis: legitimate interest (Art. 6(1)(f)): preventing fraud (Recital 47) and network and information security (Recital 49). Retention: the indicator lifecycle, as §1. Recipients: none. The host becomes a candidate domain indicator and reaches a brand’s feed or public page only once the page read or an analyst confirms it; a per-brand hourly cap limits how many hosts are filed. The referrer host and truncated prefix stay internal.

10. Takedown correspondence

Personal data: the sender address of each abuse-desk reply, its subject, the first 2,000 characters of its text (stored inert) and the message IDs that thread it to the notice (business contact data, though a mailbox may name an individual). Data subjects: registrar, hosting-provider and CERT staff who answer a takedown notice. Purpose: evidencing the takedown: who was asked, what they answered, and when the target went down. Legal basis: legitimate interest (Art. 6(1)(f)): fraud prevention and brand protection. Retention: with the case or takedown record it belongs to; no separate clock. Recipients: the abuse contact, who receives the notice and its evidence pack; the customer’s analysts. Replies are not exported or shared.

11. Public fraud alerts

Personal data: confirmed fraud-infrastructure values only (domains, phone numbers, SMS sender IDs and app packages) published anonymously, per brand, and only for a brand that has opted in. The page carries no screenshot, no analyst name and no hit count, never an IBAN, and records no per-reader data. Data subjects: the operators of confirmed fraudulent infrastructure; incidentally, a person whose number was mis-reported or spoofed. Purpose: warning the customer’s clients which sites, numbers, senders and apps are fraudulent. Legal basis: legitimate interest (Art. 6(1)(f)): preventing fraud (Recital 47). Retention: none additional: a live view over indicators retained under §1 and §8. Recipients: the public.

12. Stealer-log exposures

Personal data: customer or staff e-mail addresses whose credentials an infostealer captured against the customer’s e-banking host or mail domain, with the website they were captured against, stored masked and SHA-256 hashed, as §3. Only where plain-account export is switched on and a secrets provider is configured is the plain address also kept, encrypted at rest; otherwise it is never stored. No password is stored. Data subjects: the customer’s clients and staff. Purpose: forcing credential resets before account takeover. Legal basis: legitimate interest (Art. 6(1)(f)): preventing fraud (Recital 47) and network and information security (Recital 49); the customer is the controller of its own clients’ data. Retention: as §3. Recipients: the customer’s identity and fraud teams, through an administrator-only export that is audited every time.

13. Sharing-group deliveries and the payee-risk lookup

Personal data: fraud and attack indicators shared inside a vetted sharing group (chiefly IBANs and phone numbers, plus SMS sender IDs, app packages, domains, URLs and IP addresses) that a member labelled for the group, with their closed-vocabulary reasons (for example mule, scam payee, smishing), first and last seen, and an expiry; on the receiving side the same values, marked with the group, TLP:AMBER and not redistributable. The payee-risk lookup adds a sighting for each “known” answer, keyed by the calling API key, and a daily count per key in the audit log. The lookup returns no contributor identity, and IBAN and phone values never appear in logs, traces, metric labels or cache keys; a digest stands in for them. The group registry holds institutional data: member instance names and the name of the person who accepted the terms on a member’s behalf. Data subjects: account holders and phone subscribers named as mule or scam infrastructure (as §8); operators of other shared infrastructure; member representatives who accept the terms; lookup callers (a payment system’s machine credential). Purpose: fraud prevention and network and information security across member institutions: warning the next institution about a mule account or smishing sender one has already seen, and answering its payment pipeline before money moves. The terms bind every member to this purpose. Legal basis: legitimate interest (Art. 6(1)(f)): preventing fraud (Recital 47) and network and information security (Recital 49); for a financial entity, DORA Art. 45 expressly provides for such information-sharing arrangements, and each member notifies its competent authority of its participation (the platform renders that notice; it transmits nothing). Retention: each group observation carries an expiry, the contributor’s, otherwise the group’s default (90 days), after which it expires; on a member, the delivered indicator then ages through the ordinary lifecycle (§1). A retraction expires the member’s copy; nothing is kept beyond the lifecycle. Lookup sightings follow the sightings retention. Recipients: the group’s current members only, evaluated at every delivery under the terms; within a member, its own fraud and payment pipeline. Community, public and redistributable exports refuse group data, and it is never re-shared outside the group. A delivery to a member outside the EEA is an international transfer; see the DPA’s transfer clause. Data-subject rights: the group’s terms name the route: a person whose IBAN or number was shared contacts the member that contributed it or, for an anonymised group, the group’s operator, who knows the contributor. Erasure of a confirmed mule identifier may be lawfully refused under Art. 17(3) while it is needed for fraud prevention; a retraction removes it from further deliveries.

14. Fake-app listings, customer scam reports and social watch lists

Personal data: (a) app-store listings that name a brand: title, developer name (often a person’s or a small company’s), package ID, listing URL, icon and the hashes the store publishes; (b) customer scam reports: free text the customer typed (up to 4,000 characters), a URL, a phone number, an SMS sender ID, a social account, an IBAN the customer was asked to pay, a QR payload, the customer’s network prefix (/24 or /64) and, for the mailbox, a hash of the sender address, never a name, e-mail address or full IP address. A form report’s fields are held in the background-job store until the job expires, 24 hours after it succeeds; a forwarded scam keeps no raw message, and its attachments are hashed; (c) social watch observations: the public metadata of the customer’s own handles, and the last 20 public posts of a Telegram channel an analyst named (text up to 1,000 characters, links, posting time); (d) the resulting candidate indicators and, after corroboration or an analyst’s confirmation, confirmed ones (see §8). Data subjects: app developers and publishers (impersonators, and legitimate developers whose listings are kept for contrast); the customer’s clients who report a scam; the holders of the numbers, accounts and IBANs a report names (as §8, which is why a single report never confirms); authors of public posts in watched channels; the customer’s own social-media staff. Purpose: fraud prevention and brand protection: finding a fake app before it is installed, learning of a scam from the person it reached, and noticing the customer’s own channel being hijacked or a scam channel naming it. Legal basis: legitimate interest (Art. 6(1)(f)): fraud prevention (Recital 47) and network and information security (Recital 49); for a client’s own report, the client’s deliberate act of reporting (the form states what is kept and what is not). Retention: customer reports 90 days; social post observations 90 days; app listings for as long as the brand is monitored (a removed listing keeps its removal date as the takedown record); candidate indicators through the ordinary lifecycle (§1). Recipients: the customer’s analysts; the customer’s own defences through the per-brand feed and the public page, for confirmed items only (an IBAN never appears on the public page); staff phones receive only a listing’s package ID or hash as a detection-rule input. Never a third party: no takedown is sent without an analyst’s click. Data-subject rights: the form stores nothing that identifies the reporter, so an access request is answered from the receipt they were shown; a developer or account holder named as a candidate uses the ordinary indicator route; erasure of a confirmed fraud identifier may be lawfully refused under Art. 17(3) while needed for fraud prevention.

15. Public-code credential exposure

Personal data: the public GitHub login of a repository owner or alert resolver, where GitHub provides one, kept at most 90 days and then removed whatever the finding’s status; the location of a finding (repository, path, line), which may name a personal repository; one redacted excerpt of the matched line with the secret masked. The secret itself is stored only masked (at most six clear characters) and as a SHA-256 hash; the file is never stored. Data subjects: developers and contractors whose public repositories name the customer’s identifiers or hold a leaked credential; members of the customer’s own GitHub organisation whose secret-scanning alerts are mirrored. Purpose: finding the customer’s leaked credentials and identifiers in public code so they can be rotated; network and information security. Legal basis: legitimate interest (Art. 6(1)(f), Recital 49). The data read is public by the subject’s own act of publishing; the platform never contacts the person, never uses a found secret, and shows the login only to the customer’s analysts. Retention: findings 365 days from last sight; removed findings 180 days after removal; run records 90 days; the login 90 days from first sight. Recipients: the customer’s analysts; counts only in the management-body report and the evidence pack; never a feed, never an export of the login. Data-subject rights: a request naming a GitHub login is matched case-insensitively; access reports a count, erasure removes the login and keeps the finding’s evidential facts, both audited with the identifier hashed. Erasure of the finding itself may be refused under Art. 17(3) while the leak is unremediated.

16. Availability telemetry: DoS and DDoS detection

Personal data: attacker-side source prefixes: at most the twenty busiest source networks per router per minute, each aggregated to a /24 (IPv6 /48) with its share of packets, stored only inside an availability event’s evidence; target addresses only inside the controller’s own monitored prefixes, with every other destination folded into one bucket that carries a packet rate and no address. Everything else is aggregate counters and holds no personal data. No subscriber address, flow record or raw sample ever leaves the collector or is stored; the host agent reports no address of any kind. A prefix finer than /24 (/48), or more than twenty a minute, is refused at ingest. Data subjects: holders of source addresses inside an attacking /24 (/48), most of them spoofed or compromised hosts; where the controller is an ISP, its subscribers only in the sense that their traffic crosses the monitored routers. Purpose: the availability of the controller’s own services: detecting floods on the links and hosts it points the platform at, and saying what kind, how sure, and when it is over. Legal basis: legitimate interest (Art. 6(1)(f), Recital 49). ISP note: flow records are an ISP’s subscriber data. They are read and discarded in memory on the controller’s own collector at its own premises, which ships aggregates only; the platform never asks for a flow, a packet or a lookup by subscriber address. Retention: per-minute aggregates 90 days, deleted a calendar month at a time, so up to one month beyond; events with their prefix evidence 365 days. Ten-second samples are held in memory for 30 minutes and never persisted. Recipients: the customer’s users; the controller’s own alert channels and SIEM receive the event including its prefixes, flagged as likely spoofed unless corroborated. Nothing is minted into a feed, shared with a group or published. Data-subject rights: a /24 (/48) does not single out a person; a request naming an address is answered from the event evidence that contains its prefix, and erasure deletes those events.

Data-subject rights

Access and erasure are serviced by the platform’s compliance tooling, which exports or erases all records for an identifier across the tenant database. Erasure of attacker data may be lawfully refused (Art. 17(3)) where retention is necessary for network security or legal claims (a per-request controller decision).

International transfers and residency

Database-per-tenant enables data residency: a tenant’s data lives in one database that can be placed in a chosen region. Transfer mechanisms for any cross-border hosted deployment are completed per deployment by counsel.

Security measures (summary)

TLS in transit; encryption at rest; role-based access control with scoped API keys; multi-factor authentication; signed webhooks; audit logging of sensitive mutations; secrets kept out of source control; the exchange’s outbound sanitisation filter; signed release artefacts with a software bill of materials.

Controller: Trony Network · Privacy contact: [email protected] · Last updated 2026-11-07