1. Who we are
ZeRaLD is a product and service operated by SW11 Software Ltd, a company registered in England and Wales under company number 16896573. References to SW11 Software, we, us or our in this notice mean SW11 Software Ltd.
Registered office: 71–75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom.
For personal data that we use to operate ZeRaLD itself — such as account, authentication, security, beta, legal-acceptance and service-administration data — SW11 Software Ltd is the controller.
2. Scope and our different data-protection roles
This notice applies to the ZeRaLD website and account platform, controlled Beta, ZeRaLD Community where enabled, Panel/server-management and deployment services, Backup/Backup Panel where enabled, Store/platform marketplace functions and AI Handoff functionality operated by SW11 Software. ZeRaLD Community is part of the ZeRaLD service and is covered by this same Privacy Notice rather than a separate Community privacy policy.
Community is part of the same ZeRaLD service. Its workload may run on separate first-party infrastructure for performance, resilience and workload distribution while central ZeRaLD account/session authority remains authoritative. A Community member uses a user-chosen public Community identity; their ordinary account name and email are not intended to be shown to other members by default.
For ordinary ZeRaLD account and service data, we decide why and how that data is processed and act as controller.
Some ZeRaLD features can process files or other content that you control. If a business customer uses ZeRaLD to process personal data for purposes decided by that customer, the customer will normally be the controller and SW11 Software may act as its processor or subprocessor for the relevant workflow. In that situation, the customer's instructions and applicable data-processing terms govern our processing of that customer content in addition to the technical safeguards described here.
3. Personal data we process
Depending on the features you use, we process the following categories of information:
Account and identity data: your name, email address, email-verification status, account type (personal/consumer or business/professional), organisation name and your role or authority where you provide business details.
Authentication and security data: password hashes, session identifiers, IP addresses, user agents, passkey credential identifiers/public keys and authenticator metadata, authenticator-app/TOTP configuration, hashed single-use recovery codes, registration-verification and login challenge/grant records, password-reset records, privileged-administration step-up evidence, security events and associated timestamps. Reusable secrets, recovery codes and authentication verifiers are not exposed through ordinary privacy export.
Beta and legal evidence: beta-access request details, intended use, request/review status, request IP, the version of the Terms and Privacy Notice presented to you, acceptance timestamps and related evidence.
Communications preferences: where product/general update mail is offered, ZeRaLD records the applicable communication preference, lawful-basis/consent evidence and unsubscribe/opt-out state. Security, maintenance and service/legal communications are treated separately from optional promotional/product-update mail.
Beta availability updates: if you ask to hear when a new Beta cohort has places available, we process your email address, confirmation status and notification/unsubscribe timestamps. The list is separate from a Beta application and does not reserve a place.
Staff authority data: where an account is authorised to act for SW11 Software Ltd within ZeRaLD, we process assigned staff roles, code-backed permissions and a limited audit trail of role/permission administration. Staff notification entitlements may be used to send operational Support alerts. This authority data is not customer-project content and does not itself grant access beyond the permissions enforced by the Platform.
Community data: when Community functionality is enabled and you choose to use it, we may process your Community profile and preferences, Space or channel memberships, posts, replies, reactions, shared links or files, project-group participation, direct or private messages, reports, appeals, moderation decisions, moderation evidence, safety and abuse-prevention signals, and the audit records needed to operate and secure those features. Public Community content is intended to be visible to the audience shown by the feature. Private messages are not public and are not intended to be casually browsable by staff; where private content is reported, access should be limited to the minimum context reasonably required for the safety case and separately logged where appropriate.
Community identity and data: Community uses your existing ZeRaLD account and session rather than creating a second password or account silo. The Community web application may read the central account, session and Community records required for the feature through restricted application-level database access. Community-specific content, reports, moderation records and messaging data may be stored in dedicated Community tables within the central ZeRaLD data environment. Running the web application on a separate server does not create a separate service provider or controller.
Support data: when you contact ZeRaLD Support we process the support reference, requester identity/contact details, case category and subject, customer-visible messages, attachments you choose to provide, case status/timestamps and support audit events. Staff-only notes may be recorded where needed to operate, secure or investigate the support service. Guest support uses a non-guessable access secret stored only as a one-way hash. Before a new guest conversation opens, ZeRaLD verifies control of the supplied email address using a short-lived code; short-lived hashed email access tokens may also be used to reopen that specific support case securely from a Support email. Ordinary Support reply emails may be delayed or suppressed when the customer is actively viewing the conversation so email acts as a fallback notification rather than duplicating live chat. When an eligible signed-in user chooses a contextual “Get help with this” action, ZeRaLD may attach a deliberately limited set of operational diagnostic fields such as a ZeRaLD record reference, state/stage, a bounded user-facing message, a deterministic failure category and Platform version. Raw server output, credentials, project source, project database contents and arbitrary project files are excluded. For linked technical support, ZeRaLD may also record the linked installation identifier, reported ZeRaLD version, administrator-assigned release channel, current supported release and the resulting support-status decision. If Support grants an update-support exception, the exception reason and optional expiry are recorded as support administration data. Curated knowledge articles, known-issue records and deterministic failure signatures are product-support content rather than customer project inspection. Support staff may also link a case to an internal ZeRaLD engineering Problem so repeated reports can be investigated as one product defect. Problem records are designed to contain ZeRaLD engineering information rather than customer project content; the case-to-Problem relationship is support-administration data. Saved replies are reusable staff drafting content and become part of a customer record only when a staff member explicitly sends a reply. Stage 5 support email uses the separately configured Support mailbox. Outbound delivery metadata, secure thread markers, inbound sender/message identifiers, duplicate/bounce outcomes and customer support feedback may be recorded to operate and secure the conversation. Email replies are accepted into a case only after case-thread and requester-address checks; a support reference alone is not sufficient. ZeRaLD Support is for the ZeRaLD service itself and does not require access to your project source code, application database, business logic or arbitrary project files.
Server and installation data: server labels, hostnames or IP addresses, operating-system/runtime information, public keys and fingerprints, ZeRaLD version/channel, pairing and authorisation records, installation status and diagnostic output, release-download IP/user-agent data and timestamps.
Customer server/project locality: ordinary central control-plane operation does not copy a customer application filesystem or application database to SW11 Software. Customer-controlled content is transferred only where the user deliberately invokes a transfer feature such as AI Handoff, Support attachment/diagnostic submission or Backup.
Backup data: where Backup is enabled, ZeRaLD processes pairing and destination metadata, encrypted backup payload/manifest state, retention/verification records and recovery/restore workflow evidence. Backup remains separately release-gated and this notice does not imply that it is available to every user.
AI Handoff data: installation/project identifiers, project name, shared path, purpose, file count/size, access and expiry metadata and the temporary project archive that you choose to make available through a handoff. For Store feasibility handoffs, ZeRaLD can also retain the structured assessment result returned by the AI (for example compatibility outcome, requirements and identified project capabilities). For licensed Store integrations, ZeRaLD can retain the acquisition/product linkage, the latest structured integration progress and final AI result, and the time at which Store licence entitlement was validated for a completed integration. Store acquisition data can include the product/version acquired, promotional credits used, acquisition time and permanent licence identifier/status. Project archives can contain whatever information you put in the selected project, including personal or confidential data.
Privacy and account-lifecycle data: privacy requests, processing restrictions, retention holds, privacy-action audit records, account-closure requests and limited closure evidence.
Store promotional-credit data: your Store Credit balance is derived from an append-only ledger of grants, deductions and reversals, including the amount, reason, timestamp and relevant Store reference where applicable. Store Credits are promotional access units only and have no cash redemption value.
Store Beta membership data: if you join the Store Beta, we record your membership status, join/end timestamps and the separate Store Beta Agreement acceptance linked to that membership.
Store feature-request data: if you request a Store feature, we process the requested capability, any optional description/example and any short project-context label you choose to provide. A request may later be linked to a released Store product so your Store account can show that the requested capability is available. Submitting a feature request does not inspect or copy project files.
Store Beta feedback: if you choose to provide feedback, we process the feedback category, optional rating, message, relevant product/acquisition and, where applicable, the integration-handoff reference needed to understand the feedback. Feedback is optional and should not contain project secrets unless they are genuinely necessary to explain an issue.
ZeRaLD Guided data: when you use Guided we process the session type, tutor, availability and booking times, booking status, timezone, readiness confirmations, optional project/Installation association, customer objective, Guided Hour ledger and package/purchase records, Stripe payment identifiers and status, meeting link, reminder state, and session notes that the customer or tutor chooses to share. We also record the commercial/early-service confirmation associated with a Guided purchase where required. Guided does not automatically give a tutor access to arbitrary files, databases, credentials or server contents merely because an Installation is associated with a booking.
Transactional email and operational data: email addresses, names and message content needed to send account, authentication, security, beta and service messages; application/queue failure information and ordinary server/application logs generated while operating the service.
4. Why we process personal data and our lawful bases
Providing and administering ZeRaLD. We process account identity, account classification, server/installation information, service requests, Community participation data where that feature is enabled, and necessary technical records to take steps at your request and perform our contract with you.
Community safety, moderation and abuse prevention. Where Community is enabled, we process reports, relevant reported context, moderation history where justified, moderation decisions, appeals, abuse signals and audit records to protect users and the integrity of the service, enforce our Terms and Community rules, investigate misuse, and meet applicable legal or regulatory obligations. Depending on the processing, we rely on performance of our contract, our legitimate interests in operating a safe and trustworthy service, and legal obligation where the law requires a particular action. Access to private or sensitive evidence is intended to be purpose-limited rather than available for general staff browsing.
Authentication, security and abuse prevention. We process authentication events, IP addresses, user agents, security events and technical identifiers because they are necessary to protect accounts, servers, software delivery and the integrity of ZeRaLD. We rely on our legitimate interests in securing the service, preventing misuse, investigating incidents and protecting users, alongside contract performance where the processing is necessary to provide the requested service.
Controlled beta administration. We use beta-request information to assess and administer access requested by prospective users and to operate the beta in a controlled way. This is based on steps taken at your request before service access and our legitimate interests in testing and managing the service.
Beta availability updates. We send Beta-place availability emails only after you confirm the email address through the opt-in message. We rely on your consent for these optional updates. You can withdraw that consent at any time through the unsubscribe link included in the emails.
Legal and contractual evidence. We retain relevant acceptance, authorisation, privacy-action, closure and security evidence where necessary for contract administration, compliance, dispute handling and the establishment, exercise or defence of legal claims.
Store administration. We process promotional Store Credit ledger records to provide Store access/reward units, maintain an auditable balance and prevent inconsistent or duplicate adjustments. Credits are not treated as money, purchased value or a withdrawable balance.
Store Beta administration. We process Store Beta membership and agreement-acceptance records to administer participation, establish which programme terms were accepted and preserve appropriate contractual evidence. Store Beta membership does not rewrite or replace your historical acceptance of the main ZeRaLD Terms.
Store product development and feedback. We process feature requests and optional Store Beta feedback to understand product demand, investigate Store/integration quality and improve ZeRaLD. We rely on our legitimate interests in product development and controlled beta testing, while keeping feedback optional and limited to the information you choose to submit.
ZeRaLD Guided delivery and purchases. We process Guided booking, entitlement, purchase and session-workspace information to provide tutoring requested by the customer, administer availability and paid Guided time, confirm payment, prevent duplicate entitlement, send operational session messages and preserve appropriate contractual/accounting evidence. Payment-card details are entered into Stripe-hosted Checkout rather than stored by ZeRaLD as card data.
Transactional communications. We use your account email to send messages necessary for registration, verification, authentication, password reset, account closure, beta administration, security and operation of the service. These are service communications rather than advertising.
Where we rely on legitimate interests, we use the information for a defined operational, security or evidential purpose and limit retention according to the nature of that purpose. We do not use this basis to override rights that apply to you under data-protection or consumer law.
5. Server connection and automated administration
When you ask ZeRaLD to pair with, install on or manage a server, we process the server and installation information needed to carry out that request and maintain the installation's authenticated relationship with your account.
The automated installation path can temporarily receive a VPS credential in order to perform the installation you requested. The current design does not store that credential in the permanent installation-attempt record: it is encrypted into short-lived application cache for the queued installation job. Pairing, access and installation-authorisation secrets that need only be verified are stored as hashes.
Installation and deployment diagnostics can contain hostnames, IP addresses, usernames and environment/service information. We therefore treat diagnostic output as potentially sensitive operational information and apply the retention periods in our retention section.
6. AI Handoff and customer-controlled project content
AI Handoff is optional and user-directed. You choose whether to create a handoff and which project context is included. ZeRaLD creates a temporary read-only project snapshot and access metadata for the handoff.
For the access and service metadata required to operate AI Handoff, SW11 Software acts as controller. Where the archive contains personal data for which you or your organisation determines the purpose, SW11 Software may process that content on your instructions as processor or subprocessor.
If you choose to provide a Handoff to an external AI provider or other recipient, that recipient is a separate service and may process the information under its own terms and privacy arrangements. You are responsible for ensuring that you are authorised to disclose the selected project material to that recipient.
To improve compatibility with AI web-reading infrastructure, the initial Handoff claim response may be eligible for short-lived intermediary retention for up to 90 seconds. That response contains the temporary Handoff session link. ZeRaLD asks you to approve this delivery method before a current Panel creates the Handoff, records the notice version and approval time with the Handoff record, and keeps the normal Handoff scope, expiry and revocation controls in place. The project/session resources themselves are not deliberately made generally public by this compatibility measure.
Expired or revoked Handoff archives are eligible for physical deletion. Handoff metadata is retained for the short period described below and is only removed after the archive is confirmed absent, so a failed file deletion does not silently orphan an unknown project archive.
7. Service providers and other recipients
We disclose personal data only where it is needed to operate the service, fulfil your instruction, protect the service, or comply with law.
netcup GmbH provides the VPS infrastructure on which the current main ZeRaLD application and primary database operate. The current primary ZeRaLD VPS is located in Germany.
Contabo provides the VPS infrastructure currently used to run the ZeRaLD Community web application workload and its provider-level backup layer. Central ZeRaLD account and Community database records remain within the ZeRaLD data environment described in this notice; the separate web-application host does not create a separate privacy policy or a different SW11 Software controller relationship.
UnlimitedWebHosting provides domain/DNS and transactional email services used by SW11 Software. Transactional email may also pass through delivery or filtering infrastructure used or disclosed by that provider.
Customer-selected AI or other third-party recipients receive project material only when a customer chooses to make a Handoff or other disclosure to that destination. A customer-selected destination is not automatically treated as an SW11 Software subprocessor merely because ZeRaLD facilitates the customer's instruction.
We may also disclose information where required by law, a court or competent authority, or where reasonably necessary to establish, exercise or defend legal claims or protect the rights and security of SW11 Software, our users or others.
8. Where data is processed and international transfers
SW11 Software Ltd operates ZeRaLD from the United Kingdom. The current primary ZeRaLD application and database are hosted on netcup infrastructure in Germany, within the European Economic Area (EEA). The ZeRaLD Community web application workload is hosted on Contabo infrastructure and may connect to the central ZeRaLD database using restricted application credentials. Domain/DNS and email services are provided through UnlimitedWebHosting in the United Kingdom.
Some provider delivery infrastructure, customer-selected services or subprocessors may process information in other countries. Where SW11 Software is responsible for a restricted transfer of personal data, we use an applicable lawful transfer mechanism and required safeguards. Where you independently direct project data to a third-party AI or other recipient, you are responsible for the lawfulness of that instruction to the extent you determine the destination and purpose.
We do not describe a supplier's registered-office country as proof that every downstream processing operation occurs only in that country.
9. How long we keep information
We keep personal data for no longer than reasonably necessary for the purpose for which it is processed, subject to legal/security holds and records that must remain available for contractual or legal claims. The principal automated ZeRaLD retention rules are:
AI Handoff: the project ZIP is deleted after expiry or revocation unless an active legal/security hold requires preservation. Handoff metadata is eligible for deletion 7 days after expiry once the ZIP is confirmed absent.
Login access challenges and grants: 1 day beyond expiry. Password-reset records: 1 day. Stale application sessions: 1 day after last activity.
Security events: 180 days. Release-download telemetry: 90 days.
Server installation attempts: successful attempts 30 days after completion; failed attempts 90 days after completion. Installation challenges: 1 day beyond expiry. Expired/revoked installation access tokens: 1 day. Expired installation authorisations: 30 days. Expired unclaimed pairings: 7 days. Pairings associated with closed accounts are cleaned after the defined 30-day post-closure period where eligible.
Beta requests: pending requests 90 days; declined requests 90 days after review; approved requests 365 days after review.
Communications preferences: where product/general update mail is offered, ZeRaLD records the applicable communication preference, lawful-basis/consent evidence and unsubscribe/opt-out state. Security, maintenance and service/legal communications are treated separately from optional promotional/product-update mail.
Beta availability updates: unconfirmed sign-up records are removed after 7 days. Confirmed subscriptions remain only while you stay subscribed. Unsubscribed records are removed after 30 days.
Failed queue jobs: 14 days. Aggregate retention-run audit records: 730 days.
Closed accounts: active access is revoked when closure completes. The operational account profile is anonymised after 30 days. Completed, cancelled or expired closure-workflow records are removed after 90 days. Limited closure evidence is retained for up to 2,190 days (approximately six years) from closure unless an active legal/security hold requires longer preservation.
Support cases: closed support cases, customer-visible messages, case audit records and associated private attachments are retained for 730 days after closure unless a documented legal, security, complaint or privacy-processing hold requires longer preservation. Open cases remain while support is being provided. When an authenticated account reaches the existing post-closure anonymisation point, the requester identity stored on its support cases is anonymised with the account. Support email receipt metadata and support feedback follow the same closed-case lifecycle. Staff-only notes are not exposed automatically through the customer support interface and are handled through the applicable privacy-rights review where required.
Privacy rights requests: open requests remain while they are being handled; completed, declined or withdrawn request records are retained for 730 days, unless a legal/security hold applies.
Legal acceptance and core contractual evidence: we retain the minimum evidence reasonably required to demonstrate the legal version accepted and relevant authorisation for the applicable contractual/claims period. These records are not treated as disposable session telemetry and are not automatically rewritten when a later legal version is published.
Community data: Community records are retained under the category-specific lifecycle approved for the Community feature before that category is exposed. Public identity/content, private messaging, reports/moderation evidence, account closure, safety evidence, appeals, legal/security holds and backup expiry are treated as distinct retention cases rather than being kept indefinitely merely because they form part of ZeRaLD.
Ordinary application logs and email-provider records: these follow the operational log/mailbox lifecycle and provider controls rather than the database rules above. We minimise them and do not intentionally retain them indefinitely. A record may be kept longer where a documented security, complaint, fraud, legal or regulatory hold applies.
10. Security and access controls
ZeRaLD uses measures designed for the risks of the service, including password hashing, passkey/WebAuthn and authenticator-app strong authentication, single-use recovery methods, session-bound access grants, separate privileged-administration step-up, hashed pairing/access/authorisation secrets, encrypted storage where a temporary credential must remain reversible for a queued task, scoped AI Handoff access, expiry and revocation controls, administrator access controls and retention holds. Community database access uses dedicated application credentials and the permissions required for Community functionality rather than database root/administrator credentials or unrestricted access to unrelated ZeRaLD data.
Security-event IP addresses are masked in ordinary administrator presentation and can only be temporarily revealed through a privileged administrative control. Privacy exports deliberately exclude password hashes, reset tokens, access-code verifiers, token hashes, encrypted Handoff session credentials and equivalent reusable security material.
No internet service can guarantee absolute security. If we become aware of a personal-data breach, we assess and handle it under applicable data-protection law, including notification to affected people or the regulator where required.
11. Sessions, cookies and analytics
ZeRaLD uses first-party browser storage that is necessary to provide and secure the service, including authenticated session, security and privacy-preference cookies. Necessary storage does not depend on analytics consent.
ZeRaLD records basic anonymous Website statistics such as canonical page views, normalised referrer/source and campaign information, and coarse browser, operating-system and device class. These basic page-hit records do not create a visitor identifier, do not use analytics continuity storage and are not used to recognise the same browser later. We do not retain full IP addresses or raw user-agent strings in the analytics dataset.
If you choose to help improve ZeRaLD, optional first-party analytics adds a pseudonymous continuity identifier so we can measure 30-minute visits, approximate unique browsers and campaign attribution across visits for up to 30 days. Raw analytics events and related attribution state are retained for up to 30 days; non-identifying aggregate statistics may be retained for up to 730 days. We do not use fingerprinting, third-party ad pixels, remarketing or person-by-person browsing profiles.
You can choose Just the basics, allow the optional continuity layer, or later change your choice from Privacy & analytics preferences. Withdrawing optional analytics removes the browser continuity identifier; basic anonymous page counting continues without recognising the browser.
12. Your data-protection rights
Depending on the circumstances and applicable law, you may have rights to ask us for access to your personal data, correct inaccurate or incomplete information, erase personal data, restrict processing, object to processing based on legitimate interests, and receive certain information you provided in a portable format.
These rights are not absolute. For example, we may need to retain limited information to comply with law, preserve security or contractual evidence, respond to a dispute, or establish, exercise or defend legal claims. We will explain the position where a request cannot be fulfilled in full.
Signed-in users can submit and track a privacy request from the Privacy area of their ZeRaLD account. We may ask for additional information where reasonably necessary to verify identity or understand the scope of a request. We do not charge a fee for an ordinary data-protection request, although applicable law permits a reasonable fee or refusal in limited circumstances such as manifestly unfounded or excessive requests.
We normally respond without undue delay and within one month after receiving a valid request. Where data-protection law permits more time because a request is complex or numerous, we will tell you within the initial period and explain the extension.
13. Account closure
User-requested account closure requires an authenticated account, current-password confirmation and a separate time-limited confirmation sent to the verified account email. Opening the email link alone does not close the account: the user must explicitly confirm the request.
SW11 Software may enforce account closure where permitted by the Terms & Conditions. An administrative closure requires an authorised senior member of SW11 Software to approve and perform the action, with the reason and action recorded for audit purposes. It does not require the account holder to approve the closure.
Closure revokes reusable account, installation and Handoff access. Eligible temporary information is deleted or later anonymised under the retention schedule, while justified legal/security evidence remains only for its applicable retention period.
14. Sensitive data and children
ZeRaLD does not ask for special-category personal data or criminal-offence data as part of ordinary account creation, beta access or server management. Customer-controlled project files, diagnostics or free-text fields could nevertheless contain sensitive information if you choose to provide it. Do not include sensitive personal data unless it is genuinely necessary and you are authorised to process and disclose it.
ZeRaLD's software-development, deployment and server-management service is not designed as a service directed at children. The current Community Beta position is adult-only (18+); eligibility is confirmed at Community entry/joining. If real use later indicates meaningful under-18 access, SW11 Software will reassess the applicable Children's Code and online-safety position before widening access.
15. Automated decision-making and profiling
The current ZeRaLD platform does not use personal data for automated decision-making that produces legal or similarly significant effects about individuals. Beta applications are reviewed by administrators. Automated authentication checks, security controls, rate limits, deployment health checks and retention rules are technical service controls rather than profiling decisions about an individual.
16. Changes to this notice
ZeRaLD gives legal documents explicit versions. When we materially change this Privacy Notice, we advance its version and preserve historical acceptance evidence rather than rewriting old records as if a user accepted a later document. Where a change requires fresh acknowledgement or consent, ZeRaLD will obtain it through an appropriate account or service flow.
17. Contact and complaints
SW11 Software Ltd is the contact point for ZeRaLD data-protection matters. Privacy correspondence can be sent to SW11 Software Ltd, 71–75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom. Signed-in users can also submit a privacy request or a distinct data-protection complaint directly through their ZeRaLD account. Complaints are acknowledged and investigated under SW11 Software's data-protection complaints procedure, with progress/outcome communication where appropriate.
If you have a concern about how we use your personal data, please raise it with SW11 Software so we can investigate. You also have the right to complain to the Information Commissioner's Office (ICO), the UK supervisory authority for data protection, or another competent supervisory authority where applicable to you.
