Privacy Policy

1. Introduction & Scope

This Privacy Policy explains how nsupp ("nsupp," "we," "us," or "our"), a service operated by Asindie, Inc., handles personal data in connection with the nsupp platform — an AI-native customer-support and management product that combines live customer engagement (chat widget, unified inbox, mailbox, knowledge base, campaigns, in-app calls) with e-commerce and marketplace support (seller Q&A, review replies, and normalized order and customer context across many commerce platforms).

This policy covers two distinct relationships. First, it describes the limited personal data we collect and control about the businesses and individuals who create an nsupp account (our customers, whom we refer to as "merchants"). Second, it describes — for transparency — how we process, strictly on our merchants' behalf, the personal data of their own end-customers that flows through connected commerce platforms and support channels.

nsupp is designed to be conformant with the General Data Protection Regulation (GDPR, EU/EEA), the Turkish Personal Data Protection Law (KVKK), the California Consumer Privacy Act as amended by the CPRA (CCPA/CPRA), the Virginia Consumer Data Protection Act (VCDPA), the Colorado Privacy Act (CPA), Canada's PIPEDA, Brazil's LGPD, and the Children's Online Privacy Protection Act (COPPA), and our security and AI controls are designed to be conformant with recognized frameworks including ISO/IEC 27001, 27017, 27018 and 27034, SOC 2, ISO/IEC 42001, and the EU AI Act. We do not claim to hold any certification or attestation under these frameworks; where we describe controls as "designed to be conformant," we mean the controls are built to those standards, not that they have been independently certified.

Pre-launch notice. nsupp is currently at a pre-launch, waitlist stage. During this period the only personal data we typically collect is the information you provide to join the waitlist and to communicate with us. Sections describing operational data flows (for example, connected-store data and end-customer profiles) apply once the corresponding features become available to you.

2. Who We Are — Controller vs. Processor

Asindie, Inc. is a company incorporated in Delaware, United States, with operational activity that also creates a nexus with Türkiye and the KVKK regime. Because our users and their end-customers may be located in multiple jurisdictions, we apply the strictest applicable standard in each area rather than the minimum.

2.1 Account data — we are the controller

For personal data relating to a merchant's own account — such as the name, email address, and authentication and billing details of the people who sign up for and administer nsupp — we act as the data controller. We decide why and how that data is processed, and this policy governs it directly.

2.2 Merchant and end-customer data — we are the processor

For personal data that belongs to a merchant's business and its end-customers — for example, order records, customer contact details, and support conversations pulled in from connected platforms — the merchant is the data controller and nsupp acts solely as the data processor. We process that data only on the merchant's documented instructions, only to provide the service, and never for our own independent purposes. These responsibilities are formalized in a Data Processing Agreement (DPA) between Asindie, Inc. and each merchant. If you are an end-customer of a business that uses nsupp and you wish to exercise your rights over your data, the merchant is your primary point of contact as the controller; we will assist them in responding.

3. Data We Collect

We practice data minimization at every layer: we pull only the fields a specific function requires, we derive rather than duplicate wherever possible, and we discard data that is only needed momentarily. The table below mirrors the canonical data map implemented in our code and served on our public privacy page.

3.1 Account and communications data (nsupp as controller)

• Registration and waitlist details — such as your name, work email, and any information you volunteer when joining the waitlist or contacting us.
• Authentication data — credentials and multi-factor authentication data, managed through our identity provider we operate; passwords are subject to a server-enforced policy and are never stored in plain text.
• Billing data — where paid plans apply, billing is handled through our payment processor; we do not store raw card numbers or raw payment transactions.

3.2 Connected-platform and end-customer data (nsupp as processor)

• Store API tokens and connection credentials — obtained via OAuth or manual entry when a merchant connects a platform. Persisted for the lifetime of the connection and encrypted at rest with AES-256-GCM.
• Order status and tracking information — read from a connected store to answer "where is my order?" style queries. This is zero-persist: it is relayed live to the operator or end-customer and not stored, with customer name and address stripped before relay.
• Order-ownership email (verification only) — when an end-customer's identity must be confirmed for a lookup, the order email is compared using a timing-safe comparison and then immediately discarded. It is zero-persist and is not logged.
• Customer profile — name, email, phone, address, order count, lifetime value, and recent orders, read from a connected store only when an operator opens that customer's card. This is persisted in an encrypted field (AES-256-GCM, profile_enc) with a 90-day time-to-live, after which it is automatically swept.
• Support conversations — messages, tickets, reviews, and marketplace Q&A that flow through connected channels, each tagged with an origin (chat, marketplace, email, or review) so all channels appear in one unified inbox.

3.3 How we minimize and key this data

• Lazy sync. Customer data is pulled only when an operator opens the relevant card. We do not perform bulk imports of a merchant's customer base.
• Derived, not duplicated. Aggregates such as lifetime value, average order value, segment, and sentiment are computed from order history that is already present; they are not separately fetched or independently stored as raw records.
• Pseudonymous keys. Persisted rows are keyed by an HMAC-SHA256 hash of the email address; the raw email exists only inside the encrypted blob, never as a lookup key.
• Platform-relayed limits. For a merchant's own store, we may process full customer detail. For third-party marketplaces, we process only what the platform itself relays to the seller — where a marketplace masks data, we cannot and do not attempt to unmask it.

4. How and Why We Use Data — Legal Bases

We use personal data only for clearly defined support and platform-operation purposes, and each use rests on a lawful basis under GDPR Article 6 (and the equivalent bases under KVKK and other applicable laws).

4.1 Purposes

• To provide the core service — routing conversations, displaying order and customer context, answering order-status queries, and enabling operators to reply across channels.
• To authenticate users, secure accounts, and maintain the integrity and availability of the platform.
• To provide AI-assisted drafting, translation, summarization, sentiment analysis, and triage that operators review before use (see Section 11).
• To administer billing for paid plans, where applicable.
• To respond to support, waitlist, and data-subject requests, and to comply with our legal obligations.

4.2 Legal bases (GDPR Art. 6)

• Contract (Art. 6(1)(b)). Processing of account data necessary to provide nsupp to the merchant who requested it.
• Legitimate interests (Art. 6(1)(f)). Securing the platform, preventing abuse and enumeration attacks, and improving reliability — balanced against the rights of data subjects.
• Legal obligation (Art. 6(1)(c)). Retaining records or responding to lawful requests where required.
• Consent (Art. 6(1)(a)). Where consent is the appropriate basis — for example, certain communications or optional cookies — we obtain it and you may withdraw it at any time.
• Processor role. For end-customer data, the merchant (as controller) establishes the lawful basis; nsupp processes strictly on their instructions under the DPA.

5. Data Minimization

Data minimization is a design principle in nsupp, not an afterthought. We do not fetch or store fields that a specific function does not require. Concretely:

• Order status and the order-ownership email are never persisted — they are used in the moment and discarded.
• Customer profiles are pulled only on demand (lazy sync) and expire automatically after 90 days.
• Aggregate insights are derived from data already present rather than collected separately.
• Persisted records are keyed by a one-way email hash so that raw identifiers are not used as indexes.
• OAuth scopes requested from connected platforms follow least-privilege, read-only minimums per platform.
• Personally identifiable information is not written to application logs; audit records store a target identity (for example, an email hash), not message content.

6. Sub-processors and Third Parties

nsupp is built own-infrastructure, which meaningfully reduces the number of third parties that ever touch personal data. Our AI, identity, email-delivery, database, messaging, and storage components run on our own infrastructure we operate.

6.1 operated on our own servers components (not third-party disclosures)

• AI / large language model — operated on our own servers Qwen3. Our language model runs on our own infrastructure. It is not a third-party service, and customer data is never sent to an external LLM provider (see Section 11).
• operated on our own servers identity, email delivery, database, messaging, and object storage. These supporting systems run under our control on our infrastructure.

6.2 Third-party sub-processors

• Stripe — payment processing, used only where a merchant is on a paid plan; disabled entirely when not configured.
• Cloudflare — content-delivery and edge network services.

6.3 Connected platforms as data sources

When a merchant connects a commerce or communications platform, that platform is a source of data the merchant instructs us to process — for example: Shopify, WooCommerce, ikas, BigCommerce, PrestaShop, eBay, Trendyol, Hepsiburada, N11, Pazarama, Çiçeksepeti, Kaufland, Allegro, Judge.me, Yotpo, AfterShip, and Microsoft 365 / Outlook. Data from these platforms is subject to both this policy and the platform's own terms.

6.4 Hosting

nsupp runs on infrastructure we operate located in Germany (Falkenstein), within the European Union. We maintain a current list of sub-processors and will provide reasonable notice of material changes to merchants under the DPA.

7. International Data Transfers

Personal data is stored on infrastructure we operate located in Germany (Falkenstein), within the European Union, so data at rest remains within the EEA. Because Asindie, Inc. is incorporated in the United States and operates with a nexus to Türkiye and other regions, personal data may nonetheless be transferred across borders — principally where our United States entity accesses EEA-stored data to operate and support the service. Where we transfer personal data out of the EEA or the United Kingdom, we rely on appropriate safeguards, including the European Commission's Standard Contractual Clauses (SCCs) and, where applicable, the UK International Data Transfer Addendum. For transfers subject to KVKK, we rely on the transfer mechanisms permitted under Turkish law, including explicit consent or the applicable adequacy or commitment mechanisms as required. In all cases we apply the strictest applicable standard where more than one regime governs the same transfer, and we encrypt personal data in transit and at rest regardless of destination.

8. Data Retention

We keep personal data only as long as needed for the purpose it was collected, then delete or scrub it. Our implemented retention rules are:

• Commerce PII (customer profiles): 90 days. Encrypted customer-profile records expire and are automatically swept 90 days after they are cached.
• AI-call metadata: 365 days. We retain metadata about AI calls (not their content) for up to one year; AI prompt and response content is never logged.
• DSAR ledger: subject fields scrubbed 180 days after fulfillment. After a data-subject request is fulfilled, the subject-identifying fields in our request ledger are scrubbed within 180 days.
• Operational logs: at least 12 months. Security and access logs are retained for a minimum of twelve months; access-audit entries store an email hash rather than the raw address, and audit records capture the target identity, not message content.
• Order status and ownership email: not retained at all (zero-persist).
• Finance data: never logged, and raw transactions are not stored.

When a connection is removed, an app is uninstalled, a platform-mandated redaction is received, or a workspace is deleted, our erasure process removes the associated data as described in Sections 10 and 2.

9. Security

Our security controls are designed to be conformant with SOC 2, ISO/IEC 27001, 27017, 27018, and 27034, and the Amazon Data Protection Policy where applicable. We do not claim certification under any of these; the following controls are implemented in the product.

9.1 Encryption

• Secrets and sensitive profiles are encrypted at rest with AES-256-GCM at the field level (for example profile_enc and credentials_enc), so that even backups remain encrypted.
• Secrets are masked in data-transfer objects on a deny-by-default basis for unrecognized connectors, and are never written to logs.
• Data in transit is protected with TLS 1.2 or higher. Encryption keys are managed separately; key rotation invalidates existing credentials and requires reconnection.

9.2 Tenant isolation and access control

• A central authorization guard enforces tenant isolation on every data path; requests for resources a user does not own return a "not found" response that does not disclose whether the resource exists, mitigating IDOR-style attacks.
• Access is scoped per workspace at the repository layer, and vector retrieval fails closed.
• Role-based access control provides distinct roles on a deny-by-default basis, with least-privilege OAuth scopes requested from connected platforms.

9.3 Application and network hardening

• SSRF protection on outbound requests: DNS pinning, blocking of cloud-metadata, RFC 1918, and CGNAT ranges, resolve-once pinning, no redirect-following, and a response-size cap.
• Webhook signature verification is required on inbound platform webhooks, using strict HMAC verification for supported platforms.
• Authentication hardening: a server-enforced password policy (minimum length and complexity), multi-factor authentication, account lockout, password history, and maximum-age enforcement.
• Anti-enumeration rate limiting on order-lookup endpoints.

No system can be guaranteed perfectly secure, but we design, test, and operate nsupp to reduce risk in line with the standards above.

10. Your Rights and How to Exercise Them

Depending on where you live, you have rights over your personal data under GDPR, KVKK, CCPA/CPRA, VCDPA, CPA, PIPEDA, LGPD, and other laws. We honor the following rights for all users, applying the strictest applicable standard:

• Access — obtain a copy of the personal data we hold about you.
• Rectification — correct inaccurate or incomplete data.
• Erasure — request deletion of your personal data.
• Portability — receive your data in a portable format.
• Object and restrict — object to, or ask us to restrict, certain processing.
• Do not sell or share (CCPA/CPRA) — opt out of any "sale" or "sharing" of personal data.

10.1 We do not sell personal data

Asindie, Inc. does not sell your personal data, and we do not share it for cross-context behavioral advertising. We do not use personal data for marketing resale or third-party marketing, and we do not use customer data to train models. Because we do not sell or share personal data as those terms are defined under CCPA/CPRA, there is nothing to opt out of on that basis — but the right remains available to you and we will honor any request.

10.2 How to exercise your rights (DSAR)

nsupp provides a single operator gateway for data-subject access requests (DSARs), including per-person export and erasure. Exports are generated at the moment of download, and no copy of the exported personal data is retained afterward; requests are audited. Platform-mandated redaction webhooks (for example, Shopify's data-request, redact, and shop-redact events) are HMAC-verified, fail closed, and are idempotent, and a single erasure orchestrator is invoked on disconnect, uninstall, redaction, or workspace deletion — so a tenant deletion does not leave data behind. Tenant deletion is restricted to the account owner and requires re-authentication.

If you are an end-customer of a merchant that uses nsupp, please direct your request to that merchant, who is the controller; we will support them in fulfilling it. If you are a merchant or otherwise wish to contact us directly, email privacy@nsupp.com. You also have the right to lodge a complaint with your supervisory authority (for example, your EU data protection authority or, in Türkiye, the KVKK Board).

11. AI Governance

nsupp is AI-native, and our AI controls are designed to be conformant with ISO/IEC 42001 and the EU AI Act. We do not claim certification under either.

• No training on customer data. Our language model (Qwen3) runs on our own servers; customer data is never sent to a third-party model and is never used to train or fine-tune any model. This is enforced structurally by the fact that we host the model ourselves.
• Human-in-the-loop. AI features assist people; they do not act autonomously. Composer tools return drafts for an operator to review and send — they never auto-send. The order-status assistant answers using facts drawn only from connected platform data and does not invent facts.
• No high-risk automated decisions. nsupp does not make automated decisions that produce legal or similarly significant effects on individuals, and it does not engage in EU AI Act prohibited practices such as manipulation, social scoring, or exploitative emotion inference.
• Transparency. We are committed to clearly disclosing to end-users when they are interacting with an AI system rather than a human, consistent with EU AI Act transparency expectations.
• Metadata only. We log metadata about AI calls for reliability and governance, never the prompt or response content.

12. Cookies and Analytics on This Website

Our website uses only the cookies and similar technologies necessary to operate the site and remember your preferences. Where any non-essential cookies or analytics are used, we ask for your consent first and you may decline without losing access to the core content. We default to the most privacy-preserving option and do not use personal data placed in cookies for advertising. During the current waitlist stage, the site's data collection is limited to what is needed to operate the page and to accept waitlist sign-ups.

13. Children

nsupp is a business tool intended for use by organizations and their staff. It is not directed to children, and we do not provide services to individuals under the age of 13. Consistent with COPPA, we do not knowingly collect personal data from children under 13. If you believe a child has provided us personal data, contact us at privacy@nsupp.com and we will delete it.

14. Data Breach Notification

We maintain an incident-response process and a breach register. In the event of a personal-data breach, we will notify the relevant parties within the applicable deadlines, applying the strictest that applies:

• GDPR: notification to the competent supervisory authority without undue delay and, where feasible, within 72 hours (Art. 33), and to affected data subjects where the breach is likely to result in high risk (Art. 34).
• KVKK: notification within the timelines set by the KVKK Board (generally within 72 hours), and to affected individuals as required.
• Amazon Data Protection Policy: where applicable to data obtained via Amazon, notification within 24 hours.

As a processor, we will notify affected merchant-controllers without undue delay so they can meet their own obligations. A summary of our breach-notification commitments is also published on our public privacy page.

15. Changes to This Policy

We may update this Privacy Policy to reflect changes in our practices, our features, or the law. When we make material changes, we will update the effective date below and, where appropriate, notify you through the service or by email. Because nsupp is at a pre-launch stage, some sections describe features and flows that will apply as they become available. We encourage you to review this policy periodically.

Effective date: 14 May 2026.

16. Contact

If you have questions about this policy or wish to exercise your rights, contact us:

• Data controller / operator: Asindie, Inc., a Delaware C Corporation incorporated in Delaware, United States. Registered address: 1111B S Governors Ave, Suite 45274, Dover, DE 19904, United States.
• General contact: contact@nsupp.com.
• Privacy and DSAR contact: privacy@nsupp.com.
• Data Protection Officer / EU-UK representative: Not appointed. Our processing does not meet the Article 37 GDPR threshold that requires a Data Protection Officer. We have not designated an Article 27 GDPR representative in the EEA during the current pre-launch stage, and will designate one before offering the service to data subjects in the EEA where that obligation applies. Privacy questions: privacy@nsupp.com.
• Governing law: this policy is governed by the laws of the State of Delaware, United States, without prejudice to any mandatory data-protection rights you have under the law of your own country of residence.

You may also lodge a complaint with your local data protection authority. If you are in Türkiye, you may contact the Personal Data Protection Authority (KVKK Board).