Technical and organisational measures

Measures under Art. 32 GDPR implemented by LW IT Solutions Company Lukas Wójcik for Answely. This document is Annex 2 to the Data Processing Agreement and at the same time describes the measures for the data for which the operator is itself the controller.

1. Scope and principle

The measures apply to all parts of Answely: the website answely.com and the customer account, the answer service at api.answely.com, the script answely.js, the indexer, the machines running the language model and the embedding model, and backups and monitoring.

Operator: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, VAT ID PL7252266190.

Principle: What is stated here has been implemented and is evidenced in the code or the configuration. Where something is prepared but not yet in operation, or is deliberately absent, this is stated expressly rather than hinted at between the lines. The figures in this document are reconciled against code and configuration by an automated check on every change.

The measures describe the state with which Answely goes into operation: verified in the development environment and adopted in the configuration of production. Where development and production differ, this is stated.

2. Confidentiality

2.1 Physical access control

Answely runs on own hardware in Łódź, Poland. No data centre, cloud or hosting provider is involved in operations. Web, account app, answer service, databases and Redis run on our own server behind our own router; the language model – our own AI, self-hosted – runs on two own servers and the embedding model also on own machines, all in the same internal network and at the same location. The operator runs further services of its own on the same hardware (including MousePlayer and reactive.chat).

The servers are operated in-house in closed premises in Łódź. Only the owner personally has access. The room is locked with a key and under video surveillance; no other persons – including landlords or cleaning services – have access. The exact address of the location is deliberately not disclosed.

2.2 System access control

• Access to the account only with a personal user account and password. Passwords are stored only as a salted hash using PHP's standard method, never in plain text.
• After several failed attempts, sign-in from the same address is temporarily blocked (default: 8 failed attempts in 15 minutes, configurable in the administration area). A successful sign-in resets the counter of failed attempts. In addition, every sign-in attempt atomically reserves an attempt per account before the password is checked (default 8 in 15 minutes, including successful attempts, without reset) and per IP address (ten times that, at least 80); two-factor codes are limited to 10 attempts per account in 15 minutes. This limiting stores only HMAC keys, no email or IP address in plain text. Registrations have their own window per IP address with the same limits. If the storage for this limiting is unavailable, sign-in is refused (HTTP 503) rather than allowed without limit.
• The public forms (sign-in, registration, "Forgot password?", "Choose a new password", support, quick check) are additionally checked by our own formconfirmed form protection: proof of work in the browser, single-use check token, trap for programs, browser signals, matching against data-centre networks, check of the email domain, for support a spam pre-filter with a language model on our own AI computers in the EU, and cross-website campaign detection with irreversible fingerprints (30 days). Submissions rated "block" are rejected; for "flag" only after a second step (confirm button, more demanding task, the repeated check must result in "allow"). If formconfirmed cannot be reached or the response is unclear, the submission is rejected and can be repeated; there is no silent acceptance. The other limits continue to apply.
• "Forgot password?": at most 3 reset links per address and hour and 10 per day (pseudonymised counters, also apply if formconfirmed fails) and one receipt per submission, so that a repetition does not trigger a second link.
• Two-factor sign-in (TOTP) is available to every account. It is mandatory for the administration area; recovery codes are stored only as a hash. The requirement can only be switched off in the server configuration, not via the application.
• Session cookies are HttpOnly, Secure and SameSite=Lax; the session identifier is reissued on sign-in. Customers see their sessions in the settings and can end them.
• Every write action in the account carries a CSRF token. The only exception is logging out, which works via a plain link without a token.
• Server administration is carried out via SSH, only by the owner or on his behalf. There are no shared accounts. From outside, the server's SSH access permits login with a key only; login with a password is possible only from private networks such as our own local network (since 16.10.2026).
• The development environment is only reachable behind a preview protection; without access, it responds with "not authorised".
• Secrets (database, Redis, tokens, keys) are kept in configuration files with restricted permissions outside the publicly reachable area, never in the source code. Retrieval of these files via the web is rejected.

2.3 Data access control

• Workspaces have members with roles; what a member may see and change is checked by the server, not just by the interface. If an owner deletes their account, workspaces with further members pass preferably to the longest-standing admin, otherwise to the longest-standing member.
• Every query in the account is bound to the workspace of the requesting account; a third-party site cannot be managed even with a known key.
• The administration interface of the answer service is only reachable via the server's local loopback, never via the upstream web server. For synchronisation with reactive.chat, it can additionally be bound to an address in the encrypted internal network (WireGuard), where it only accepts connections from a fixed list of addresses. In every case, a token is required, which is compared in constant time; without a sufficiently long token, it remains switched off.
• Push tokens are stored by the operator only as a SHA-256 hash and checked in constant time; they are valid only for their site and only for addresses on hosts with verified ownership.
• The machines running the AI models receive jobs only via signed requests (HMAC-SHA256 with a secret of at least 32 characters, timestamp that may deviate by no more than five minutes from the server's clock). Unsigned or incorrectly signed requests are rejected before any job is handed out.
• The answer service and the indexer run under a dedicated system user without login capability (answely-dienst) and with hardened settings (no privilege escalation, private temp directory, read-only system, no access to home directories). Dedicated users are prepared for production – answely-dienst-live for the service and answely-web for the account app in its own PHP pool – but have not yet been set up. In the development environment the account app runs in the web server's shared PHP pool.
• For the production account app it is prepared that it may only read its own program tree, its working directory and its data folder (open_basedir); the files of other services on the same server, including their configuration, would then not be accessible to it. In the development environment this limit does not apply.
• Redis: Answely uses its own ACL user, which only sees keys with the prefix of its environment (in development additionally the prefix of the test suites) and may not execute dangerous commands (such as deleting everything or changing the configuration). The service does not receive the password of the default user.
• Databases: separate databases for account app and answer service with separate users that are only admitted locally on the server; Answely connects to the database and Redis only via the local loopback. The database server and Redis additionally listen on the server's address in the internal network because other services of the same operator use them; the server's firewall admits only one of the AI machines to the database there and nobody to Redis. The database administration user with rights to all databases is likewise admitted only locally on the server.

2.4 Separation control

• Each site has its own key, its own settings and its own index. Answers are generated only from the index of the site on which the question is asked; separation per tenant is evidenced by tests with a real database.
• The answer box only answers for hosts whose ownership the customer has verified (CORS per site). If verification fails permanently, the box switches itself off for that site.
• The candidate and the previous index of an index approval have internal identifiers derived from the site's key and are not publicly addressable sites.
• Development and production run in separate installations with separate databases, separate Redis prefixes and separate system users. Development works with its own demo and test data, not with customer data.
• The machines running the AI models also serve other services of the operator (including reactive.chat, Stats4U and MousePlayer). Answely's jobs are fetched by a separate worker with its own secret; Answely sends only text to the language models, although the image component of the model software is switched on.
• The files of the company logos are stored outside the program tree and any public directory.

3. Pseudonymisation and data minimisation

• No cookie, no identifier: The script answely.js sets no cookies, creates no visitor identifier and does not load fonts, images or scripts from third parties. It only sends the question, the language and the addresses of the current and the referring page, both without parameters and anchors; the server additionally strips parameters and anchors.
• "Allow answer cache" off by default: In the default setting for new websites, questions and answers are not stored ("Allow answer cache" off). All optional features are switched off for new sites.
• Consent mode: If data-consent="required" is in the embed code, the browser sends no request to Answely before the visitor has consented, not even for the box settings. If the customer switches the mode on only in the account, the box first loads its settings and only holds back the question.
• Truncated IP addresses: Counters, the web server's access log and the page statistics store IP addresses only in truncated form: IPv4 without the last octet, IPv6 to /48. In addition, the access log contains neither parameters nor browser nor referring page.
• Abuse protection without IP address: It works with a hash of the IP address and a daily changing random value. The hash lives for at most 2 minutes, the random value for at most 2 days; the IP address itself is not stored for this purpose.
• Form protection pseudonymous: formconfirmed does not store any IP address, only a hash of the truncated address range with a key that changes daily (at most 1 hour), and of the email address only the result for its domain (at most 7 days); message texts are checked in memory only. The password is never sent to formconfirmed.
• No content in logs: Question and answer do not appear in any log of the answer service, the indexer, the AI workers or the web server; only types, codes and figures are logged. The AI models run without logging of requests.
• Question analysis masked: If it is switched on, email addresses, telephone numbers, IBAN-like digit sequences, links and long numbers are made unrecognisable before storage; storage takes place without IP address, without identifier and with the calendar day instead of the time.
• Groups only: Question analysis only shows the customer groups of two or more questions.
• Protected areas (prepared): Access tokens are checked locally; their contents are neither stored nor passed to the language model.
• Proofs instead of identifiers: Success reports and A/B comparison work with random answer identifiers and signed proofs, not with visitor profiles.
• Local derivation of the country: The country in the page statistics is derived from a local database file; no IP address is sent to a geolocation service.

4. Integrity

4.1 Transmission control

• All public endpoints are only reachable via TLS; the website sends HSTS. Certificates are issued by Let's Encrypt and are renewed automatically.
• The machines running the AI models are never called by the server. A worker on these machines fetches jobs via TLS (long poll), every request signed with HMAC, and returns the result by the same route – for the language model in parts, so that the answer flows in the browser. The server and all AI machines are located in the same internal network at the same location.
• The answer service only starts if every configured AI endpoint is on an allowlist of servers in the EU. As a result, the AI runs exclusively on servers in the EU; an endpoint not on the list prevents start-up.
• Answely addresses the database and Redis only via the server's local loopback (on the network addresses of both, see section 2.3).
• Off-site copies are encrypted on our own server before transfer (section 5.1).

4.2 Input control

• Important operations in the customer account (sign-in, changes to settings, deletions) are recorded in the audit log with account, time and action.
• Consents to the legal texts are recorded with version, time, IP address and browser.
• Payment events from Stripe are only accepted with a valid signature and are processed exactly once per event.

4.3 Disclosure control and output protection

• The script sends exclusively to the operator's own infrastructure. In normal operation, no third party is contacted.
• Answers are first masked and then provided with evidence markers; links only with https and only to hosts of the website. User text is inserted into the page in the browser only as text, never as HTML.
• The customer's own CSS is sanitised; the AI labelling is protected against being hidden.
• The indexer only retrieves domains with confirmed proof of ownership, only public addresses – no private, internal, link-local or reserved networks, not even after a redirect –, only via GET, without cookies and credentials, with time and size limits and respecting robots.txt.
• The server retrieves live data only from at most two fixed public HTTPS endpoints on confirmed hosts, without credentials, parameters or visitor data.
• Text recognition for PDF files runs locally with limited resources, time and number of pages in a private temporary folder, which is deleted afterwards; no third-party text recognition is used.
• Uploaded company logos are checked and re-encoded before they are stored; the original file is not served.
• The website sends security headers against embedding in third-party pages, against MIME type confusion, for economical disclosure of the referrer address and against access to camera, microphone and location. The Content Security Policy restricts the base address, objects, form targets and embedding, but not the sources of scripts; this is a known gap.

5. Availability and resilience

5.1 Backup

• Every night, the status job backs up the databases of the account app and the answer service, checks the backup for completeness and cleans up old states. Our own backups on the server are deleted after 30 days.
• Every Sunday, a restore test loads the latest backup into a disposable database, compares it and deletes the test again.
• In addition, every night a copy of all databases of the server and of the entire web directory is moved off-site, i.e. including the index, question analysis, company logos and our own backups. The destination is non-public storage at Google Cloud Storage in the region europe-central2 (Warsaw).
• The off-site copy is encrypted on our own server before transfer (rclone crypt), including file and directory names. The keys are held only by the operator; Google only sees blocks without recognisable meaning.
• Off-site copies are retained as follows: daily copies 7 days, weekly copies 364 days.
• Before encryption, the nightly full copy (dumps of all databases on the server and a file copy of /var/www including configuration files) is created on a USB drive attached to the server at the same location. There it is stored unencrypted and deleted after at most 8 days.
• Deleted data therefore remains in these copies until they expire; no targeted deletion within a copy takes place. Copies serve only for restoration and are not analysed. What happens to data deleted in the meantime in the event of a restoration is governed by section 12.3 of the Data Processing Agreement.

What does not exist, expressly: The databases, Redis, our own backups and the full copy on the USB drive are stored unencrypted; the server's disk is not encrypted, and encryption at rest has not been set up. The disks of the AI machines are not encrypted either; however, no content is stored on them: the machines fetch jobs, process them in memory and send back the result without storing any of it locally. Our own backups are on the same disk as the databases; only the copy on the USB drive and the off-site copy protect against the failure of that disk. A restoration of the entire server from the off-site copy has not yet been tested. Target recovery time: no more than 24 hours. Because backups are made daily, data loss is normally no more than one day.

5.2 Resilience and circuit breakers

• Rate limiting: at most 60 requests per minute and IP address across all public endpoints of the answer service; above that, it responds with "too many requests".
• Admission: the service only accepts a limited number of simultaneous answers, in total and per site; above that, it rejects immediately instead of queuing requests.
• Circuit breaker: if the language model fails repeatedly, the service stops accepting requests to the model for a while. The box then disappears, and the normal search of the customer's website remains fully usable.
• Several AI machines: answers are generated by two machines; if one is busy or fails, the other takes over. Background work such as the embeddings during index runs and the nightly grouping runs on a further machine of our own. If both answering machines fail, there are no answers; the box disappears.
• AI jobs have time limits: if no worker fetches a job or a worker stops responding, the job ends with an error instead of hanging. Visitor questions take priority over indexer work.
• Quotas per site and month limit the load; the customer is warned at 80 and 100 per cent.
• The workers' connections run via a separate route bypassing the web server, with limits per address and in total, so that waiting requests do not occupy slots needed for visitors.

Limit, stated candidly: According to the latest load measurement, capacity is not sufficient for high peaks; above the limit, the service rejects requests instead of slowing down. Additional capacity at an AI provider in the EU is prepared but not in operation and would only be permissible subject to the conditions in section 8.3 of the Data Processing Agreement.

5.3 Monitoring

• A status job checks the interface, database, free storage space, TLS certificates, answer service, readiness of the AI models and answer time every five minutes, and only reports an outage after two consecutive failed measurements, so that a single restart does not wake anyone. Checks of the website and the indexer are switched on in production; in the development environment they are switched off.
• Alert channels: a signal without content via Telegram and an entry with component, error and duration in the urgent messages ("Urgent Logs") of the administration area, which remains open until the operator ticks it off.
• A pending deletion that has not been carried out after 12 hours writes an error to the operator's error log. No active alert (Telegram or entry in the Urgent Logs) follows from it.

Limit: Monitoring runs on the machine it monitors and cannot itself report that machine's total failure. A heartbeat to an external service is provided for in the code but not set up. Delivery of an alarm to a real recipient has not yet been tested for Answely. Whether the nightly off-site transfer has succeeded is checked automatically every day by the watchdog that the operator runs for this server; if a successful backup fails to materialise, it notifies the operator.

6. Procedure for regular review

• Every change to the code passes through automated test suites for the service, account app and script, including tests of separation per tenant, access rights, signatures, input handling in all forms, retention periods with the clock set forward, and failure paths.
• A dedicated test suite reconciles the figures and commitments in the legal texts against code and configuration – in both directions: a text may not state a time limit different from the code, and the mandatory texts must state every time limit. It also checks the commitment that the AI runs exclusively in the EU against the allowlist.
• An end-to-end measurement checks that, with "Allow answer cache" switched off, a marker in a question appears neither in databases nor in Redis, journals or logs.
• Dependencies are checked manually for known vulnerabilities, most recently on 09.10.2026 (npm and Composer audits without open findings); there is no automatic check on every change. The runtime environment is kept on supported versions.
• The measures in this document are reviewed when processing changes – in particular before any change to the AI provider, fallback endpoint, question analysis or push interface – and otherwise annually.

External penetration tests are currently not commissioned, and there are no security certifications. This is stated here expressly: a TOM document that is silent on this reads as though such tests existed.

7. Sub-processors

The operator engages sub-processors only on the basis of the general authorisation in the Data Processing Agreement, announces changes 30 days in advance and contractually binds each of them to the same obligations. The current list: Sub-processors.

No third party is involved in answering a question: the script sends exclusively to our own infrastructure, and the language model runs on own hardware. The encrypted off-site copy at Google makes Google a sub-processor, even though Google cannot read the content – encryption is a measure, not a change of role. The operator sends emails to customers, including the optional knowledge-gap report with groups of masked questions, via Namecheap Private Email (Namecheap, Inc., USA); the transfer is based on the EU standard contractual clauses in Namecheap's Data Processing Addendum.

8. Retention and deletion

Deletion runs automatically; it is not triggered manually. Every time limit is evidenced by a test with the clock set forward.

8.1 Answer box (on behalf)

• Questions and answers in the default setting: no storage.
• Answer cache (only if "Allow answer cache" is switched on): 24 hours; after a new index version an old entry is no longer used and expires with this period.
• Counters without content: 7 days.
• Abuse protection: hash 2 minutes.
• Web server access log: 7 days.
• Question analysis (only with the customer's opt-in): 90 days, checked hourly; immediately together with the site or at the push of a button.
• Test reports of the answer tests and technical approval reports: at most 30 days.
• Answer diagnostics: only in working memory, at most 15 minutes after completion.
• Index, index copies and settings of a site: until deletion of the site, then within 24 hours. A queue catches up on deletions that the service does not accept immediately and writes an error to the log after 12 hours. A reconciliation finds orphaned sites.

8.2 Customer account and website (controller)

• Page statistics: 60 days.
• Audit log: 365 days.
• Error log: 90 days.
• Outbox: 30 days.
• Sign-in attempts: 7 days.
• formconfirmed form protection: hash of the truncated address range at most 1 hour, check results 30 days, result for the email domain at most 7 days.
• Receipts for "Forgot password?": 7 days; state information of the form protection: 30 days.
• Account data: until deletion of the account, then immediately; invoices 5 years from the end of the calendar year in which they were created under Polish tax law, then deleted automatically; record of consent to the legal texts after deletion as soon as the consent is 4 years old, i.e. at most 4 years after deletion.
• Sessions: ended ones or ones no longer in use 30 days after they end or were last used.
• Support requests including AI drafts: 1095 days from the last reply.
• Own backups: 30 days.
• Off-site encrypted copies: daily copies 7 days, weekly copies 364 days.
• Unencrypted full copy on the USB drive at the server: at most 8 days.

9. Personal data breaches

The operator notifies the customer without undue delay, at the latest 48 hours after becoming aware of a breach affecting the customer's data. The notification contains the information the customer requires for its obligations under Art. 33 and 34 GDPR. Every breach is documented with the facts, its effects and the remedial action taken.

Reporting address for security incidents: support@answely.com

10. Status and version

Version 1.0, as of 18.10.2026 – first published version; version 1.1, as of 31.10.2026: formconfirmed form protection added (2.2, 3, 8.2); version 1.2, as of 04.11.2026: outage rule without silent acceptance (2.2); version 1.3, as of 04.11.2026: rate limit, receipts and state information (2.2, 8.2); version 1.4, as of 06.11.2026: second step for "flag" (2.2); version 1.5, as of 06.11.2026: campaign detection and language model (2.2). Next review: annually.

This English version is the binding version; translations are provided for information.

Version 1.5 – as of 06.11.2026