Security & Data Protection

Zerqano is a B2B SaaS platform that processes sensitive business data including inventory records, purchase orders, supplier information, financial transactions, and AI-generated forecasts. We treat the security of that data as a core product responsibility — not just a compliance checkbox.

We follow a defence-in-depth strategy: multiple independent security layers so that if one control fails, others remain. Our security programme covers physical infrastructure (via our cloud providers), network, application, data, and operational layers.

Every Zerqano customer is a separate tenant. Tenant isolation is enforced at multiple levels so that no user or organisation can access another's data — even in the event of application-layer bugs.

• Hosting. Our backend API runs on a Hostinger VPS (EU datacenter) with a hardened Ubuntu configuration. Our frontend is hosted on Vercel's global edge network.
• Firewall. UFW firewall rules restrict inbound traffic to HTTPS (443), SSH (on a non-standard port, key-only), and application ports. All other inbound traffic is dropped.
• DDoS protection. Vercel's edge network provides DDoS protection for frontend traffic. The API layer uses rate limiting via slowapi to reject abusive request patterns.
• SSH access. Server SSH access is restricted to key-based authentication only — password authentication is disabled. Access keys are rotated and managed per-engineer.
• CORS. Cross-Origin Resource Sharing is configured with an allowlist of authorised origins (zerqano.com, www.zerqano.com). Wildcard origins are not permitted in production.
• Port exposure. Internal services (database, vector store, MCP) are not exposed on public ports. All internal communication uses private network channels.

Our development practices follow the OWASP Top 10 framework. The key controls we implement for each category:

Zerqano uses OpenAI (and optionally Groq) for large language model inference. The following controls govern how Customer Data is handled in AI processing:

• Data minimisation. Only the minimum necessary context from Customer Data is sent to LLM APIs. Full file contents are summarised or chunked before transmission where possible.
• No model training on Customer Data. Our API agreements with OpenAI and Groq include opt-out from model training on API-submitted data. Customer Data is not used to train public models.
• Prompt injection defences. User-supplied content passed to LLMs is sanitised and wrapped in system-level delimiters. LLM outputs are treated as untrusted and validated before being stored or displayed.
• API key scoping. Third-party API keys are scoped to minimum required permissions and stored as encrypted secrets — never exposed in logs or responses.
• Subprocessor DPAs. All AI providers are covered by Data Processing Agreements and are bound by GDPR Article 28 obligations.

• Principle of least privilege. Team members are granted access only to the systems and data required for their role. Access is reviewed quarterly.
• MFA required. All internal accounts (GitHub, cloud providers, SaaS tools) require MFA. Hardware security keys are encouraged for privileged access.
• Security training. All team members complete security awareness training on onboarding and annually thereafter, covering phishing, social engineering, and secure coding practices.
• Access provisioning & deprovisioning. Access is provisioned on a need-to-know basis and revoked immediately on role change or departure.
• No direct production database access. Customer Data queries in production require documented justification and are logged in our audit trail.
• Confidentiality agreements. All team members and contractors sign NDAs covering Customer Data and business confidential information.

• Error monitoring. Sentry is integrated across the API and frontend. All unhandled exceptions are captured, alerted, and triaged within our on-call rotation.
• Access logging. All API requests are logged with timestamp, endpoint, HTTP method, response status, and user ID (no request bodies). Logs are retained for 12 months.
• Anomaly detection. Unusual access patterns — including abnormally high request rates, access from new countries, and bulk data export attempts — trigger automated alerts.
• Uptime monitoring. External uptime checks run every 60 seconds. Automated alerts are sent if any critical endpoint is unavailable for more than 2 minutes.
• Dependency scanning. Automated tools (Dependabot, pip-audit) scan dependencies weekly for known CVEs and alert our engineering team.

We maintain a documented Incident Response Plan (IRP) that is reviewed and tested annually. Our process covers:

Backups are stored in a geographically separate location from the primary infrastructure and are encrypted at rest. Restore tests are conducted at least quarterly. Our Recovery Point Objective (RPO) target is 24 hours for all tiers.

Out of scope: Denial-of-service attacks, social engineering of Zerqano staff, physical security, or vulnerabilities in third-party services outside our control.

For privacy rights requests and our full data protection policy, see our Privacy Policy. For the terms governing use of the Service, see our Terms of Service.