ZipZy® Security Policy

Our programme is built on:

• Defence in depth — no single control is relied upon.
• Least privilege — access is granted only where necessary and only for as long as necessary.
• Secure by default — safe configuration is the default state.
• Data minimisation — we collect and retain only what the Services require.
• Verifiability — security-relevant actions are logged and auditable.
• Continuous improvement — controls are reviewed and strengthened as threats evolve.

3.1 In Transit. All connections to the Services use TLS 1.2 or higher with modern cipher suites. HTTP requests are redirected to HTTPS. HTTP Strict Transport Security (HSTS) is enforced. Internal service-to-service communication within our infrastructure is encrypted.

3.2 At Rest. Databases, file storage, and backups are encrypted using AES-256. Backup archives are separately encrypted before storage.

3.3 Certificates. TLS certificates are automatically provisioned and renewed. Customer custom domains are automatically issued certificates on verification.

3.4 Key Management. Encryption keys and application secrets are held in a managed secret store with restricted access and audit logging. Keys are rotated on a defined schedule and immediately on suspected compromise. Secrets are never committed to source control; automated scanning blocks commits containing credential patterns.

3.5 Field-Level Protection. Particularly sensitive fields — including credentials, tokens, API keys, and payroll identifiers in the HRMS module — receive additional application-layer encryption or one-way hashing beyond storage-level encryption.

4.1 Password Storage. Passwords are never stored in plaintext or reversibly encrypted. They are hashed using a modern memory-hard algorithm with a unique per-user salt and calibrated work factor.

4.2 Password Requirements. A minimum length is enforced, candidate passwords are checked against known-breached password corpora, and complexity is encouraged rather than enforced through arbitrary composition rules, consistent with current guidance.

4.3 Brute-Force Protection. Progressive rate limiting, temporary lockout, and challenge mechanisms protect authentication endpoints. Credential-stuffing patterns are detected and blocked at the edge.

4.4 Sessions. Session tokens are cryptographically random, transmitted only over HTTPS in HttpOnly, Secure, SameSite cookies, and invalidated on logout, password change, and detected anomaly. Idle and absolute session lifetimes are enforced. Users can view and revoke active sessions from account settings.

4.5 Password Reset. Reset links are single-use, time-limited, and delivered only to the verified email address. Reset invalidates all existing sessions and API tokens where configured.

4.6 Single Sign-On. Third-party identity providers are supported for login. Enterprise plans support SAML/OIDC SSO with organisation-enforced authentication.

5.1 For Customers. MFA is available on all plans and supports time-based one-time passwords (TOTP) from any standard authenticator application. Recovery codes are issued at enrolment and shown once.

5.2 Enforcement. Workspace Administrators can require MFA for all Users in the Workspace. We strongly recommend enabling this.

5.3 For Our Personnel. MFA is mandatory for every employee and contractor for all administrative, production, and source-control access. Phishing-resistant factors are used for the highest-privilege roles.

5.4 Step-Up Authentication. Sensitive actions — changing email, disabling MFA, generating API keys, exporting bulk data, deleting a workspace — require re-authentication.

6.1 Role-Based Access Control. The Services implement granular, scoped permissions in a module.action:scope structure, allowing Administrators to grant precisely the access each role requires.

6.2 Tenant Isolation. Every data access path enforces workspace scoping at the application and query layer. Isolation is covered by automated regression tests.

6.3 Internal Access. Production access is restricted to a small number of named engineers, granted just-in-time, time-bound, approved by a second person, and fully logged. Standing production access is not granted.

6.4 Access Reviews. All internal access rights are reviewed at least quarterly. Access is revoked on the same business day as role change or departure.

6.5 Customer Data Access. Our personnel do not access Customer Content except where necessary to resolve a support request you have raised, to investigate abuse, or to restore service. Such access is logged and available to Enterprise Customers on request.

7.1 Architecture. Primary application and database infrastructure is self-managed and located in India. Data Backups are stored in the AWS Asia Pacific (Mumbai) region.

7.2 Edge Protection. Cloudflare provides DDoS mitigation, a Web Application Firewall with managed and custom rulesets, bot management, TLS termination, and rate limiting at the network edge. Origin infrastructure is not directly reachable from the public internet.

7.3 Reverse Proxy. Nginx operates as a hardened reverse proxy providing request filtering, connection and rate limiting, security headers, and TLS enforcement.

7.4 Network Segmentation. Production, staging, and corporate environments are isolated. Database services are not exposed publicly and accept connections only from authorised application hosts. Administrative interfaces are reachable only through authenticated, restricted channels.

7.5 Hardening and Patching. Operating systems are hardened to a documented baseline, run only required services, and are patched on a defined cadence:

7.6 Process Supervision. Application processes run under supervision with automatic restart, health checks, and resource limits, under dedicated non-privileged service accounts.

7.7 Change Management. Infrastructure changes are peer-reviewed, applied through repeatable configuration, and are reversible. Emergency changes are documented retrospectively within one business day.

8.1 Secure Development. All code changes undergo peer review before merge. Security-relevant changes receive additional review. Branch protection prevents unreviewed changes reaching production.

8.2 Automated Scanning. Continuous integration includes static analysis, dependency vulnerability scanning, secret scanning, and container image scanning. Builds fail on critical findings.

8.3 Common Vulnerability Classes. The application uses parameterised queries throughout, output encoding and Content Security Policy against cross-site scripting, anti-CSRF tokens for state-changing requests, strict server-side authorisation checks on every request, validated and constrained file uploads, and server-side allow-listing for outbound requests to prevent server-side request forgery.

8.4 Dependencies. Third-party dependencies are pinned, monitored for advisories, and updated on a defined cadence with expedited handling for critical advisories.

8.5 API Security. API keys are issued with defined scopes, displayed once at creation, stored hashed, and revocable at any time. Requests are authenticated, rate limited, and logged. See the API Terms.

8.6 Content Safety. Destinations, hosted pages, and uploaded files are scanned against threat-intelligence feeds for malware and phishing. Confirmed malicious resources are disabled and, where appropriate, replaced with an interstitial warning.

9.1 What We Log. Authentication events including failures, MFA changes, permission and role changes, API key creation and revocation, bulk exports, deletions, administrative actions, billing changes, and security-relevant application events.

9.2 Retention. Application and access logs are retained for 12 months. Security incident records are retained for 3 years from closure.

9.3 Integrity. Logs are centralised, write-once from the perspective of application services, and access to log stores is restricted and itself logged.

9.4 Customer Visibility. Workspace Administrators can view an audit trail of significant actions within their Workspace. Extended audit export is available on Enterprise plans.

9.5 Privacy in Logs. Logs are designed to exclude credentials, tokens, payment details, and message bodies. IP addresses in analytics reporting are truncated or hashed.

Availability, latency, and error rates are monitored continuously with automated alerting and 24×7 on-call escalation for critical alerts. Anomaly detection covers unusual authentication patterns, privilege escalation, abnormal data export volume, and traffic spikes. Edge telemetry from Cloudflare feeds attack detection. Detection rules are reviewed after every significant incident.

11.1 Backups. Automated Data Backups run on a defined schedule with a rolling 35-day retention. Backups are stored in a separate failure domain from primary infrastructure.

11.2 Restore Testing. Restores are tested periodically to verify integrity and recovery timing.

11.3 Business Continuity. A documented business continuity and disaster recovery plan defines recovery point and recovery time objectives, roles, and communication procedures. It is reviewed at least annually.

11.4 Redundancy. Critical components are configured for automatic recovery. Edge caching and DNS-level failover reduce the impact of origin disruption on link and QR resolution.

12.1 Plan. We maintain a documented incident response plan covering detection, triage, containment, eradication, recovery, notification, and post-incident review, with defined severity levels and escalation paths.

12.3 Breach Notification. We notify affected Data Principals and the Data Protection Board of India without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach. Where we act as Processor, we notify the affected Customer within 48 hours so they can meet their own obligations. See Section 12 of the Data Processing Addendum.

12.4 Communication. Status and updates are published on our status page. Direct notification is sent to the registered security or administrative contact.

12.5 Post-Incident Review. Every SEV-1 and SEV-2 incident receives a blameless post-incident review with root cause analysis and corrective actions tracked to closure. A summary is available to affected Customers on request.

Background verification is conducted appropriate to role before production access is granted. All personnel sign written confidentiality agreements that survive employment. Security and data protection training is delivered at onboarding and annually, with additional secure-coding training for engineers and periodic phishing simulations. Company devices are encrypted, patched, screen-locked, and centrally manageable. Offboarding follows a documented checklist including same-day revocation of all access and recovery of devices.

Vendors with access to production data or systems are assessed for security and data protection posture before onboarding, contracted under written data processing terms with confidentiality, security, and breach notification obligations, reviewed periodically, and removed promptly when no longer required. Current subprocessors are listed in the Subprocessor List Policy.

Data is classified as public, internal, confidential, or restricted, with handling requirements attached to each class. Production data is not used in development or test environments; test data is synthetic or anonymised. Data is retained per the Data Retention Policy and deleted or irreversibly anonymised at the end of its retention period. Storage media are securely wiped or destroyed at end of life.

16.1 Penetration Testing. Independent penetration testing is conducted at least annually and after significant architectural change. Summary reports are available to Customers under NDA.

16.2 Internal Testing. Automated security testing runs in CI on every change. Periodic internal reviews cover access controls, tenant isolation, and configuration drift.

16.3 Vulnerability Management. Findings from any source are triaged by severity and remediated within the service levels in Section 7.5. Remediation status is tracked to closure.

16.4 Third-Party Reports. Where we hold third-party attestations, they are made available to Customers under NDA. See the Compliance Statement for current certification status.

We welcome reports from security researchers. Report vulnerabilities to security@zipzy.in. Our commitments, scope, safe harbour terms, and response timelines are set out in the Vulnerability Disclosure Policy.

Do not conduct testing against production systems outside the terms of that policy; unauthorised testing violates the Acceptable Use Policy.

We recommend that every Customer:

• Enforce MFA for all Users in the Workspace
• Apply least-privilege roles and review User access quarterly
• Remove departed Users promptly
• Scope API keys narrowly, rotate them regularly, and never embed them in client-side code or public repositories
• Use SSO where available on your plan
• Keep the security contact email current so breach notifications reach the right person
• Review the audit trail regularly for unexpected activity
• Avoid placing confidential information in publicly resolvable links, QR codes, or hosted pages

Report suspected compromise of your Account immediately to security@zipzy.in.

Our security programme is designed to meet the reasonable security safeguards required under Section 8(5) of the DPDP Act and Section 43A of the Information Technology Act, 2000, is aligned to ISO/IEC 27001 control domains, and is being developed toward SOC 2 Type II readiness. Current status is described in the Compliance Statement.

Pranava Company Group (ZipZy®)
62, Mandola, Loni, Ghaziabad, Uttar Pradesh 201102, Bharat (India)