Last updated: 6 August 2026
1. Security approach
AdyOps uses defence-in-depth: no single control is treated as sufficient. Safeguards are selected according to the deployed version, hosting environment, plan and connected providers. This policy describes the intended security posture, not a guarantee that an incident can never occur.
2. Identity and access controls
- Unique user identities and role-based workspace access.
- Manager, agent, confirmation, logistics and owner permissions separated by function.
- Login throttling, temporary lockouts and protected password handling.
- Session regeneration, expiry and secure cookie attributes where supported.
- Administrative capability to disable or unlock accounts.
3. Application security
AdyOps applies server-side validation, permission checks, request-size limits, CSRF protection for state-changing actions, safe output handling, controlled file types, protected downloads, formula-injection protection for exports and restricted error messages.
4. Data and secret handling
Integration tokens, webhook secrets and private configuration must not be exposed in browser code, public repositories or downloadable diagnostics. Access is limited according to operational need. Customers must rotate credentials that may have been shared or exposed.
5. Transport and browser protections
Production use should enforce HTTPS. Security headers may include content restrictions, anti-clickjacking, no-sniff, referrer and permissions controls. Secure deployment also depends on correct DNS, SSL, PHP, file ownership and hosting configuration.
6. File and storage controls
Public access to storage, source archives, configuration, logs and backups should be blocked. File uploads should be limited by size and verified by content type. Executable, macro-enabled and archive-bomb patterns should be rejected.
7. Logging and monitoring
Relevant events may include failed logins, account changes, administrative actions, form abuse, integration errors and suspicious access. Logs are protected and reviewed according to operational need. They should not intentionally contain passwords or full access tokens.
8. Backup and recovery
Production operators should maintain automated hosting backups and periodic offline copies of business-critical storage. Restore procedures must be tested. Backup availability and recovery time depend on the hosting plan and any written service commitment.
9. Vulnerability and patch management
Security fixes are prioritised according to severity and compatibility risk. PHP, libraries, hosting components and application modules should be kept supported. Patches should be tested so existing CRM functions and live data continue to work.
10. Incident response
AdyOps will investigate credible reports, contain affected access, preserve evidence, rotate credentials where required, assess impact and communicate with affected customers as appropriate. Notification to authorities or individuals will be made where legally required.
11. Third-party security
External hosting, messaging, payment, analytics and API providers maintain their own systems. AdyOps evaluates and limits integration access but cannot guarantee the security or continuous availability of a third-party service.
12. Customer security responsibilities
- Use strong unique passwords and secure devices.
- Grant only the permissions each user needs.
- Remove former personnel promptly.
- Protect Meta, WhatsApp, email, sheet and webhook credentials.
- Review exports and avoid downloading customer data to unmanaged devices.
- Report suspected compromise immediately.
13. Responsible disclosure
Security researchers should report a suspected vulnerability privately to Support@adyops.com, avoid accessing customer data, avoid disruption and allow reasonable time for investigation before public disclosure. AdyOps does not authorise destructive testing.
14. Contact
Use the subject “Security Report” and include clear reproduction steps, affected URL, impact and supporting evidence. Never include live customer credentials.