Zaarks Console

# Zaarks — Privacy Notice This notice explains how XSAVY GmbH processes personal data **as controller** for the Zaarks website, Zaarks Account, Console, sales, subscriptions, billing, security and support. When a Zaarks customer records information about its own customers, staff, suppliers or other people inside its operational Instance, that customer ordinarily determines the purposes and is the controller. XSAVY then acts as processor under the Data Processing Agreement. Those people should contact the relevant Zaarks customer first. ## 1 · Controller and contact XSAVY GmbH Otto-Heilmann-Straße 18 a 82031 Grünwald, Germany Amtsgericht München, HRB 276852 Managing Director: Mohammad Yousuf Email: [email protected] No Data Protection Officer is presently designated. Privacy enquiries and data-subject requests may be sent to the address above. We reassess the appointment duty when organisation or processing changes. ## 2 · Data, purposes and legal bases | Data or activity | Purpose | Principal legal basis | |---|---|---| | Name, business email, account credential hash, MFA and recovery state | Create, authenticate and protect the Zaarks Account | Art. 6(1)(b) where the person is the contracting business; otherwise Art. 6(1)(f), secure administration of the customer's account | | Organisation, authority and membership records | Let authorised people represent and administer a business account | Art. 6(1)(b), Art. 6(1)(f) | | Legal name, address, country, tax ID and billing contacts | Contracting, invoices, tax determination and statutory records | Art. 6(1)(b), Art. 6(1)(c) | | Orders, subscriptions, invoices, payment status and provider references | Sell, deliver, renew, reconcile and account for Zaarks | Art. 6(1)(b), Art. 6(1)(c), Art. 6(1)(f) | | B2B representation and accepted document versions/hashes | Prove authority and contract content | Art. 6(1)(b), Art. 6(1)(f) | | Minimised network prefix, request metadata, login and security events | Prevent abuse, investigate incidents and establish legal claims | Art. 6(1)(f) | | Support, sales and service correspondence | Respond, perform the contract and preserve necessary business correspondence | Art. 6(1)(b), Art. 6(1)(f), where applicable Art. 6(1)(c) | | Website request data and strictly necessary cookies | Deliver the requested site, language and secure session | Art. 6(1)(f); § 25(2) TDDDG for necessary device access | Our legitimate interests are service and account security, fraud prevention, reliable business administration, product operation, and establishing or defending legal claims. We balance those interests against the affected person's rights and minimise what we collect. We ordinarily receive the data from you, your employer or organisation, another authorised account administrator, our payment provider, or technical use of the service. We do not buy consumer profiles. ## 3 · Payment processing Stripe processes payment-method and transaction information under its own legal responsibilities for payment, fraud prevention and regulatory duties. XSAVY receives identifiers, limited method details, status, amount and reconciliation data—not the full card number or verification value. ## 4 · Systems and separation Primary Zaarks infrastructure is configured in DigitalOcean's Frankfurt region. - Zaarks Account, catalogue, order, subscription and billing data is held in the separate **Console control plane**. - A **BMS Instance** uses its own logical operational database and runtime credential. - A **Work Apps Instance** uses a shared operational data plane with mandatory Instance scoping and isolation controls. These are different authorities. Paying for an Instance does not itself grant operational access, and operational Instance data is not joined to a person merely by matching an email address. ## 5 · Recipients and service providers We disclose personal data only where needed for the stated purpose: | Recipient category | Purpose | Typical location | |---|---|---| | DigitalOcean, LLC and its authorised sub-processors | Hosting, managed databases, object storage, backups and infrastructure logs | Primary region Frankfurt, Germany; limited support, security and group access may occur elsewhere subject to safeguards | | Stripe group entities and financial institutions | Payment, fraud prevention, reconciliation, refund and statutory financial duties | EEA and, subject to safeguards, other countries | | Amazon Web Services group entities (Amazon SES) | Transactional account, invitation, security and billing email | Primary region `eu-central-1`, Frankfurt | | Hostinger International Limited and mail infrastructure providers | Staff mailboxes and correspondence sent to us | Primary server region Germany; support/security access may occur elsewhere | | Tax advisers, auditors, legal advisers and authorities | Professional advice and statutory duties | As required for the engagement or law | We do not sell personal data or disclose it for another party's independent advertising. ## 6 · International transfers A provider's German hosting region does not necessarily prevent limited remote support, security or group access. Where Chapter V GDPR applies, the transfer uses an applicable adequacy decision, Standard Contractual Clauses or another lawful mechanism, with supplementary measures where the assessment requires them. Information about the relevant safeguard is available on request, subject to confidentiality and security restrictions. ## 7 · Retention We retain data for the shortest period reasonably needed for its purpose, then delete or anonymise it unless a legal hold or duty requires retention. - account and organisation-administration data: while the account or relevant relationship is active, followed by a limited closure and claims period; - contract and acceptance evidence: for the contract and applicable limitation periods; - commercial and tax records: according to § 147 AO and § 257 HGB—typically ten years for books and accounting records, eight years for booking vouchers, and six years for business correspondence, calculated under the applicable statutory rules; - payment references: for reconciliation, disputes, accounting and mandatory retention; - security and request logs: according to a documented operational period appropriate to security and claims, extended only for a relevant incident or legal hold; and - support correspondence: while needed for the request, contract, statutory business-record duty or legal claims. Data retained only for law or legal claims is access-restricted and not used for unrelated purposes. ## 8 · Cookies and local storage Zaarks uses strictly necessary storage for authentication, security, language, checkout continuity and routing. Session cookies are host-, path-, expiry-, `Secure`, `HttpOnly` and `SameSite` scoped as appropriate to their function. They are not advertising cookies. We do not claim consent for a purpose we do not operate. This section is the current cookie summary. If optional analytics, advertising or other non-essential device access is introduced, it must remain disabled until the required detailed notice and consent controls exist. ## 9 · Required data and automated decisions Contract, organisation, tax and payment information marked required is needed to create the account, verify business eligibility, contract, invoice or deliver the subscription. Without it, the relevant transaction cannot be completed. We do not make solely automated decisions about Zaarks Account users that produce legal or similarly significant effects within Article 22 GDPR. Automated security controls may delay or refuse a login or transaction; a person may contact us for review. ## 10 · Your rights Subject to the legal conditions, you may request access (Article 15), rectification (16), erasure (17), restriction (18), portability (20), or object to processing based on legitimate interests (21). Where processing relies on consent, you may withdraw it prospectively. You also have the right to complain to a supervisory authority. Contact [email protected]. We may need to verify identity and authority before disclosing account or organisation data. Our lead supervisory authority is generally the Bayerisches Landesamt für Datenschutzaufsicht (BayLDA), Promenade 18, 91522 Ansbach, Germany. ## 11 · Security We use organisational and technical safeguards proportionate to risk, including access control, credential hashing, purpose-separated identities, TLS, secret protection, audit evidence, Instance isolation, controlled migrations and tested recovery procedures. No internet service can promise absolute security. The DPA gives more detail for processor-side Customer Data. ## 12 · Changes We publish a new version when this notice materially changes and give additional notice where the change warrants it. Published versions are content-hashed so the notice applicable at a given time can be established.

Privacy notice

What this text is

The text, as published