Privacy Policy

Last updated: 2026-10-07

This policy explains what personal data Scopulars NETA collects, why, who we share it with, and what rights you have. It covers both the EU/UK General Data Protection Regulation (GDPR) and the Turkish Personal Data Protection Law No. 6698 (KVKK).

1. Data controller

The data controller — also the veri sorumlusu under KVKK for users in Türkiye — is Corvellum OÜ, a company registered in Tallinn, Estonia.

Operator

Corvellum OÜ

Legal form

Private limited company (osaühing / OÜ) registered in Estonia

Registry number

17608875

Address

Sepapaja tn 6, 15551 Tallinn, Harju Maakond, Estonia

Operating from

Tallinn, Estonia

Contact

privacy@scopulars.net

2. What we collect

2.1 Account and organization data

• Your email address and a cryptographic hash of your password (never the password itself).
• Your language preference and your organization’s name, slug and plan, and the seat-limit value stored with every organization record (adding members to an organization is not currently offered).
• The date and version of the legal terms you accepted at registration.
• If you enable two-factor authentication: your TOTP secret and recovery codes.
• Single sign-on (SSO) is not currently offered. If SSO was configured for your organization earlier, we hold that identity provider’s SAML configuration (entity ID, endpoints, signing certificate) until the organization is deleted.
• Team invitations are not currently offered. If invitations were sent from your organization earlier, we keep their records — the invitee’s email address, the role offered, who sent it, the invitation token, its status and its issue and expiry dates — until the organization is deleted, and they are deleted together with it.

2.2 Scan data — the targets you enter

• The targets you submit (IP addresses, subnets, domains, hostnames, API and GraphQL endpoints, container images, repositories and manifests).
• Scan results: open ports, detected services, product and version strings, operating system guesses, TLS/SSL details, identified CVEs with CVSS/EPSS/KEV context, findings, risk scores, compliance evaluations, discovered subdomains and assets, and any notes you add.
• Evidence of target ownership: the verification token and a hash of the proof you published (DNS TXT record or HTTP challenge file).
• Credentials you choose to store for authenticated scanning over SSH. Secret values are encrypted at rest. For cloud posture scanning (AWS/Azure/GCP) we store no credential at all: access is granted by a role or federated identity you control, and each scan obtains a short-lived token at the moment it runs. What we keep for cloud accounts is the non-secret pointers you enter — role ARNs, external IDs, tenant, project and subscription identifiers, and Workload Identity pool and provider names.
• Destinations you configure for notifications and webhooks, and their signing secrets.

Scan targets frequently identify infrastructure rather than people, but an IP address or a domain can constitute personal data. We treat this category accordingly.

2.3 Billing data

Your Stripe customer identifier, subscription status, the date you upgraded, and charge records (amount, currency, refund status). We never receive or store your card number — card data is handled by Stripe.

2.4 Security and audit logs

For security-relevant actions we record the acting user and organization, the action and affected resource, the response status, your IP address, your browser user-agent string, and the request path. Values that look like passwords, tokens, secrets or card numbers are filtered out of the recorded metadata before it is written.

2.5 Cookies and local storage

We set an HTTP-only access_token cookie, and a refresh-token cookie scoped to the token-refresh endpoint, so that you stay signed in. These are strictly necessary for authentication. Your browser also stores your language preference locally. We do not use advertising, analytics or tracking cookies, and there is no third-party analytics script in the application.

3. Why we use it, and on what legal basis

Under KVKK, the equivalent bases are Art. 5(2)(c) (necessary for the performance of a contract) and Art. 5(2)(f) (legitimate interests of the data controller).

4. Who we share data with

We do not sell personal data and we do not share it for advertising. We use the following processors and third-party services. All of them are outside Türkiye, so using Scopulars NETA necessarily involves international transfer of your data.

4.1 Infrastructure and platform

• Railway — hosts the application backend, the PostgreSQL database and the Redis queue, all in the EU (Amsterdam) region. This is where the live system runs and where your data is stored and processed from day to day. It is not the only place a copy exists: our daily backup is also kept outside Railway, as described in section 5.1. The backup is made by a scheduled job that runs inside Railway itself, so the database password it needs is never held anywhere else.
• Vercel — hosts and serves the web interface.
• GitHub — hosts our source code and runs our automated build and test jobs. It does not hold a copy of your data and is not involved in making or storing our backups. That changed on 4 October 2026: until then the backup job ran on GitHub-hosted machines, which meant GitHub both stored a copy of the database and held the credentials used to produce it. The job now runs inside Railway instead, and the database credential was removed from GitHub, so neither is true any more. We are naming the change rather than quietly dropping the paragraph that described it, because the earlier arrangement is what some of you will have read.
• Backblaze B2 — stores our daily backup, which is a full copy of the database. It is encrypted before it leaves Railway, with a public key whose private half Backblaze does not have, so Backblaze stores the file but cannot read what is in it. It goes into a bucket in the EU (Amsterdam) data region and is kept for 90 days before a rule on the bucket deletes it. For the first 30 days the file cannot be deleted at all, by Backblaze or by us — that is deliberate, so that losing control of an account cannot also destroy the backups. To be precise about the transfer: the file sits in the EU, but Backblaze is a US company, so this copy is stored in Europe and operated from outside it.
• Stripe — payment processing and the billing portal. Receives your email and payment details. Does not receive your scan data.
• Resend — delivers our transactional email. Receives your email address and the message content. Note that our scan-completion email names the scanned target, so a target you scanned can leave our systems in an email.
• Sentry — error and performance monitoring. Configured not to send personal data by default, and we filter authorization headers, password fields and card numbers from error reports. See the honest limitation in section 4.3.

4.2 Third parties that receive your scan targets

This is the disclosure that matters most for a security scanner. To enrich results, the Service sends target and finding data to independent third-party services. When this happens, the target you entered leaves our systems:

• VirusTotal, AbuseIPDB and Shodan — when threat-intelligence enrichment is used, the IP address or domain you are assessing is sent to these services and their reputation and exposure data is returned and cached. This feature is currently disabled, so no data is sent to these three services at present.
• Certificate Transparency logs (crt.sh) — during subdomain discovery, the root domain you are assessing is queried to enumerate subdomains.
• Anthropic — when AI analysis runs, findings from your scan are sent to the Claude API to generate summaries and remediation advice. Before sending, we pseudonymize the data: the target address is replaced with a placeholder and product, version and free-text description fields are masked. Technical facts such as CVE identifiers, ports, services and severity scores are sent as-is.
• OSV — for software composition and SBOM analysis, the package names and versions found in your dependency manifests are queried.
• NVD (NIST), FIRST.org (EPSS) and CISA (KEV) — queried for vulnerability, exploit-probability and known-exploited data. These receive product, version and CVE identifiers, not your account identity.

Each of these is an independent controller of the data it receives, under its own privacy policy. If you do not want a target disclosed to a third party, do not use the enrichment features that query them.

4.3 A limitation we want to state plainly

Our error-monitoring filter removes credentials, passwords and card numbers, but it does not specifically strip scan data. If an error occurs while processing a scan, it is possible for scan details such as a target address to appear in an error report sent to Sentry. We consider this a residual risk rather than an intended flow, and we prefer to disclose it rather than imply a guarantee we do not enforce in code.

5. Retention and deletion

We keep your account, organization, scan and finding data for as long as your account exists, so that your history remains available to you. We do not currently operate an automated deletion schedule that purges old scans or audit logs after a fixed period; when we introduce one, this section will state the periods. Password-reset tokens expire on their own. An invitation token can be used only while the invitation is pending and for at most 7 days after it was issued; the invitation records themselves are kept until the organization is deleted (section 2.1). Records we are required to keep for accounting or legal purposes are retained for the period the law requires.

5.1 Deleting your account is permanent

You can delete your account yourself, from Settings → Security → Delete account. This is a hard delete, not a hidden “deleted” flag: the rows are removed from the live database in a single transaction. It is irreversible — there is no recovery window, no grace period, and no “undo” we offer you afterwards. Because of that, deletion requires you to re-authenticate; see section 7 for what it asks you for and for the cases where it refuses.

One honest qualification about backups. We take a daily backup of the whole database so that we can recover from data loss, and we keep one copy of it, outside the platform the live system runs on: it is stored at Backblaze in the EU and kept for 90 days. It is encrypted before it leaves the job that creates it — only we hold the keys that open it, and the platform that stores it cannot read what is inside. Until 4 October 2026 there was a second copy, kept by GitHub for 7 days; that copy is gone because the backup job no longer runs on GitHub, which also means GitHub no longer holds a credential to our database. We think one copy away from the live platform, kept for 90 days and undeletable for the first 30, is the better arrangement — but it is one copy, not two, and we would rather say so than leave the older sentence standing. Section 4.1 sets out what that does and does not protect you from. The consequence for a deletion is the part that matters to you: it removes you from the live system immediately, but backups taken before it still contain your data until the last of them ages out, which takes up to 90 days. We do not use those backups to restore individual deleted accounts, and we would only ever restore one wholesale after a catastrophic failure — if we ever had to, we would re-apply the deletions that happened after the point we restored from. We state all of this because claiming your data is gone from every copy the moment you click the button would not be true.

5.2 What happens to your organization

This is the part most people do not expect, so we state it plainly. What happens depends on whether you are the only person in your organization:

• If you are the only member, your organization is deleted with you, and so is all of its data — scans, findings, assets, schedules, reports, connections and its audit log.
• If your organization has other members, the organization and its data survive, and the scans, findings, analyses, notes, monitoring schedules, scheduled reports, verified assets and connections you created, and the invitation records you sent (which then name that person as their sender), are reassigned to a surviving administrator of that organization (or, if it has no other administrator, to another remaining member) rather than deleted. Your own account record is destroyed either way. We do it this way because that content describes the organization’s infrastructure rather than you as an individual, and the remaining members are still our customers — otherwise any one member could erase the whole team’s scan history by deleting their own account.
• Two things do not survive, even when the organization does. Your scheduled scans are deleted rather than reassigned, so any recurring scan you set up stops running. And if the subscription paying for the organization was yours, cancelling it is part of deleting your account (see section 8 of the Terms), so the organization drops back to the Free plan and your colleagues lose paid features until someone else subscribes.

5.3 What survives a deletion, and why

• Pseudonymized erasure records. So that we can prove an erasure happened without keeping the person who was erased, we write an audit entry when the deletion is requested and another recording how it ended (a successful deletion therefore leaves two; an abandoned one also leaves a record of why). Each contains a one-way keyed hash of your user id, the organization id, a timestamp and the outcome, and the hash cannot be reversed back to your account. They contain no email address, no IP address and no user-agent — though we will not pretend the organization id and timestamp are meaningless to somebody who already knows who was in that organization.
• Security audit entries, with your personal fields cleared. The audit log of actions you took is not deleted — not in your own organization when it survives you, and not in any organization you previously belonged to. Instead the personal fields are cleared: the acting-user link, the IP address, the browser user-agent and the free-form metadata. What happened, on what, and when remains as that organization’s security record. We keep it because deleting it would turn account deletion into a way to erase the evidence of an abusive scan. To be precise rather than flattering: these rows are stripped of the fields that identify you directly, but some of them still carry the internal numeric id your account used to have, so we describe them as pseudonymized rather than anonymous.
• Stripe’s billing records. Deleting your Scopulars NETA account removes our local copy of your payment records, but it does not erase the billing and invoice records Stripe keeps as a payment processor under its own legal retention obligations. Stripe is named as a processor in section 4.1.

6. Security

• Passwords are stored only as hashes and are never recoverable by us.
• Credentials for authenticated scanning over SSH are encrypted at rest. For cloud providers there is nothing to encrypt: the columns that once held a cloud secret were removed from the database, so a long-lived cloud key cannot be stored even by mistake — not by us, not by a future feature, and not inside a restored backup.
• Traffic is served over HTTPS with strict transport security.
• Access to data is scoped to your organization, and every data query is filtered by organization membership.
• Two-factor authentication is available on your account and we recommend enabling it.

No system is perfectly secure. If you believe you have found a vulnerability in Scopulars NETA, please see the support page for how to report it.

7. Your rights

Under the GDPR you have the right to access your data, to have inaccurate data corrected, to erasure, to restriction of processing, to data portability, and to object to processing based on legitimate interests. Under KVKK Art. 11 you have equivalent rights, including the right to learn whether your data is processed, to request correction or deletion, and to object to a result produced solely by automated analysis.

How to exercise them. Two of these rights are built into the product; for everything else, email privacy@scopulars.net and we will respond within the period required by applicable law. You may also lodge a complaint with your local supervisory authority, or in Türkiye with the Personal Data Protection Authority (KVKK Kurumu).

7.1 Erasure — delete your account yourself

Settings → Security → Delete account. Because the deletion is permanent and cannot be undone, we ask you to prove it is really you: you must enter your current password, plus your authenticator code if you have two-factor authentication enabled, and type your account email address to confirm. Section 5 describes exactly what is deleted, what survives, and what happens to your organization.

Situations where the product cannot do it for you, in which case email privacy@scopulars.net or support@scopulars.net and we will carry out the erasure for you:

• You sign in with SSO only. Single sign-on is not currently offered; this applies only to an account that was set up through it earlier. Single sign-on accounts have no password for us to check, so the re-authentication step cannot succeed and self-service deletion is unavailable to you. This is a current limitation, not a refusal of your right to erasure.
• You are the last administrator of an organization that still has other members. The product refuses, because deleting you would leave the remaining members with an organization nobody can administer. Changing roles is not currently available in the product, so write to us at one of the addresses above and we will carry out the erasure for you.
• Your account belongs to more than one organization. The product refuses rather than guess which organization’s data you meant to destroy.
• You still have data in an organization you have left. If you were removed from an organization but content you created there remains, the deletion stops rather than quietly destroy another team’s data, and asks you to contact us. You will see a message saying nothing was deleted.

Whenever the product refuses, nothing is deleted — it never half-deletes an account. If a refusal is not one of the cases above, treat the message on screen as the accurate one and write to us.

7.2 Portability — export your findings

You can export findings yourself from the Findings page, as CSV or JSON. The export honours the filters you have applied and is not paginated, so the file is the whole filtered set rather than just the page on screen. Three honest limits:

• A single export contains at most 5,000 findings. If your filters match more than that, the file stops there. The web interface does not currently warn you when this happens, so narrow your filters — or ask us for a larger extract.
• This exports findings only. It is not a complete copy of everything we hold about you. For a full account data export, or for data in any other part of the Service, email privacy@scopulars.net.
• The file contains your organization’s findings, not only the ones you personally created — findings belong to the organization, and any member can export them. It is therefore a useful portability tool, but not a record of you as an individual.

8. Children

The Service is sold to businesses and is not intended for anyone under 18. We do not knowingly collect data of anyone under 18.

9. Changes

We may update this policy; the updated text is published here and the version identifier at the top of this page changes when we do. We do not currently push notifications about such changes, so please check this page from time to time.

10. Contact

Privacy questions and rights requests: privacy@scopulars.net. Anything else: support@scopulars.net.