Information Security Policy
Last updated: September 29, 2026
The security program of Central Seller: infrastructure, access control, data classification and encryption, vulnerability management and incident response. It applies to everyone who operates the system and to every environment where store data is processed.
1. Principles and responsibilities
Store data belongs to the seller. We collect only what the service needs, give each person the minimum access required and prefer controls enforced by the system itself over manual procedures. The partners of Central Seller Gestão e Integração Ltda. are responsible for this policy, review it at least once a year and whenever the system changes, and answer security questions at centralseller.adm@gmail.com.
2. Infrastructure and network
- The system runs entirely on managed cloud providers: database on Supabase (AWS, São Paulo), web panel and API gateway on Vercel (São Paulo) and integration workflows on n8n Cloud. We run no servers of our own and no office network holds store data.
- The database is not reachable directly: every access goes through authenticated APIs, and row-level security decides which rows each request can read or change.
- All traffic uses HTTPS/TLS 1.2 or higher. The providers supply network isolation, DDoS protection and access logs.
- Development, test data and production are separated: tests use a fictitious demonstration company, never real store data.
3. Access control (least privilege)
- A single membership table defines which companies and stores each person can see, with the roles owner, admin and operator. Only owners and admins can connect or disconnect stores, approve replies or change automatic rules.
- This rule is enforced inside the database for every table and view, not only in the screens. An isolation test with more than 80 checks logs in as a user of one company and confirms it cannot read or act on another company's stores; it runs after every change to access rules.
- AI assistants connected by users receive their own revocable access key, see only the stores of that user and can only use the tools of their plan. Keys are stored as SHA-256 hashes.
- Service credentials are used only on the server side and never reach the browser.
- Administrative accounts of the team (code repository, hosting, database and workflows) use unique passwords and multi-factor authentication. Access is removed as soon as someone no longer needs it.
4. Data classification and encryption
| Class | Examples | Rule |
|---|---|---|
| Public | This page, marketing material | No restriction. |
| Internal | Source code, documentation | Private repository; never contains secrets or real data. |
| Confidential | Sales, listings, costs, reputation of a store | Only people with access to that store; encrypted at rest. |
| Sensitive | Buyer personal data, marketplace and ERP tokens, API keys | Tokens and keys only in the encrypted vault or as hashes; buyer data only in the store's own records, never in logs or exports we control. |
- Encryption in transit with TLS and at rest with AES-256 (Supabase/AWS).
- OAuth tokens of marketplaces and ERP tokens are kept in Supabase Vault; screens and integrations cannot read them directly.
- Secrets are never stored in the code repository; they live in the providers' environment variables and credential stores.
- Workflows that handle ERP tokens do not keep execution history.
5. Actions on marketplaces
Integrations are read-only by default. The only actions that write to a marketplace (replying to buyers, taking part in promotions) require approval by an owner or admin, or an automatic rule that they explicitly turned on, and each approval uses a single-use code that expires in minutes. Before sending, the system reads the marketplace again and only proceeds if the action is still allowed.
6. Workstations and daily operation
- Company computers have antivirus active and automatic updates, screen lock and password.
- Strong unique passwords, multi-factor authentication where available, and no store data kept on local disks or in e-mail.
7. Vulnerability and threat management
- Automated security and performance advisors of the database are reviewed after every schema change; findings are fixed or documented.
- Dependencies are updated regularly and every change is reviewed before going to production.
- Access to functions is revoked from anonymous users; every privileged function checks the caller's access to the store.
- Health checks watch the real-time integration and alert when notifications stop arriving.
8. Incident response
- Report: anyone who suspects an incident writes to centralseller.adm@gmail.com. Sellers can use the same address.
- Contain: revoke keys and tokens involved, disconnect affected stores and stop the affected workflows.
- Assess: identify data, stores and people affected, using provider logs.
- Notify: affected sellers and the marketplaces involved (including TikTok Shop and Shopee) within 72 hours of confirmation, and the ANPD and data subjects when required by the LGPD.
- Fix and learn: correct the cause, record what happened and update this policy.
The partners are the incident response owners; one of them coordinates each case and is the single point of contact until it is closed.
9. Providers
We only use providers that publish their own security programs (Supabase, Vercel, n8n, AWS, which hold SOC 2 reports). The list of providers and where they process data is in the Privacy Policy.