Security and data protection

Gosoft Connect is used on websites that belong to other companies, which makes almost everything it touches somebody else's data. This page describes what we do about that, in enough detail to be checked rather than taken on trust.

Where we act on a customer's behalf we are a processor and they are the controller. Our processor privacy notice and our Data Processing Agreement set out that relationship in full. This page describes our measures as they are today, and they change as the service develops. The security commitments we are bound by are those in section 6.3 of the Data Processing Agreement; where this page and the agreement differ, the agreement prevails.

Data protection by design

No cookies. Gosoft Connect sets none, on any customer site. What the widget needs to function is held in the browser's local storage and session storage, scoped to that one site. It counts as expired 30 minutes (by default) after the visitor leaves and is removed on their next visit, or at once from the chat's privacy menu. Markers for a popup or greeting that shows once or was dismissed, and a recorded consent choice, can stay until the visitor clears their browser storage. The rules on device storage cover this storage as they cover cookies, so whether a site asks for consent is the customer's decision as controller. With the analytics consent setting on (the default for new workspaces), nothing is stored on the visitor's device for analytics until the visitor consents; until then, visits are counted under a same-day key (below).

Visitor IP addresses are not stored with visitor data. An IP address is used in memory to rate-limit abusive traffic and, on sites that wait for consent, to derive a same-day count key with a salt that is replaced and deleted every day. The address itself is never written to our database or to any application log. We keep no web access logs at all - the usual line-per-request record of who visited what is switched off, not merely rotated. Web-server error logs may still record a client address for request-level failures such as timeouts; those are operational logs kept 14 days. We do store the IP address of a logged-in portal user in three places: the audit log, the acceptance of our Terms of Service and Data Processing Agreement, and password-reset requests. Those are staff and customer personnel, never a website visitor.

No third-party trackers. We add no advertising pixels, no third-party analytics and no session replay. Knowledge-base search and its embeddings run on our own infrastructure. A customer can choose to send widget events to its own Google Analytics; that is off by default. A font the customer chooses may be loaded from the font provider's server, which then sees the visitor's IP address; new workspaces load no remote fonts.

Profiling. Visitor profiling, which derives attributes such as role, interests and intent from a conversation, is off and cannot be switched on in the portal. Lead summaries are on by default: when a visitor sends a form or contact details in the chat, an AI-written summary of the conversation goes to the customer's team with the lead. The customer can switch them off in the workspace settings.

Encryption

In transit - TLS on every web connection between visitors, customers, our servers and our sub-processors. Outbound e-mail, such as notifications and form answers sent by e-mail, uses TLS when the receiving mail server offers it, without verifying that server's certificate, and travels unencrypted when the server does not offer TLS. A connection to a service the customer connects goes to the address the customer gives: a webhook or a calendar address must use HTTPS. A website or product feed the customer adds to its knowledge base is read at the address the customer gives, which may be plain HTTP.

Backups - encrypted with public-key cryptography as soon as they are made: the unencrypted working copy exists only in a private temporary folder on the platform server and is deleted when the run ends. The server running the platform holds only the public half, so it can create backups and cannot read any of them back. The private half lives on a separate backup host that runs no public services. Someone who compromised our application server could read the live database, but not the backups already made.

Data in the live database is protected by the access controls and infrastructure security described below rather than by full-disk encryption. We would rather state that plainly than imply a control we do not operate.

Access control

Access is invite-only today: self-registration, which our Terms of Service and Data Processing Agreement already provide for, is built but switched off, and this page will change when it opens. Every request is scoped to an organisation and a workspace and re-checked on the server; workspace ownership is verified per call, so an administrator of one organisation cannot reach another's data by guessing identifiers. Passwords are hashed with argon2id. Administrative AI endpoints bind to loopback only and refuse any request that arrived through a public proxy.

Audit logging

Portal reads of customer personal data are recorded: who accessed what category of data, in which workspace, when, and from where. The log holds no message content. Covered today: opening a conversation, exporting a transcript, listing form submissions, exporting submissions, downloading a submitted file, opening the moderation queue, asking Kollega, deleting a workspace, restoring a workspace, deleting a workspace for good, and listing bookings.

Not covered, so you know the edges: aggregate dashboard previews; list views that show a preview of the latest message or a visitor's e-mail address; reports built from conversations, such as the knowledge-gap report and digests; and direct database access by an administrator with shell access to the server. The last is bounded by limiting production access to named administrators rather than by logging, and we would rather say so than imply a completeness we cannot deliver. The log is written best-effort, so a logging failure never blocks a request.

Customers can retrieve their own access trail at any time through the portal API: an admin of the organisation can call it. There is no portal page for it yet, so we also send it on request. Verifying who has looked at your data should not depend on us.

Resilience

Backups run nightly and are copied to a separate server in a different country; the database dump is checked when it is created. The platform server keeps its 14 most recent archives. The backup server deletes an archive once it is more than thirty days old, and only after a successful copy run, so while copying fails, older archives stay there until it works again. That backup host has no public IPv4 address, denies all inbound traffic at the provider firewall, and is reachable only over a private network.

Automated health checks run every three minutes and alert on service failure, certificate expiry, and on backups that stop arriving, go stale, or are written without encryption.

Sub-processors

All three are engaged under data processing agreements imposing data protection obligations that give at least the same level of protection as those we owe our customers, as far as they apply to their processing, and we remain liable to the customer for their performance. OpenAI and Google may transfer data to their affiliates and their own sub-processors outside the EEA, including in the United States. Their data processing terms with us require each such transfer to rely on the European Commission's Standard Contractual Clauses or on an adequacy decision of the Commission, such as the one for the EU-US Data Privacy Framework where the recipient is certified under it. Under OpenAI's API terms, data sent through the API is not used to train OpenAI's models, and OpenAI may keep it for up to 30 days to detect abuse. Section 7 of our Data Processing Agreement is the authoritative list.

Alerts to customer personnel travel through their browser's push service (Apple, Google, Microsoft or Mozilla), encrypted end to end, so those services cannot read the content.

We tell customers by e-mail at least thirty days before a new or replacement sub-processor starts processing their data, and a customer can object on reasonable grounds, as section 7 of the Data Processing Agreement sets out.

Data centre certification

Both data centres holding your data - Helsinki for the platform, Falkenstein for backups - are among the locations covered by Hetzner's ISO/IEC 27001:2022 certificate, valid to 26 September 2028. Hetzner also holds a BSI C5:2020 Type 2 attestation for its hosting products, including dedicated and cloud servers and storage; the published attestation does not name the locations it covers. Their technical and organisational measures were inspected on site by TÜV Rheinland i-sec, whose most recent report records no deviations. Hetzner publishes the measures themselves at hetzner.com/AV/TOM_en.pdf, which is the document to read if you want the detail. We hold our own Article 28 agreement with Hetzner and their audit report; both are marked confidential by Hetzner, so we share them under a non-disclosure agreement rather than publish them.

To be precise about what this covers: these are our hosting provider's certifications, covering their data centres and hosting services. Gosoft Oy is not itself ISO 27001 certified, and we do not claim to be. The measures described on this page are our own, and are stated so you can verify them rather than take a badge on trust.

Retention

Deletion in the first three rows is automated, not on request. The sweep runs every day at 03:00 in your workspace's own timezone and issues a real delete, not a hidden flag. Deleted data remains in the encrypted backups until they are rotated out (see Resilience). A separate hourly pass closes idle conversations and clears expired tokens.

Retention windows are defaults enforced in code. A customer can set each of the three windows in the first three rows from 1 to 365 days through the portal API, or ask us to set it; there is no portal page for it yet.

Rights of website visitors

Visitors can download or delete their own data directly from the chat widget's privacy menu, authenticated by a secret held in their own browser. Erasure removes the conversations, messages, form submissions, uploaded files, leads, any profile and analytics events linked to the identifier the browser holds, including the files on disk; this is tested end to end. It also clears the visitor's name or e-mail address from the title of a booking made through a form. It cannot reach an earlier visit kept under an identifier that has expired, copies already sent to the customer, for example by e-mail, reports already built from many conversations, or the copies OpenAI keeps to detect abuse.

Where a visitor has lost that secret, the request goes to the website operator as controller, and we act on its instruction.

Where we are

Gosoft Oy is a Finnish company, Business ID 3454099-6, registered in Helsinki. Our primary data storage is in the EU/EEA. Our agreements are governed by Finnish law.

Asking us questions

Security questionnaires, audit requests under Article 28(3)(h), and requests for our Article 30 record of processing all go to privacy@gosoft.fi. Report a security vulnerability to abuse@gosoft.fi, as our security.txt says. We would rather answer a specific question than send a generic pack.