Information Security Policy

Effective: 20 October 2026 · Reviewed at least once a year

This policy sets out how Reachlee protects the information it handles: the data of the creators and businesses who use Reachlee, and the data of the people who interact with their accounts. It applies to every system, service and device used to build or run Reachlee. Related documents: the Access Control Policy, the Incident Response Policy and our Privacy Policy.

1. Responsibility

Reachlee has a designated security and privacy owner who approves this policy, keeps it current and is the point of contact for security matters at tusharkapil@reachlee.co. Everyone given access to Reachlee systems must follow this policy and the Access Control Policy.

2. Information we protect

• Confidential: account access tokens, credentials and secrets; message and comment content; contact details our customers collect; billing records.
• Internal: analytics, logs and infrastructure configuration.
• Public: marketing pages, documentation, and pages our customers choose to publish.

We collect only what the product needs to work, and request the narrowest platform permissions that support the features a customer uses.

3. Infrastructure and network security

• Reachlee is hosted on Amazon Web Services, with all public traffic served through a content delivery network.
• Application servers accept traffic only through approved paths. Databases and internal services are not reachable from the internet.
• Storage is private by default; only content customers choose to publish is publicly readable.
• Operating-system security updates are applied automatically.

4. Encryption

• In transit: all connections use TLS 1.2 or higher, and browsers are instructed to use HTTPS only.
• At rest: account access tokens and integration credentials are encrypted with AES-256 before they are stored, and backups are encrypted.
• Secrets are never stored in source code. They are kept in encrypted secret storage and provided to systems only when needed.

5. Secure development

• Code is kept in a private repository. Changes are reviewed, tested and verified before release, and significant features are rolled out gradually.
• Events received from platforms and payment providers are verified by signature before processing; unsigned or altered requests are rejected.
• Every request for customer data requires authentication and is limited to the customer's own workspace.
• Development uses separate environments and test data. Production data is accessed only when needed to operate the service or resolve a customer's support request.
• Logs are filtered so that credentials and sensitive payloads are never recorded.

6. Vulnerability and patch management

• Dependencies are audited for known vulnerabilities on a regular schedule and before releases. Fixes are prioritized by severity, with critical issues addressed first.
• We run periodic security assessments of our application and infrastructure.
• Anyone can report a vulnerability to tusharkapil@reachlee.co.

7. Logging and monitoring

Our systems are monitored continuously for availability, errors and unusual activity. Security-relevant events are logged and retained for a limited period in line with our Privacy Policy.

8. Backup and recovery

Production data is backed up regularly to encrypted, access-restricted storage, and backup health is monitored so that data can be restored if needed.

9. Devices

Devices used to work on Reachlee must use full-disk encryption, lock automatically when idle, and stay up to date with security updates.

10. Vendors

We work with a small set of established providers for hosting, payments, email, analytics and AI, each receiving only the data its service requires. Providers are reviewed before they are added and periodically after that.

11. Data retention and deletion

We keep personal data only as long as needed, as set out in our Privacy Policy. Customers can disconnect accounts or delete their Reachlee account at any time, and we honour platform deauthorization and data-deletion requests.

12. Review

This policy is reviewed at least once a year, after any significant security incident, and when our systems change materially.