Scope and responsibility
These policies apply to the Watsy platform operated by ربوع قرطاج للتجارة العامة محدودة المسؤولية شركة خاصة, and to everyone who accesses its systems or data: employees, contractors and service providers.
- Security and privacy lead: the company director, who approves these policies, oversees their implementation and is the point of contact for any security or privacy enquiry.
- Protected data: merchant account data, merchants' conversations with their customers and the media in them, messaging-platform access tokens, and the payment data visible to us.
- This document complements our privacy policy and data deletion instructions; it does not replace them.
Information security policy
Our security rests on three principles: least privilege, need to know, and defence in depth, so that defeating a single control is never enough to reach the data.
- Governance: the security lead approves these policies and reviews them at least once a year, and after any material change to the platform or any security incident.
- Confidentiality: anyone given access to merchant data commits to confidentiality in writing before access is granted.
- Awareness: everyone with access receives security awareness training on joining and at least once a year (phishing, password hygiene, incident reporting).
- Work devices: must run full-disk encryption, active and up-to-date malware protection, an automatic screen lock of at most 15 minutes, and automatic security updates.
- Environment separation: the staging environment is isolated from production, with a separate database and storage, and real merchant data is never copied into it.
- Providers: we only use a provider that processes merchant data under a processing agreement binding it to what we ask; the list is published in our privacy policy.
Access control policy
Access is granted on a need-to-know and least-privilege basis, and removed as soon as the need ends.
Within a merchant account
- Three tiered roles: owner (settings and billing), manager (team and day-to-day work) and agent (conversations only).
- Permissions are enforced in the API and in the database itself through row-level isolation, so no organisation can reach another's data even if the application errs.
- Passwords must be at least 10 characters; common passwords and passwords containing the user's name or email are rejected. Signing out ends the session on every device.
Platform staff
- Each staff member holds permissions limited to their own section, and none of them can grant settings or staff-management permissions — a restriction enforced in the database.
- Every view of a merchant's data by staff, and every action on a merchant's account, is logged with who did it and when.
- Suspension is checked on every request, so it takes effect immediately.
Infrastructure
- Server access uses cryptographic keys only: password login and root login are disabled.
- Administration and monitoring tools are not exposed to the internet and are reachable only through an encrypted tunnel.
- Two-step verification is mandatory on every administrative account at our hosting, database, storage, domain, source-code and messaging-platform providers.
- Operational secrets are never stored in the source repository; they are supplied to services at runtime.
Granting, review and revocation
- The security lead approves every administrative access before it is granted.
- Administrative permissions are reviewed at least once a year, and anything no longer needed is removed.
- When anyone's engagement ends, their access is revoked the same day.
- Administrative access and sensitive-event logs are retained for at least 12 months.
Data and network protection
- In transit: every connection to the platform uses TLS 1.2 or 1.3 only.
- Access tokens and secrets: encrypted with AES-256-GCM before storage, so they cannot be read as plain text even from the database.
- At rest: the database and media storage are encrypted by their providers with AES-256, and off-site backups are encrypted.
- Inbound messages: every webhook signature is verified before acceptance, so forged messages are rejected.
- Network: a firewall opens only encrypted web traffic and restricted administration, and internal services expose no port to the internet.
- Abuse prevention: rate limiting at the edge and in the API, strictest on sign-in pages.
- Browser: a strict content security policy with a random per-request nonce, and security headers on every page.
- Media: served through time-limited links, never permanent public URLs.
- Server location: application servers are hosted in Germany.
Vulnerability management
- Every code change passes an automated dependency audit, and no change with a critical vulnerability can be merged.
- Operating-system security updates are installed automatically.
- We assess the platform's external surface periodically. The latest internal assessment was on 29 September 2026; all of its findings were remediated the same day, and reports are retained.
- Independent ratings you can check now: Mozilla HTTP Observatory (A+) and Qualys SSL Labs (A+), as of September 2026.
- Remediation targets: critical within 7 days, high within 30 days, and lower severities in the next update cycle.
Backup and continuity
- A daily database backup, plus an encrypted off-site copy protected from deletion for a fixed period.
- A backup of conversation media that keeps deleted files for 14 days only before erasing them permanently (as stated in our privacy policy).
- We test restoration in practice rather than relying on backups merely existing; the latest successful test was on 29 September 2026.
Monitoring and logging
- An availability check every minute covering the database and job queues, with immediate alerts on failures and on resource thresholds.
- Automated tracking of application errors and scheduled jobs.
- Technical logs are automatically scrubbed of passwords, tokens and secrets before they are written.
- Sensitive events and staff views of merchant data are logged as described in section 3.
Incident response policy
A security incident is any event that threatens the confidentiality, integrity or availability of data: unauthorised access, a leak, a compromised account, a widespread outage, or a vulnerability being actively exploited.
| Phase | What we do | Deadline |
|---|---|---|
| Detection and triage | Record the incident and determine its severity (critical, high, medium, low) and scope | Within 24 hours of detection |
| Containment | Isolate what is affected, revoke and rotate exposed tokens and keys, and suspend compromised accounts | Immediately for critical and high |
| Eradication and recovery | Remove the cause, restore from a clean backup where needed, and verify before returning to service | According to severity |
| Notification | Notify affected merchants of what happened, how it affects them and what we did, and notify regulators and partner messaging platforms where required | Without undue delay, and within 72 hours of confirmation where personal data is affected |
| Review | A written report covering root cause, lessons learned and corrective actions | Within 14 days of closing the incident |
- We preserve the evidence and logs relating to each incident and document every incident and the decisions taken.
- We rehearse this plan at least once a year and update it with what the exercise reveals.
- To report a suspected incident: support@watsy.pro.
Reporting a vulnerability
If you find a security vulnerability in Watsy, we welcome your report and thank you for it.
- Email support@watsy.pro with a subject starting [Security], describing the issue, the steps to reproduce it and its likely impact.
- We acknowledge receipt within 3 business days and keep you informed until the issue is resolved.
- We ask that you do not access, modify or delete anyone else's data, do only the minimum needed to demonstrate the issue, and do not disclose it publicly before it is fixed.
- Out of scope: denial-of-service attacks, social engineering, physical access and spam.
- We will not take legal action against anyone who follows these terms in good faith. We do not currently offer monetary rewards.
- This guidance is also published in machine-readable form in security.txt, per RFC 9116.
Review of these policies
The security lead approves these policies and reviews them at least once a year. The date of the latest revision appears at the top of this page, and any material change is announced here.