Privacy policy
This policy explains what ServerGuard ("SGuard", "we") collects, why, and what you can do about it. It covers the marketing site at sguard.ai and the application at app.sguard.ai. Plain language; no legalese where we can avoid it. A lawyer is reviewing this text before launch — anything material may change between this draft and the published version.
Last updated: TBD — set on publish
Who we are and how to reach us
ServerGuard is the controller for the personal data described here. General privacy questions go to privacy@sguard.ai. Security-sensitive contact (suspected breach, vulnerability reports, abuse) goes to security@sguard.ai. Postal address: [TBD — founder to fill]. We do not currently have a separate Data Protection Officer; the founder is the responsible contact.
What this policy covers
Two distinct surfaces: (1) the marketing site at sguard.ai, including the waitlist signup and blog. (2) the application at app.sguard.ai once it ships, where customers connect their cPanel/WHM servers for monitoring and remediation. Both surfaces are operated by ServerGuard. Each section below states which surface it applies to where the distinction matters.
What we collect
Marketing site (waitlist form): email and optional details you provide (name, role, locale, referring campaign parameters). Application (when active): account information you provide (name, email, organisation name), server configuration you enter (hostnames, SSH ports, the encrypted SSH private keys we store on your behalf), incident data generated by monitoring (alerts, diagnoses, command outputs, audit log entries), and membership/role data within your organisation. Automatically collected on both surfaces: IP address (used transiently for rate limiting and routing), user agent string, and, only after you accept the cookie banner, analytics events on the marketing site. We do not collect payment card numbers; when paid plans launch, our payment processor handles card details directly.
How we use it
Service delivery: account data and server configuration are used to monitor your servers, run diagnostics, and execute approved remediation actions per the risk-classification framework described in the spec. Security and abuse prevention: IP addresses, user agents, and audit log entries are used to detect rate-limit violations, suspicious access patterns, and to investigate incidents. Communication: waitlist email addresses receive a confirmation when you sign up and product launch news when there is something to share — no marketing drip. Account email addresses receive transactional emails (approval requests, incident notifications, billing receipts once billing ships). Analytics: aggregated, consent-gated Google Analytics 4 events on the marketing site help us understand which pages perform. We do not use analytics on the application. Legal compliance: where required, we retain records (e.g. for tax/accounting once billing ships) for the statutory period. We do not use customer server data, command outputs, or diagnosis content to train AI models — see the AI processing section below.
Legal bases (GDPR and Saudi PDPL)
Under GDPR Art. 6, the lawful bases we rely on are: contract performance (everything required to deliver the application to customers — account, server configuration, monitoring, remediation); legitimate interests (security, abuse prevention, fraud detection, basic transactional communication to customers); consent (analytics cookies, optional marketing emails); and legal obligation (tax, accounting, and any response to lawful authority requests). Where Saudi PDPL applies, equivalent grounds apply. Where we rely on consent, you can withdraw it at any time without affecting the lawfulness of processing before withdrawal. Lawyer will refine this section.
Who we share with (sub-processors)
We share personal data only with sub-processors who help us deliver the service, and only the data they need. We use sub-processors in the following categories: hosting and infrastructure (for the marketing site and the application backend, including managed database), AI processing (for incident diagnosis), transactional email delivery, analytics (marketing site only, consent-gated), and, once paid plans launch, payment processing. A current list of named sub-processors is available on request. We will update customers before adding a new category of sub-processor that touches customer data.
AI processing (Anthropic / Claude)
When the application investigates an incident, the relevant context — redacted log excerpts, sanitised command output, the server's plan tier and OS metadata — is sent to Anthropic's Claude API to produce a diagnosis and propose remediation. We do not send SSH private keys, passwords, customer credentials, or full filesystem dumps. The structured-output redaction layer runs before the data leaves our backend, and the same redaction is mirrored in the audit log. Per Anthropic's API data-handling policy at the time of writing, content sent through the Claude API is not used to train Anthropic's models. We re-verify this against Anthropic's current legal terms (anthropic.com/legal) before each material policy update. If you object to AI processing of incident data on your servers, the application will not work for you — that processing is the core of the service.
International transfers
Data may be processed in multiple jurisdictions, including the European Union and the United States. Where personal data leaves your region of residence, we rely on the appropriate transfer mechanism — Standard Contractual Clauses for EU/UK transfers, and the equivalent under Saudi PDPL where applicable. The specific sub-processors and processing locations are listed on request.
How long we retain data
Application — incident history retention follows the plan tier: Starter 30 days, Pro 90 days, Agency 1 year. After the retention window, incident data is deleted; audit log entries are retained for the same period as the related incident. Account and organisation records are retained for the lifetime of the account and for 30 days after termination, after which they are deleted unless we are required to retain them for tax or legal reasons. Encrypted SSH keys are deleted within 24 hours of a server being removed from an organisation. Marketing site — waitlist signups are retained until you ask us to delete them, or for up to 2 years post-launch if you never become a customer, whichever comes first. Server-side logs (rate-limit counters, request logs) are retained for up to 30 days. Lawyer will refine the specific windows and confirm the tax-retention period.
Your rights
Subject to GDPR and Saudi PDPL, you have rights of access (a copy of the personal data we hold), rectification (correction of inaccurate data), deletion ("the right to be forgotten", subject to lawful exceptions), restriction of processing, portability (a machine-readable export of the data you provided), objection (including objection to processing based on our legitimate interests), and withdrawal of consent for anything we relied on consent for. To exercise any of these rights, email privacy@sguard.ai with enough detail to identify your account. We respond within 30 days. There is no fee for the first request in a given period; abusive or repetitive requests may be declined or charged a reasonable fee. You also have the right to complain to a supervisory authority — in the EU your national data protection authority; in Saudi Arabia, SDAIA.
Children
ServerGuard is not directed at and is not intended for use by anyone under 18. We do not knowingly collect personal data from children. If you believe a child has provided us with personal data, email privacy@sguard.ai and we will delete it.
Security
Our security posture is described in detail on the Security page (sguard.ai/security). Highlights: SSH private keys are encrypted at rest with AES-256-GCM; all transport is TLS 1.2+; every command we execute on customer servers is logged to an INSERT-only audit log with secrets redacted before write; destructive actions never auto-execute and require human approval. We do not yet claim SOC 2 or ISO 27001 certification — we will only claim certifications once they are awarded.
Breach notification
If we become aware of a personal data breach that is likely to result in a risk to your rights and freedoms, we will notify the relevant supervisory authority within 72 hours of awareness, and we will notify affected customers without undue delay where the risk is high. The notification will describe the nature of the breach, the data affected, the likely consequences, and the measures we have taken.
Changes to this policy
We will update this policy when our practices change. Material changes will be notified to customers by email before they take effect; non-material changes will be reflected by updating the "last updated" date above. The current version is always the one published at this URL.
Contact
Privacy questions: privacy@sguard.ai. Security questions or breach reports: security@sguard.ai. For anything else: hello@sguard.ai.