Information Security Policy

Version 1.0 · effective 14 September 2026 · reviewed annually and after any significant incident. Owner: Huseyin Kurtoglu Wolfsohn (sole proprietor), Alte Schulgasse 9, 64850 Schaafheim, Germany.

This policy covers the Sellergoo service (sellergoo.com), the production infrastructure it runs on, its source code repository, and everyone with access to any of them. It is the framework our daily operations follow. Sellergoo is operated by a small team; the roles named below are functions, and one person may hold several.

Two things, in order of sensitivity. First, marketplace credentials — the OAuth tokens and API keys a seller entrusts to us so we can read their account. Second, the business data we read with them: orders, fees, refunds, settlements, inventory and listings, and — for orders a seller fulfils through a provider such as Amazon MCF — the delivery address that order carries. What we hold and why is set out in our Privacy Policy.

Data we hold is classified into three tiers, and the tier decides how it is protected, who may reach it and where it may go.

Secret — marketplace OAuth tokens and API keys, two-factor secrets, the keys that protect them. Individually encrypted at rest, decrypted only in memory for the duration of a single operation, never written to a log, never returned to a browser, and never shown again once stored. Reachable by no role through the interface.

Confidential — a seller's business data (orders, fees, refunds, settlements, inventory), their account details, and the delivery addresses carried by orders they fulfil through a provider. Held in that customer's own database, reachable by the customer and, for support, by the operator role, whose every read is recorded. Never combined across customers, never used to build benchmarks or models.

Internal — aggregate operational data with no personal content: service health, sync outcomes, error diagnostics. Available to the people who run the service.

A tier is never downgraded by copying: an export, a report or a backup carries the protection of the highest tier it contains, which is why backups are encrypted before they leave the server.

All traffic is served over TLS; the service is not reachable over plain HTTP. Marketplace credentials are encrypted at rest with AES-256-GCM envelope encryption before they are written to storage, through a single module that is the only place in the system able to decrypt them. Decrypted values exist only in memory for the duration of a sync run; they are never written to logs and never returned to a browser. Two-factor secrets are encrypted at rest with the same key material. Account passwords are not stored — only an argon2id hash. Session cookies, API keys, OAuth codes and invitation tokens are stored as SHA-256 hashes, never in plaintext.

In transit, connections are served over TLS 1.2 or above with modern cipher suites; earlier protocol versions are refused. At rest, every Secret-tier value is individually encrypted with AES-256-GCM, and every copy of customer data that leaves the server — the daily backups — is encrypted with AES-256-GCM before upload, with a key the storage provider does not hold. The live databases sit on a single-tenant server that is not reachable from the internet, in a directory readable only by the service account, and are protected by the access controls in section 3 rather than by disk-level encryption; moving them onto an encrypted volume is on the roadmap in section 10. The residual risk this leaves — storage media leaving the data centre — falls under our hosting provider's certified information security management system, which covers physical security, storage media handling and secure disposal (section 5).

Access to customer data is limited to the people who operate the service, and is granted on the principle of least privilege. Sign-in supports TOTP two-factor authentication with single-use recovery codes. Changing a password or an e-mail address requires the current password even inside an active session, and a password change signs out every other device.

People are granted access by role, not individually. Each role — owner, developer, operator, automation — carries the narrowest set of systems that role needs, and a person receives the lowest role that lets them do the work. Personal data is reachable only through the operator role. Automation never shares a person's credential and never holds a role wider than its single job. Access is removed the same day someone leaves.

Within a customer's workspace, access is role-based in the same way: an invited viewer cannot perform changing operations, and that boundary is enforced on the server, not in the interface.

Every administrative sign-in, failed attempt, lockout, read of customer data and change to a customer account is written with its source address to an audit trail that operators cannot edit — so an access nobody authorised is visible on the same page it would have been used to reach. These access logs are retained for the life of the installation; nothing prunes them.

Access rights are reviewed at least once a year, and on every joiner, mover and leaver. The review enumerates every login account, every authorised key, every privileged group and every operator account, and compares them against the roles above; findings are recorded with an owner and closed in the same way as any other work.

Each customer workspace has its own separate database file, not a shared table with a customer column. Isolation is therefore structural: a query cannot accidentally cross a workspace boundary, because the data is not in the same place. Demonstration data is held in its own workspace and is never mixed with live customer data.

The service runs on a dedicated server inside the European Union, behind a reverse proxy, in a container whose only persistent volume is the data directory. The host firewall exposes SSH, HTTP and HTTPS and nothing else. SSH accepts public keys only — password authentication is disabled — and repeated failed attempts are rate-limited and banned automatically. Configuration secrets live in a file readable only by the service account, are never committed to the repository and are never copied into a container image.

The hosting provider's information security management system is ISO/IEC 27001:2022 certified by TÜV Thüringen e.V. (a DAkkS-accredited certification body), with VPS hosting explicitly inside the certified scope — certificate 1512124260, valid to 26 June 2027. The certification is theirs, not ours: it covers the platform our server runs on, including physical security, storage media handling and secure disposal. We hold no certification of our own and do not claim one.

Every database is backed up daily using an online-consistent snapshot — never a file copy that could capture a partially written state. Each copy is verified by reading it back immediately after it is written, and a copy that does not verify fails the run rather than passing silently. The verified copies are compressed andencrypted before they leave the server, with a key the storage provider does not hold, then uploaded to object storage in a second location in the European Union — a backup that lives only on the machine it protects is not a backup. The storage bucket is jurisdiction-restricted, so those copies cannot leave the EU. A rolling window of daily copies is retained; backup storage is private and carries the same access restrictions as production.

Restores are exercised, not assumed. The restore path verifies every file against the checksum recorded when it was written and runs an integrity check on each database before it is put back into service, and the drill is performed after any change to the backup system and at least once a year.

All changes go through version control and code review before reaching production. Every change is checked automatically by type checking, linting, an automated test suite and a reconciliation gate that verifies financial figures to the cent against the underlying records. Dependencies are scanned for published vulnerability advisories on every change, on every pull request and weekly on a schedule; a critical advisory fails the build, and updates arrive as tracked pull requests rather than ad-hoc upgrades.

Writes back to a marketplace are deliberately constrained: our default posture is read-first, and an outbound action a customer has not connected a live channel for is queued rather than sent.

Vulnerability and threat management. Weaknesses reach us from four places, and each has a route in: automated dependency advisories, static analysis of our own source against the OWASP Top 10 and secret-detection rules, an automated dynamic scan against the live site, and reports from customers or security researchers. Every finding is triaged on severity and fixed to a deadline — critical within 7 days, high within 30, medium within 90, and lower findings in the normal backlog. A critical dependency advisory additionally fails the build, so it cannot reach production while unresolved. Where a fix is not available, we record the compensating control rather than let the finding lapse. Scan output is retained as a run artefact for every scheduled and change-triggered run, so the history is auditable rather than reconstructed. We run these scans ourselves and have not commissioned an independent third-party penetration test; we do not claim one.

We maintain a written incident-response procedure with defined severity levels, named responsibilities, containment actions for each type of compromise, evidence preservation, and a post-incident review. Where an incident involves personal data and is likely to result in a risk to the people concerned, we notify the competent supervisory authority within 72 hours of becoming aware (Art. 33 GDPR), and the people concerned directly where the risk to them is high (Art. 34). Affected customers and affected marketplace partners are notified without undue delay and within the window each partner agreement requires. A record of every incident is retained.

Roles. An Incident Lead declares an incident, decides its severity and owns every external communication — customers, partners and authorities. A Technical Responder investigates, contains, recovers and preserves evidence. A Customer Contact handles inbound reports and, once the Incident Lead has approved the wording, outbound notification. Only the Incident Lead speaks for Sellergoo: no responder notifies a customer, a partner or an authority on their own.

Reporting channels. Customers, researchers and partners report to [email protected], which reaches the Incident Lead. Internally, an incident can also be raised by our own alerting: failed synchronisations, a stale worker heartbeat, a failed backup and the administrative audit trail each surface on the operator dashboard, and failures also send mail. Every incident is recorded in a dated register — severity, timeline, systems and customers affected, whether personal data was involved, notifications sent with their timestamps, root cause and corrective actions. Entries are never rewritten after closure; a correction is appended.

Business impact and recovery objectives. We have assessed which assets carry the loss. In order: the key that protects stored marketplace credentials, the control database that maps a workspace to its data, each customer's own database, and the marketplace authorisations themselves. Availability ranks below integrity deliberately — Sellergoo reports on trade rather than carrying it, so an outage costs a seller visibility, not sales. Our recovery point objective is 24 hours (backups run daily, on-box and off-box) and our recovery time objective is 4 hours where infrastructure is available, or 24 hours where a host has to be rebuilt from nothing. The restore path depends on no part of the lost machine.

Drills. The plan is exercised at least once a year against a realistic scenario, and the restore is exercised after any change to the backup system and at least once a year. Each exercise is recorded with its date, what it covered and what it showed the plan got wrong, and those records are retained. The most recent restore drill was completed on 15 September 2026: every file in the latest backup was verified against its recorded checksum and passed an integrity check.

Customer data is processed and stored in the European Union: the application and its databases in Germany, the off-box backup copies in an EU jurisdiction-restricted storage bucket. We use a small number of sub-processors — hosting, a content delivery and TLS provider, a payment provider for subscription billing, and an e-mail delivery provider for transactional messages. Payment card details are handled entirely by the payment provider and never reach our systems. The current list is available on request and is set out in our Privacy Policy.

This policy is reviewed at least annually by its owner, and immediately after any significant incident or material change to the service. Planned improvements currently being worked on: continuous replication of the databases to reduce the recovery point below the nightly window, and moving the live databases onto an encrypted volume so that the storage layer protects them as well as the application layer already does. We do not hold an ISO 27001 or SOC 2 certification, and this document does not claim one.

If you believe you have found a security issue in Sellergoo, write to [email protected] with enough detail to reproduce it. We will acknowledge your report, keep you informed while we investigate, and will not pursue legal action against anyone who reports a genuine issue in good faith and does not access, alter or retain other people's data while doing so. Please give us a reasonable opportunity to fix the issue before disclosing it publicly.