Security

1. Security commitment

TorpedoWeb LLC, a Delaware limited liability company operating Opseno ("Opseno"), is built for businesses that depend on accurate billing, inventory, payroll, and guest operations. Security is embedded in our architecture, development process, and operational practices.

This page describes technical and organizational controls we apply to the Opseno cloud platform. It supplements our Privacy Notice and Terms of Service. For vulnerability reports, contact security@opseno.com.

2. Platform architecture

• Multi-tenant SaaS with logical workspace isolation: each customer workspace is scoped by tenant identifiers enforced in application code and database queries.
• Role-based access control (RBAC) with least-privilege defaults for staff, managers, and administrators.
• Separate admin console (Opseno Admin) with additional authentication and audit expectations for internal operators.
• API routes protected by session validation, CSRF considerations on state-changing browser requests, and permission checks per module.
• Production deployments on modern cloud infrastructure with automated TLS termination and hardened headers (Content Security Policy, HSTS where applicable).

3. Data protection

4. Authentication and access

• Email and password authentication with secure session management.
• Workspace-level user roles limit access to POS, payroll, HR, settings, and admin functions.
• Failed login and permission-denied events are logged for review.
• Session expiry and logout invalidate client-side access to protected routes.
• Optional future support for SSO/MFA may be offered on enterprise plans; contact sales for roadmap details.

5. Application security

• Secure development practices including code review, dependency updates, and automated testing for critical paths.
• Input validation and parameterized database queries to mitigate injection risks.
• Content Security Policy and other HTTP security headers on public and authenticated surfaces.
• Rate limiting and abuse detection on sensitive endpoints where implemented.
• Separation between marketing sites, authenticated app routes, developer API docs, and admin consoles.

6. Infrastructure and operations

• Application hosting via Vercel or equivalent with platform-managed DDoS mitigation and edge protection.
• Database hosting on dedicated PostgreSQL instances (self-hosted VPS or managed Postgres) with connection pooling (PgBouncer) for production workloads.
• Infrastructure access restricted to authorized personnel; production secrets stored in environment variables, not in source code.
• Scheduled maintenance windows communicated when possible; emergency patches applied for critical vulnerabilities.
• Monitoring of application health via /api/v1/health and operational alerting for downtime.

7. Backups and disaster recovery

We maintain regular database backups according to our operational runbooks. Backup frequency and retention depend on deployment tier; production guidance targets daily backups with point-in-time recovery where configured.

Disaster recovery procedures are documented internally. Recovery time objectives vary by plan; enterprise customers may negotiate enhanced RPO/RTO in writing.

Customers are encouraged to export critical reports and records periodically as an additional safeguard.

8. Vendor and subprocessor security

We evaluate subprocessors for security posture before integration. Categories include hosting, email, payments, and observability. See our Privacy Policy for representative providers.

Subprocessor agreements include confidentiality and security obligations appropriate to the data processed.

9. Incident response

We maintain an internal incident response process for detecting, containing, and remediating security events.

• Security events are triaged by severity with escalation to engineering and leadership as needed.
• Affected customers and Data Principals will be notified without undue delay when a breach of personal data is confirmed, consistent with the DPDP Act and Rules (Rule 7 dual-stream: Principals + Data Protection Board, including the 72-hour Board detailed report clock). See docs/DPDP-BREACH-RUNBOOK.md.
• Post-incident reviews identify root causes and preventive improvements.
• Report suspected vulnerabilities responsibly to security@opseno.com. Please do not publicly disclose before we have had reasonable time to investigate.

10. Compliance and customer responsibilities

Opseno provides tools; compliance with GST, labour law, PCI-DSS for card handling, and industry regulations remains your responsibility. When you connect payment gateways, card data is typically handled directly by the certified payment provider.

• Assign appropriate roles to staff and revoke access when employees leave.
• Use strong, unique passwords and protect devices used to access the POS.
• Configure GST and business settings accurately; verify reports before filing.
• Review integration permissions for WhatsApp, email, and third-party APIs.
• Notify us promptly at security@opseno.com if you suspect account compromise.

11. Shared responsibility model

Cloud security is a shared responsibility. Opseno secures the platform, network boundaries we control, and tenant isolation in our application layer. You secure your accounts, endpoints, physical POS devices, thermal printers, and policies governing how staff use the system.

12. Security contact

Security inquiries and responsible disclosure: security@opseno.com

General support: support@opseno.com

Privacy and data subject requests: privacy@opseno.com

Important notice

This Security page describes our practices in good faith and may be updated as our platform evolves. It is not a warranty, certification, or legal guarantee. Organizations requiring formal audits, SOC 2 reports, or custom data processing agreements should contact us for enterprise options.