Security Policy

1. Our Commitment to Security

At DA592 LTD, trading as Masheev, security is foundational to everything we build and operate. We take a security-first approach to the design, development, and operation of our platform, and we are committed to protecting the confidentiality, integrity, and availability of the data entrusted to us by our customers.

This Security Policy provides an overview of the measures we implement to safeguard the Services and the data processed through them. We continuously review and enhance our security practices as threats evolve and industry standards advance.

2. Infrastructure Security

Our infrastructure is designed for resilience, performance, and security from the ground up:

Edge Computing and DDoS Protection: The web application and API run on Cloudflare Workers. Provider network protection is supplemented by application authentication, authorization, input validation and rate limits. WAF and bot-management features depend on the configured service and plan; this policy does not claim every optional feature is enabled.
Managed Database Architecture: Core application PostgreSQL databases are hosted on PlanetScale in EU and US regions. Billing uses a separate Lago service with its own database, job queue and storage on Railway. Backup, recovery and maintenance controls must be verified for each service separately.
Provider Certifications: Infrastructure-provider attestations apply to their stated service and scope; they do not certify Masheev or every product feature. We review account-specific assurance documents where available and track missing evidence rather than treating a public provider link as approval.
Network Isolation: Sensitive application operations require server-side authorization. Private service bindings are used for supported internal Worker operations; external providers use authenticated connections. Network location alone does not grant application access.

3. Data Encryption

We use transport and managed-storage encryption controls to protect data in transit and at rest:

Encryption at Rest: Managed database and object-storage providers supply encryption at rest under their service-specific controls. Their encryption algorithms, key management and service scope are documented by the applicable provider; this is not a claim of end-to-end encryption of customer communications.
Encryption in Transit: All data transmitted between your devices and the Services is encrypted using Transport Layer Security (TLS) 1.2 or higher. We enforce HTTPS across all endpoints and do not support unencrypted connections.
Database Encryption: Application database connections use TLS with certificate verification. Authorized application services can process plaintext records; storage encryption does not prevent that intended processing.
Object Storage Encryption: Files and media stored in Cloudflare R2 are encrypted at rest. EU-region organizations use EU-jurisdiction R2 bindings. A region selection alone does not establish compliance for all processing or external providers.

4. Access Controls

We maintain strict access controls to minimize the risk of unauthorized access:

Role-Based Access Control (RBAC): Application roles limit which organization data and administrative functions a user may access. Sensitive operations also enforce server-side authorization; external provider consoles have separate access controls.
Least Privilege Principle: Our access standard is to grant only the permissions needed for a person's duties. Privileged application and provider accounts are subject to separate enrollment and access review; an application role alone does not prove every historical external grant has been recertified.
Multi-Factor Authentication (MFA): Application system-administrator operations require verified second-factor assurance, and organization users can enable MFA for their accounts. Enrollment of every privileged account and verification of external provider MFA are tracked as operational controls rather than inferred from the application gate.
Access Reviews: Access grants, role changes and departures are handled through an operational review and revocation process. Review completion must be supported by account-specific evidence.

5. Application Security

Security is integrated into every stage of our software development lifecycle:

Secure Development Lifecycle (SDLC): We follow secure coding practices throughout the development process, incorporating security requirements from design through deployment and maintenance.
Code Reviews: Security-sensitive changes require review and relevant verification before release. Automated checks complement human review; they are not a guarantee that every defect will be detected.
Automated Security Scanning: We use automated static analysis, dependency scanning, and vulnerability detection tools in our continuous integration pipeline. These tools identify potential security issues before code reaches production.
Dependency Vulnerability Monitoring: The local release pipeline scans dependencies and release images for known vulnerabilities. Findings are triaged and remediated according to severity; a release scan is a point-in-time check, not continuous or complete vulnerability coverage.
Input Validation and Output Encoding: We use schema validation, parameterized database queries and framework output encoding to reduce risks such as SQL injection and cross-site scripting.

6. AI Security

Our AI-powered features are subject to additional security measures to ensure safe and responsible use:

Prompt Injection Defense: We implement structural defenses against prompt injection attacks, including input sanitization, system prompt protection, and output validation. Our approach follows industry best practices for AI security.
AI Output Validation: AI-generated outputs are subject to validation and safety guardrails to reduce the risk of harmful, inappropriate, or misleading content.
AI Provider Security Assessments: AI-provider approval requires review of the actual service, account settings, retention and applicable contractual safeguards before customer data is processed.
No Customer Data for Model Training: We do not use Customer Data to train our own AI models. Provider processing, retention and training restrictions depend on the selected service, contract and account settings, as described in the Privacy Policy and Sub-Processor List.
Rate Limiting and Abuse Prevention: AI features are protected by rate limiting and abuse detection mechanisms to prevent misuse, resource exhaustion, and automated attacks.

7. Incident Response

We maintain a documented incident response program to detect, investigate, and respond to security incidents effectively:

Incident Response Plan: We have a formal, documented incident response plan that defines roles, responsibilities, escalation procedures, and communication protocols for handling security incidents.
Breach Notification: When acting as processor, we notify affected customers without undue delay, and in any event within 48 hours, after becoming aware of a Personal Data Breach affecting their Customer Data, and provide further information as the investigation develops. When acting as controller, we assess and make regulator and affected-person notifications under the applicable legal thresholds and deadlines (including the GDPR’s 72-hour regulator deadline where applicable). We do not wait for a completed investigation, and do not apply the GDPR deadline as a universal CCPA rule.
Post-Incident Review: Following the resolution of any significant security incident, we conduct a thorough post-incident review to identify root causes, evaluate our response effectiveness, and implement improvements to prevent recurrence.
Continuous Monitoring: Application and provider monitoring supports investigation and operational alerts. Coverage and response depend on configured signals and operator availability; it does not guarantee detection of every incident.

8. Data Protection

We are committed to the highest standards of data protection and privacy:

UK and EU privacy requirements: Our Privacy Policy and DPA describe controller and processor responsibilities, rights handling and safeguards. Applicable obligations depend on the processing, parties and jurisdictions; this policy is not a certification of GDPR compliance.
US privacy requirements: Our Privacy Policy describes applicable US rights and request routes, including California rights where applicable. Service-provider restrictions and other state requirements must be assessed for the actual use case.
Data Minimization: We design collection and processing around specified purposes and limit fields where practical. Retention, erasure and regional-reconciliation work address unnecessary or incorrectly placed copies; this policy does not claim those historical cases are already resolved.
Purpose Limitation: Personal data is processed only for the specific purposes for which it was collected, and is not further processed in a manner incompatible with those purposes.
Data Protection Impact Assessments: We assess whether a DPIA is required for high-risk processing and document the analysis and residual risks. A draft assessment is not an approved decision, and any required consultation or mitigation must be completed before the relevant processing is authorized.
Data Residency: Customers select an EU or US region for regional application databases and object storage. Central identity and billing records, global edge execution and external providers have separate processing locations; see Privacy Policy Section 9.3. The setting does not confine every processing operation to that region.

For complete details on our data processing practices, please see our Privacy Policy.

9. Vendor Security

We hold our third-party vendors and sub-processors to the same high security standards we maintain internally:

Due Diligence: Our vendor approval process requires evidence of the relevant service’s security practices, data handling and contractual safeguards.
Contractual Security Requirements: Where a vendor processes Customer Data on our behalf, the applicable written processing and transfer terms must be documented. Public vendor policy links do not replace those agreements.
Ongoing Monitoring: The Sub-Processor List and provider contract matrix identify services for review of incidents, processing terms, transfer mechanisms and available assurance documents. Open account-specific evidence or approval gaps remain tracked until resolved.

10. Payment Security

Payment details entered in the web billing form are collected by Stripe's Payment Element. The application uses payment-method identifiers and limited card metadata, such as brand, expiry and last four digits, to manage billing. Do not send full card numbers, security codes or banking credentials through chat, email, uploads or support requests.

Stripe's provider certification does not certify Masheev. Merchant PCI DSS scope and validation depend on the complete payment integration and the requirements of the payment processor or acquirer. This policy makes no claim that Masheev holds a PCI certification, SOC 2 report or ISO 27001 certification. Customers must not collect payment card numbers through conversations, calls or uploads (Acceptable Use Policy Section 7.2); payments should be taken through the payment provider's own secure page or link.

11. Reporting Security Issues

We value the contributions of the security research community and encourage responsible disclosure of any security vulnerabilities discovered in our Services.

Responsible Disclosure: If you discover a potential security vulnerability, please report it to us as soon as possible. We ask that you give us reasonable time to investigate and address the issue before making any public disclosure.
Contact: Please report security issues to: security@masheev.com
Security metadata: Our machine-readable disclosure details are available at /.well-known/security.txt.

Scope and safe harbour

This policy covers Masheev-owned production services and applications at masheev.com and its subdomains. Third-party services, customer-managed systems, social engineering, physical attacks, denial-of-service or load testing, automated scanning that degrades the Services, and accessing, modifying, retaining, or deleting another person's data are outside scope.

We will not initiate legal action against researchers who act in good faith, comply with this policy, use only accounts and data they own or have explicit permission to test, stop when they encounter customer data, avoid privacy violations and service disruption, and give us a reasonable opportunity to remediate before publication. This safe-harbour statement does not authorize conduct that violates applicable law or third-party terms, and it does not bind third parties.

What to include in a report

Please include the affected URL or component, a concise description and impact assessment, reproducible steps or a minimal proof of concept, relevant timestamps, and a safe way to contact you. Do not include access tokens, passwords, payment-card data, unnecessary personal data, or copies of customer content. Encrypt sensitive supporting material before sending it and coordinate the transfer method with us first.

Severity and response targets

We classify reports by their demonstrated impact and exploitability:

Critical: Active or readily exploitable compromise causing broad unauthorized access, remote code execution, authentication bypass, or material cross-tenant data exposure.
High: Significant unauthorized access, privilege escalation, or sensitive-data exposure with meaningful prerequisites or limited scope.
Medium: Security impact requiring substantial prerequisites, user interaction, or affecting non-sensitive data or a constrained component.
Low: Defense-in-depth weakness or limited issue with no demonstrated direct compromise.

We target acknowledgment of critical and high reports within 1 business day and all other reports within 3 business days. After validation, we target remediation or an effective mitigation within 7 calendar days for critical findings, within 30 calendar days for high findings, and within 90 calendar days for medium findings. Low findings are prioritized in the normal security backlog. These are operational targets rather than guarantees; a safe resolution may require coordinated vendor or customer work. We will provide the reporter with progress updates when a target changes.

If you have general security questions or concerns, please contact us at security@masheev.com.