Data Usage Policy

1. Categories of Data Processed

1.1 Inventory Operational Data

Core business data generated by your operations. This includes:

• Stock balances — on-hand, reserved, and available quantities per product variant per warehouse location. Updated by database triggers on every movement event; never overwritten directly by application code.
• Inventory movements — each record captures: movement type (RECEIVE / ISSUE / TRANSFER / ADJUST / RETURN / RECONCILE), product variant, source and target locations, quantity, unit cost, reason code, reference order, serial numbers, batch number, expiry date, and the authenticated user who initiated it.
• Batch and serial records — batch stock ledger tracking quantity by batch/lot number and expiry date; serial number registry for individually serialized assets.
• Audit records — stock count sessions including scheduled counts, ad-hoc counts, and reconciliation. Captures expected vs. counted quantity and variance for each line item.
• Bill of materials (BOM) — product component relationships for manufacturing work orders.

1.2 Identification and Scan Data

• Scan events — each barcode, QR, RFID, or NFC scan generates a record containing: identifier type, raw identifier value (barcode string / RFID EPC / NFC tag ID), scan timestamp, resolution status (MATCHED / UNMATCHED / PARTIAL), linked product variant or asset (if resolved), and the device ID of the scanning hardware.
• Scan data is collected only through the Verdeshell mobile app or registered scanning devices. No passive scanning is performed without user initiation.

1.3 Device and Equipment Data

• Registered scanning devices (RFID readers, NFC readers, QR scanners, mobile devices) are stored with: device name, device type, registration timestamp, and push notification token (for FCM delivery to mobile devices).
• Device utilization (scan count per device) is aggregated for reporting purposes.

1.4 Subscription and Usage Metering Data

• Usage events — lightweight meter events recording scan count and device count per organization, used exclusively for subscription billing verification.
• No personal data is included in usage events. Each event records: org_id, meter name, source record ID, and timestamp.

1.5 Notification Data

• System notifications — generated by background jobs for: low stock alerts (when available quantity drops below the reorder point), subscription expiry warnings (10 days before expiry), invoice due alerts (3 days before due date), and unauthorized movement alerts (when a stock movement is performed at a location with explicit access grants by an actor without the required access level).
• Notifications are stored per-organization and include type, title, body, reference entity type/ID, and read status.

2. Data Architecture and Tenant Isolation

Verdeshell IM is a multi-tenant platform. Tenant isolation is enforced at every layer:

• Database level — every table carrying business data includes a NOT NULL org_id foreign key. All queries issued by the application include an org_id filter derived from the authenticated JWT token.
• Application level — tenant context is populated from the JWT at request entry and injected into every service call. There is no path through the API that allows cross-tenant data access.
• Enterprise isolation — organizations on the Enterprise plan may opt for schema-level isolation, where their data is stored in a dedicated PostgreSQL schema provisioned at onboarding.
• Admin portal — admin users operate under a separate authentication flow (vs_im_admin_auth cookie) with a distinct JWT signing key and role-based access controls. Admin endpoints are prefixed /adminvcp/v1/ and are inaccessible to tenant users.

3. Processing Purposes

4. Data Storage and Infrastructure

• All Customer data is stored in a managed PostgreSQL database hosted on our cloud infrastructure provider.
• Data is encrypted at rest using AES-256 and in transit using TLS 1.2 or higher.
• Database backups are taken daily and retained for 30 days. Backup copies are encrypted with the same key as production data.
• Application logs (30-day rolling retention) do not contain personal data beyond user IDs and organization IDs — no PII, passwords, tokens, or payload bodies are logged.
• Our infrastructure is hosted within India unless a Customer explicitly requires a different region under an Enterprise agreement.

5. Data Retention Schedule

The 90-day post-termination window exists to allow Customers to export their data. We provide data export on request at no charge during this window.

6. Access Controls

Access to Customer data within the platform is governed by:

• Role-based access control (RBAC) — predefined roles (Owner, Manager, Operator, Viewer) with granular permission codes (e.g., inventory.manage, audit.submit, analytics.view). Admins can assign custom roles.
• Location-level access grants — warehouse locations may optionally have explicit user access grants (VIEW / OPERATE / MANAGE). Stock movements at restricted locations by users without a grant generate an UNAUTHORIZED_MOVEMENT notification.
• JWT authentication — every API request must carry a valid, unexpired JWT signed with the organization-specific key. Tokens expire after 15 minutes.
• Refresh token rotation — rotating refresh tokens. Reuse of a previously rotated token triggers revocation of all active sessions (compromise detection).

7. Third-Party Data Processors

We maintain Data Processing Agreements (DPAs) with the following sub-processors:

• Razorpay Software Pvt. Ltd. — processes payment card data for invoice payments. Razorpay is PCI-DSS Level 1 certified. No card data is stored by Verdeshell.
• Google Firebase Cloud Messaging (FCM) — delivers push notifications to mobile devices. We transmit device push tokens and notification payloads. No inventory operational data is transmitted to FCM beyond the notification body text.
• Cloud infrastructure provider — hosts the database, application servers, and object storage. All data is encrypted at rest; the provider has no access to unencrypted Customer data.
• Sentry — receives error reports. Our Sentry configuration strips request body data before transmission (beforeSend hook deletes event.request.data). Only stack traces and user/org IDs are transmitted.

8. Data Not Processed

To be explicit about what we do not do:

• We do not sell Customer data to any third party.
• We do not use Customer operational data (inventory, orders, scans) to train AI or machine-learning models without explicit consent.
• We do not perform cross-tenant analytics or benchmarking using identifiable Customer data.
• We do not use advertising cookies or behavioral tracking technologies.

9. Incident Response

In the event of a data breach or security incident affecting your data, Verdeshell will:

• Notify affected Customers within 72 hours of becoming aware of the incident, in accordance with the DPDP Act 2023 and GDPR obligations.
• Provide details of the nature of the breach, categories of data involved, likely consequences, and remediation measures taken.
• Notify the relevant supervisory authority (CERT-In for India; lead DPA for EU) as required by law.

10. Contact