Security

Last updated: Jul 18, 2026 · Security contact: security@domainstabilizer.com · Urgent incidents: support@domainstabilizer.com

At Domain Stabilizer, security is a priority. This page summarizes how we protect your data, how we respond to incidents, and how to report vulnerabilities responsibly.

1) Model and scope

100% SaaS: cloud‑hosted, multi‑tenant, agentless.

Data processed: domains/URLs, technical metadata for DNS/DMARC/SPF/DKIM/SSL/uptime, account settings, contact email, and usage telemetry (see our Privacy Policy).

Payments: handled by Paddle (Merchant of Record). We do not store or process card data; Paddle processes payment details under its own PCI-DSS compliant infrastructure.

Shared responsibility: we secure the platform; you secure your credentials, email access, and correct configuration of your domains/services.

2) Data protection

Encryption in transit: TLS is used for public traffic and database connections. HSTS is enabled on the main public site and production subdomains. Encryption at rest: our primary database is Neon Postgres. Neon encrypts customer data at rest using AES-256 and requires TLS for database connections. Key management: database key management is handled by our managed database provider. We do not currently use customer-managed keys or a dedicated HSM. Logical isolation: customer accounts and workspaces are separated at the application and database levels. Backups and restore: the database supports point-in-time restore and provider-managed backup/restore capabilities according to the active Neon plan and configuration. VPS/server recovery depends on provider snapshots and operational backups configured for the production environment. A full-service restore drill has not yet been formally validated.

3) Access governance

We follow the principle of least privilege. Production access is via SSH restricted to authorized keys. MFA is enabled on provider, source-control, and administrative accounts used to manage the infrastructure where supported. Direct MFA enforcement at the SSH session level is not currently implemented. Development and production environments are separated. Operational logs include request IDs to support troubleshooting and incident review.

4) Secure development (SDL)

Dependency review for known issues. Secrets are kept out of the source repository (environment configuration). Incoming payment webhooks are verified by HMAC signature before any database write. Feature flags and a read-only mode for controlled changes. Unit and integration tests in critical areas (e.g., alert dedupe, uptime runner).

5) Vulnerability management

We apply operating-system and dependency updates and review security advisories for the packages we use. Maintenance windows are announced when impactful. We do not currently perform formal penetration testing, and we are not SOC 2 or ISO certified.

6) Availability and continuity

Stateless design where possible; background workers use CAS locks and retries. Operational objective (non‑contractual, pending formal validation via a restore drill): RPO/RTO of ≤ 24h for major incidents. Health monitoring, rate‑limits, and back‑pressure to protect the platform.

7) Retention and deletion

We retain personal data only as long as necessary: account data while your account is active and for a reasonable period after closure; security logs typically 30–180 days; purchase records as required by tax law (via Paddle). We delete or anonymize data upon account closure or request, subject to minimum legal/anti‑fraud preservation. See our Privacy Policy for details.

8) Subprocessors

We use providers with appropriate contractual and technical safeguards: cloud infrastructure (our VPS host and the Neon database), transactional email, and Paddle (payments, billing and taxes). The list may change; we will notify material changes in-app or via email when applicable.

For more information about data processing and subprocessors, see our Privacy Policy.

9) Incident management

Detection and classification; containment and eradication (key rotation, hotfixes, feature flags); notification to affected customers without undue delay and, when applicable, within 72h (e.g., GDPR); lessons learned and preventive measures. Notices include scope, data affected, actions taken, and recommendations.

10) Responsible vulnerability disclosure

We appreciate security reports. Email: security@domainstabilizer.com (optionally include PoC and repro steps). Please DO NOT: perform DoS, massive brute‑force, ransomware, social engineering, or exfiltrate real data. DO: limit tests to your own account/resources, avoid harming availability, and respect privacy. Safe‑harbor: we won’t take legal action for good‑faith research that follows these guidelines. No public bug bounty as of today; we may credit you in a Hall of Fame if you authorize it.

11) Customer controls (best practices)

Protect your email account with two-factor authentication, use unique passwords where applicable, review who receives your alerts, and restrict access in your own firewalls, DNS, hosting, and email systems where appropriate.

12) Compliance

GDPR/LGPD: we act as the data controller for the personal data we process to provide the Service, as described in our Privacy Policy. Payments: delegated to Paddle (PCI-DSS under their scope). We are not SOC 2 or ISO 27001 certified.

13) Changes and contact

We may update this page. We will publish the current version and date. For security questions or requests, contact: security@domainstabilizer.com

Related documents: Terms of Service · Privacy Policy · Refund Policy