1. Principles
- Minimisation — we process only the data needed to deliver the service.
- Least privilege — access is granted for a specific task and revoked once it ends.
- Secure by default — safe settings apply without action from the Customer.
- Traceability — significant actions are recorded in logs.
- Verifiability — controls are tested regularly, not just declared.
2. Access control
2.1. Staff access to production environments is requested, approved by a manager and reviewed at least quarterly.
2.2. Multi-factor authentication is mandatory for administrative accounts and infrastructure access.
2.3. Access to Customer data is granted only as needed for support and is logged with a stated reason.
2.4. On termination or role change, access is revoked within 1 business day.
3. Data protection
| Area | Control |
|---|---|
| In transit | TLS 1.2+ for all external traffic, HSTS, legacy ciphers disabled |
| At rest | Disk and backup encryption (AES-256), keys stored separately |
| Secrets | Stored in a managed secrets vault, rotated at least annually |
| Isolation | Logical separation of Customer data; separate dev / stage / prod environments |
| Backups | Daily backups, 30-day retention, regular restore testing |
| Logs | Centralised collection, tamper protection, 12-month retention |
4. Secure development
4.1. Changes go through code review and automated checks before release to production.
4.2. Dependencies and container images are scanned for known vulnerabilities; critical ones are remediated within 7 calendar days, high ones within 30 days.
4.3. Production data is not used in test environments without anonymisation.
5. Incident management
5.1. Incidents are classified by impact, and a response owner is assigned to each.
5.2. The Customer is notified of a confirmed incident affecting its data without undue delay and no later than 24 hours after the fact is established.
5.3. The notification covers the nature of the incident, categories of affected data, measures taken and recommendations for the Customer.
5.4. After the investigation we produce a report with root cause analysis and a remediation plan.
6. Continuity and availability
6.1. Availability targets are set by the SLA.
6.2. The recovery time objective (RTO) and recovery point objective (RPO) are agreed in the Order based on the Customer's requirements.
6.3. The recovery plan is tested at least once a year.
7. Working with vendors
7.1. Before onboarding a subprocessor we assess its security practices.
7.2. Contractors sign confidentiality and data processing agreements with obligations no lower than those in this policy.
7.3. The list of subprocessors is available to the Customer on request; changes are notified as provided by the DPA.
8. Vulnerability disclosure
8.1. We welcome responsible disclosure. Send reports to alibek.abdekov2110@gmail.com with the subject "Security".
8.2. Please do not publish vulnerability details before remediation, and do not run testing that causes denial of service or access to other parties' data.
8.3. We acknowledge reports within 3 business days and keep you updated on remediation.