Security

Last updated: October 18, 2026

Hosting and Physical Security

Azethra production workloads are hosted with an established cloud infrastructure provider in a data centre in the United States (Ashburn, Virginia). Physical security of the facility — site access control, environmental monitoring, and power and network redundancy — is operated by the provider under its own security programme.

No Azethra team member has physical access to hosting hardware; hardware maintenance and decommissioning are performed by the hosting provider. Encrypted backups (see Backup and Recovery) are stored off-site in Germany (European Union), separate from the primary servers.

Encryption

Data in transit is protected with TLS 1.2 or TLS 1.3. HTTP Strict Transport Security (HSTS) is enforced, HTTP is redirected to HTTPS, and older protocol versions (TLS 1.0 and 1.1) are rejected.

Backups are encrypted client-side with AES-256 before they leave our servers. The primary database and server disks are not currently encrypted at the disk level; they are protected by the hosting provider’s physical security and by the access controls described below. Secrets (API keys, database credentials, signing keys) are kept outside the application source code, in server-side configuration files readable only by the service account. Passwords are never stored in plaintext; they are hashed with bcrypt.

Access Control

Access to production systems is governed by the principle of least privilege and limited to a small number of named team members. Role-based access control (RBAC) is enforced at the application layer, and the administrative panel requires a named staff account with two-factor authentication. Access is removed when it is no longer needed.

Architecturally, sellers never see the real identity of the artisan fulfilling their orders. This "artisan anonymization" is enforced at the API layer: seller-scoped endpoints return anonymized artisan identifiers only, and operational data (shipping labels, customs paperwork) is generated in a way that prevents sellers from deriving artisan identity. This is a hard platform rule and not a per-tenant configuration.

Authentication

User authentication uses email-based credentials with a password policy requiring at least ten characters, including upper- and lower-case letters, a digit, and a special character. Two-factor authentication and passkeys are available to users, and two-factor authentication is required for internal staff accounts. Sessions use short-lived access tokens with rotating refresh tokens; reuse of an already-used refresh token ends the session, and sessions are ended on logout and after password or two-factor changes.

Third-party integrations (sales channels, payment partners) use OAuth 2.0 or the provider’s API credentials with scoped access; access tokens are refreshed where the platform issues expiring tokens. Webhook receivers validate signatures where the source platform supports them.

Retention and Deletion

We retain personal data only as long as necessary for the purposes for which it was collected, as described in our Privacy Policy, or as required by applicable tax, accounting, or anti-fraud laws (typically up to seven (7) years for financial records under U.S. tax and accounting rules, or longer where required by law). Operational data (logs, error traces, request metadata) is rotated automatically and kept for a limited period, with longer retention for security-investigation purposes on a need-to-know basis.

Users may request deletion of their account and associated personal data by contacting us. Deletion is applied to primary datastores when the request is processed, and to backups as they expire under the backup retention schedule (up to twelve (12) months). Data required for legal retention is access-restricted.

Backup and Recovery

The primary database is backed up daily with a full, consistent copy; continuous point-in-time recovery is not currently enabled, so in a disaster up to one day of changes could be lost. Backups are encrypted client-side with AES-256, stored off-site in Germany (European Union), and kept on a rolling schedule (14 daily, 12 weekly, and 12 monthly copies). Backup success and age are monitored automatically, and we test restoration from these backups.

Product images and documents are stored with a specialised object-storage and content-delivery provider. Service configuration (container and web-server configuration) is kept in source control, so the environment can be rebuilt from source.

Vulnerability Management

Third-party dependencies are updated in response to published security advisories, and operating-system security updates are applied automatically on our servers. Server health (availability, disk, memory, database, backups, and TLS certificates) is monitored continuously with automatic alerts.

An independent third-party penetration test has not yet been completed.

Subprocessors (Category Disclosure)

We engage a small number of carefully vetted subprocessors to deliver the service. To protect operational security and commercial relationships, vendor names are disclosed under non-disclosure in our Data Processing Agreement. At a category level, our subprocessors include:

Each subprocessor processes data under its own data-processing terms. We select subprocessors based on security, compliance, and data-protection criteria.

Incident Response

We maintain a documented incident-response plan with defined roles, severity classifications, and escalation paths. On detection of a suspected security incident, we triage, contain, eradicate, and recover, and conduct a post-incident review. For confirmed personal-data breaches, we notify the competent supervisory authority without undue delay and, where feasible, within seventy-two (72) hours of becoming aware, as required by GDPR Art. 33. Where the breach is likely to result in a high risk to data subjects, we notify affected individuals in accordance with Art. 34.

Controllers using our service will be notified of qualifying breaches in accordance with our Data Processing Agreement. Where other applicable laws (including U.S. state breach-notification statutes) require direct notification of affected individuals or authorities, we comply with those requirements.

Coordinated Vulnerability Disclosure

We welcome reports from security researchers. Vulnerabilities may be reported in confidence to security@azethra.com. We ask researchers to act in good faith, avoid privacy violations and service disruption, refrain from accessing data beyond what is necessary to demonstrate the issue, and give us reasonable time to remediate before public disclosure. Good-faith research conducted under these guidelines will not be pursued as a breach of our Terms of Service.

A formal bug-bounty programme with defined scope and rewards is being established; terms will be published at /security when live.

Compliance Posture

Azethra is a United States company and applies the data-protection laws applicable to its processing, including the EU General Data Protection Regulation (GDPR) and the UK GDPR where we offer goods or services to, or monitor the behaviour of, individuals in those territories (Art. 3(2) GDPR), and the California Consumer Privacy Act (CCPA) for California residents. Our payment partner handles cardholder data under PCI DSS; Azethra itself does not store primary account numbers (PANs) on its systems.

We do not currently hold ISO/IEC 27001 certification or a SOC 2 report. We will publish audit artefacts at /security as they become available. Customers requiring immediate assurance may request our current security-control summary under NDA.

Security Contact

For security concerns, vulnerability reports, or incident inquiries, contact security@azethra.com. For formal data-protection matters, use the contact details set out in our Privacy Policy or Data Processing Agreement.