Guard security, service, and support policy
Security responsibilities, research reporting, operational coverage, maintenance, support, and SLA remedies for Guard.
Last revised: October 23, 2026
This Security, Service and Support Policy ("Policy") forms part of the accepted Guard agreement to the extent incorporated by its Terms of Service. An accepted service-level agreement ("SLA") or support schedule establishes any additional measurable commitment and remedy. The express reasonable-skill-and-care obligation and remedies for uncured material failure remain applicable. An operational target constitutes a binding service-credit commitment only when the accepted SLA expressly gives it that effect.
Security responsibilities
Solarius maintains risk-appropriate authorization, privileged-access, tenant-boundary, vulnerability, change, logging, and contracted recovery controls for components it operates. Customer users, configuration, keys, local hosts, persistence, and independently selected providers remain in their actual operator's scope. Enabling an edge or hosted function adds only its stated processing boundary. SOC monitoring does not grant blanket containment authority. Disruptive response requires the applicable approval or expressly authorized playbook; disconnecting an agent does not prove an applied policy stopped.
An encryption feature is not a claim of universal certification, zero-knowledge architecture, or end-to-end encryption. Required personal-data safeguards and incident duties follow the DPA, including its supplier and transfer provisions.
Research and incident reporting
The Solarius security and bug bounty policy supplies the common reporting, testing authorization, exclusions, reward, disclosure, update, and incident rules. Send vulnerabilities to bugs@solarius.me with minimal redacted proof; do not include credentials or unrelated customer records. Prohibited methods and ineligible reports also apply to Guard.
Active compromise or material operational impact requires help@solarius.me and the purchased urgent channel. Do not wait for research triage. A finding in a customer's workload is distinct from a vulnerability in Guard; customer testing permission does not authorize testing shared Solarius systems.
Product scope and targets
Guard provides 24/7/365 human-reviewed SOC triage of received telemetry under the enabled collaboration and coverage scope. Its operational targets include sub-hour feed refresh, automatic mitigation activation under 60 seconds from detection for admitted protected traffic, weekly automated scanning, quarterly authenticated coverage reviews, and an annual scoped penetration-testing engagement. On-demand testing is separately arranged. These are distinct measurements; none promises complete detection or application restoration.
The DDoS clock starts at Guard detection, not the attacker's first packet. Bypassed edge traffic, unsupported protocols, an unavailable origin, or a disconnected self-hosted collaboration channel can leave a coverage gap. Offline endpoint state and missed scan windows must remain visible as unknown or incomplete rather than being counted as protection success.
Standard support uses the standard queue. Premium has a one-hour initial-response target. Enterprise has a 15-minute initial-response target and 24/7 on-call coverage under the support agreement. These support targets do not replace continuous SOC triage and are not deadlines for containment. Use SOC coverage and escalation.
Request support or escalate an incident
Use help@solarius.me or the support route named in your order. For purchased urgent coverage, use the escalation contact in that agreement rather than relying on an unattended ordinary email thread. Include the organization, product and deployment type, affected resource IDs, UTC start time, observed impact, operation or request references, and a reachable responder. Remove passwords, tokens, and unrelated customer content.
Solarius shall assess and administer support severity by reference to the actual impact and urgency of the reported condition, within the contracted coverage. A production-wide outage or active material security incident takes priority over a cosmetic defect; the assigned severity and any change should be explained. Supply reasonable diagnostic information and provide a person authorized to approve changes. A support request authorizes only the investigation and assistance within its lawful scope. It shall not constitute consent to unrelated destructive operations, expansion of an approved response mandate, or unrestricted access to Customer Data. Additional approval shall be obtained where required by the product permissions or Agreement.
Initial response means a substantive acknowledgement and an assigned next step. It is separate from workaround, containment, remediation, restoration, and root-cause report. A proposed action or successful delivery to an external ticketing system is not evidence that its executor completed it. Solarius communicates material progress, blockers, and next steps within the agreed coverage.
Maintenance and changes
Solarius plans maintenance to reduce disruption, communicates expected material impact through the applicable service channel, and uses reasonable notice for scheduled work. Urgent security, legal, or reliability work can require immediate action and a prompt explanation. Customer approvals and change windows apply to the operations for which the product or agreement requires them.
Solarius does not retrospectively create a maintenance window merely to make an otherwise valid outage claim disappear. A planned retirement of core functionality follows the notice and remedy provisions in the Terms. Optional integrations and third-party components can change independently; Solarius explains material effects on the contracted service and any supported alternative.
Contractual availability and credit claims
A binding availability commitment must identify the covered service and region, measurement point, time zone and interval, successful-service definition, treatment of partial failures and unknown periods, permitted maintenance exclusions, and credit schedule. A customer-generated report or a public status page does not supply these missing contract terms. Solarius does not publish a universal uptime percentage or credit amount for all Guard deployments through this policy.
Where an SLA exists, use its claim process and time limits. Provide the service, period, impact, and available evidence. Solarius compares relevant records and explains acceptance or rejection. Solarius shall not require a report format you could not reasonably obtain. A customer configuration or external-provider failure is excluded only to the extent it actually caused the affected failure under the applicable SLA; it does not excuse an independent service failure by Solarius.
Service credits and other remedies follow the agreement and mandatory law. An SLA credit provision shall not, by implication, exclude statutory data-protection remedies, mandatory rights, or the Agreement's express material-breach remedy. Any exclusive-remedy provision applies only to the extent expressly accepted and legally enforceable. The billing policy distinguishes account credits from cash refunds and prevents duplicate recovery for the same loss.
Customer continuity and assurance
Maintain the backup, alternative communications, routing, and recovery measures appropriate to your business. Tell Solarius about a required recovery point, recovery time, regulated workload, local processing boundary, or additional support need before relying on it. An agreement must confirm a requested additional commitment; a feature setting or sales conversation alone does not establish one.
Security and compliance materials are available through the contracted review process or legal@solarius.me, with reasonable confidentiality. Solarius provides the scope and date of evidence actually held and distinguishes operating controls from independent assurance. A product report is not itself a certification of your organization.