Security Policy

Renidly operates a risk-based security program with administrative, organizational, and technical safeguards designed to protect the confidentiality, integrity, and availability of customer data. The program is proportionate to the nature of the Service and the size of our operations and is reviewed at least annually by leadership.

• All employees and contractors are bound by written confidentiality undertakings.
• Background screening (where lawful) is performed before hiring for positions with access to production.
• Mandatory security and privacy training on hire and annually thereafter.
• Password manager required for all work accounts; unique passwords per service.
• Hardware-token or app-based MFA on all corporate accounts. SMS-based 2FA is not permitted.
• Access provisioning and de-provisioning are tied to HR events; access is removed within one business day of termination.

Before engaging any new vendor that will process customer data, we perform a risk-based security assessment. Every vendor is contractually bound by confidentiality, privacy, and security obligations consistent with our own. The current list of sub-processors is published on the Trust Center and updated when changes occur.

The Service is hosted on regulated cloud infrastructure operated by reputable providers. Customer data is logically segregated by tenant identifiers across all storage layers. Production traffic is isolated from corporate networks; database engines are not exposed to the public internet and accept connections only from the production application network.

Where feasible, sensitive operational data (e.g., verification tokens) is pseudonymized so that theoretical compromise of a single layer does not yield directly exploitable data.

• Role-based access control under the principle of least privilege.
• Multi-factor authentication required for all administrative access.
• High-risk actions in the production environment are logged and centrally reviewable.
• Quarterly access review for production systems; access removed within one business day of role change or termination.
• Customer dashboard accounts authenticate against a hardened auth service with rate limiting and breach-password detection.

• TLS 1.2 or higher for all in-transit traffic; only modern cipher suites permitted.
• AES-256 for data at rest on primary storage.
• Encrypted backups; offsite backup media also encrypted at rest.
• Customer passwords stored as bcrypt hashes; OAuth tokens encrypted with AES-256-GCM.
• Cryptographic material managed via a hosted key-management service with strict role separation.

• All changes ship through peer-reviewed pull requests with mandatory CI checks.
• Static analysis and dependency scanning run on every build.
• Critical infrastructure changes follow change-management procedures with rollback plans.
• Deployments use immutable artifacts and rolling rollouts; production secrets are never embedded in builds.

Continuous third-party scanning of our infrastructure and dependencies. Findings are triaged on severity:

• Critical: remediation or compensating control within 7 days.
• High: within 30 days.
• Medium: within 90 days.
• Low / informational: tracked and addressed during regular maintenance.

Application, infrastructure, and audit logs are centrally collected. Sensitive user and support actions are recorded with non-repudiation. Anomalies trigger on-call alerts; security-relevant events are investigated and escalated according to our incident response plan.

• Automated daily backups of primary databases; retained per documented schedule.
• Off-site backup copies for geographic redundancy.
• Disaster recovery exercises performed periodically to validate restore procedures.
• High-availability deployment topology to minimize impact of single-instance failure.

Renidly maintains a documented incident response plan with defined roles, communication paths, and escalation procedures. A 24×7 on-call rotation covers production. In the event of a confirmed personal data breach affecting customer data, we will notify affected customers within 48 hours of confirmation, providing the information required by Article 33(3) GDPR to the extent reasonably available. Lessons learned are formally reviewed and fed back into the security program.

We welcome reports from security researchers. If you believe you have found a vulnerability, please contact [email protected]. We commit to:

• Acknowledge receipt within two business days.
• Provide a status update within ten business days.
• Refrain from legal action against researchers who act in good faith, do not violate user privacy, do not exfiltrate data beyond what is necessary to demonstrate the issue, and give us reasonable time to remediate before public disclosure.

Security: [email protected]
Privacy: [email protected]
Trust Center & documentation requests: [email protected]