This page describes the controls that protect data in Clikgen. We have written it plainly and without overstating our position — where a control is planned rather than in place, we say so.
1. Encryption
- All traffic to and from the platform uses TLS 1.3 with modern cipher suites; older protocol versions are disabled.
- Data at rest, including database contents, attachments and call recordings, is encrypted with AES-256.
- Secrets, API keys and provider credentials are stored in a managed secrets service, encrypted with keys we rotate on a schedule.
- Credentials you supply for third-party providers are encrypted at rest and are never displayed back in full after saving.
2. Access control
- Role-based access control across every object, with separate permissions for read, create, update, delete, export and bulk send.
- Field-level masking so sensitive values can be hidden from roles that do not need them.
- Team hierarchy and territory scoping to limit record visibility.
- Two-factor authentication available to all users and enforceable per role; SSO via Google Workspace and SAML.
- Session controls including device listing, forced expiry and IP allowlisting.
- Internal access to production is least-privilege, time-bound, individually attributed and logged.
3. Infrastructure
- Hosted on major cloud infrastructure with the data residency region selected at workspace creation.
- Network segmentation between public, application and data tiers with no direct public access to databases.
- Infrastructure defined as code with peer-reviewed changes.
- Automated dependency and container scanning with a defined remediation window by severity.
- Encrypted daily backups with periodic restoration testing.
- Rate limiting and abuse detection at the edge.
4. Monitoring and audit
- Immutable audit log of record creation, modification, deletion, export, login and permission change, searchable by actor, object and date.
- Recording-access logs showing who listened to which call recording.
- Export logging including the row count and the filter applied.
- Centralised application and security log aggregation with alerting on anomalous patterns.
- Audit log export available for your own SIEM or compliance archive.
5. Incident response
We maintain a documented incident response plan with defined severity levels, an on-call rotation and named responsibilities. For any confirmed personal data breach affecting customer data we notify affected customers without undue delay and within 72 hours, with the information required under section 9 of our DPA. Post-incident we publish a written analysis to affected customers describing cause, impact and the corrective work undertaken.
6. People and process
- Background verification for staff with production access, where lawful in their jurisdiction.
- Confidentiality obligations in every employment and contractor agreement.
- Security and data protection training at onboarding and annually.
- Change management with peer review and automated testing before deployment.
- Offboarding checklist that revokes access on the last working day.
7. Responsible disclosure
We welcome reports from security researchers. Email WhatsApp on +91 96304 70438 with a description, reproduction steps and any supporting material. We will acknowledge within 48 hours, keep you updated, and credit you publicly if you would like that.
Please act in good faith: test only against your own workspace, do not access or modify other customers' data, do not run denial-of-service or social-engineering attacks against our staff, and give us reasonable time to remediate before publishing. Researchers who follow these guidelines will not face legal action from us.