Guard retention and deletion policy

Data classes, documented defaults, exports, closure, backup expiry, holds, and verified deletion for Guard.

Last revised: October 23, 2026

This Retention and Deletion Policy ("Policy") sets out the applicable lifecycle rules for Guard Customer Data and associated administrative records. It supplements the DPA for processing on Customer's behalf and the Privacy Policy for Solarius's controller activities, subject to their respective scope and precedence. An instruction to delete a personal identity, remove membership, retire a resource, cancel a subscription, or close an organization shall apply only to its confirmed scope; those instructions are not interchangeable.

Product retention classesCopy link

Each product data class has its own retention rule:

At Organization → Data → Retention, inspect each effective class before changing it. Raw evidence expiry can leave a detection and an evidence reference after the artifact bytes become unavailable. Closing an incident, retiring an asset, or disabling sharing does not erase retained investigation records. See retention, evidence, and holds.

Administrative and legal recordsCopy link

Account and business-contact records remain while needed for the relationship, account security, or a documented legal purpose. Routine support records are reviewed against the case purpose and the applicable support schedule; customer attachments must not be retained indefinitely merely because a ticket exists. Payment and tax records follow applicable accounting retention requirements, which can outlast service termination. Solarius explains the applicable period or legal criterion when responding to a request.

Security and audit records can be retained to investigate abuse, establish accountability, or defend legal claims for a documented, proportionate period. A retained actor address or organization slug can still be personal data. Deletion of a business object is not a justification for keeping every associated log forever. Where product audit records survive purge, they remain access-restricted, subject to review and lawful erasure exceptions rather than unrestricted indefinite use.

Export and ordinary end of serviceCopy link

For an ordinary end of service, Solarius provides a 30-day opportunity after the effective end date to retrieve existing customer data through available exports or a verified support request, unless you instruct earlier deletion, your signed agreement sets another period, or a binding legal requirement prevents access. This is a transition window for retained data, not a promise to keep workloads running, execute new checks, preserve an address allocation, continue active protection, or retain observations beyond their already scheduled expiry.

An explicit earlier organization-closure instruction follows the scope and date confirmed with the authorized owner. Solarius identifies when that instruction shortens the ordinary export opportunity so you can export first. Resource-level deletion and raw-evidence expiry likewise take effect under their own settings rather than being delayed by the general transition window.

At the customer's choice, Solarius returns or delete covered data. After the retrieval window, active-service copies scheduled for end-of-service deletion are removed within 30 days, except for a lawful hold, a customer-requested continuing resource, or an expressly agreed longer schedule. Managed backup remnants expire under the disclosed backup schedule, ordinarily within 90 days after active-service deletion. A longer fixed backup or retention-lock requirement must be disclosed and agreed before relying on it, or explained when later imposed by binding law. These contractual limits do not describe customer-operated or independently exported copies.

Before leaving Guard, export necessary reports and evidence, preserve approved holds, arrange replacement routing and monitoring, and review each active response action. Explicitly release containment or transfer its administration, revoke assessment credentials, retire agent identities, and remove approved access integrations. Agent disconnection or subscription cancellation does not prove a local policy stopped. Do not remove a protected route until the replacement traffic path is ready. See response actions, endpoints, and protected services.

How to request deletion or returnCopy link

An authorized owner can request an organization export or closure through help@solarius.me, identifying the organization, product, data scope, destination or deletion choice, and requested timing. Use the product's linked resource or data-deletion procedures for an individual object. Solarius verifies authority and confirms the scope, effective date, blockers, and consequences. An accepted request is not a completion confirmation.

For individual privacy rights, contact dpo@solarius.me. An employee's account deletion does not generally erase organization-owned evidence or commercial records to which a lawful retention duty applies. Solarius explains any restriction and separates the remaining lawful record from unnecessary identity details when feasible.

Holds, backups, and external copiesCopy link

Any suspension of ordinary deletion for preservation purposes ("Hold") shall have an identified legal obligation or other valid lawful basis, a defined data and time scope, an accountable owner, and a review or expiry condition. The Party requesting a Hold shall establish authority for the request; the label "Hold" does not itself create an exemption from data-protection law. Customer-requested evidence or litigation holds remain subject to the customer's lawful basis; a hold is not a way to avoid privacy obligations indefinitely. Solarius restricts access and use to preservation and the authorized purpose and reviews whether the reason still applies. Releasing a hold makes data eligible for its ordinary lifecycle, not necessarily immediate physical erasure.

Residual backup copies shall be protected against ordinary operational access and use and shall expire in accordance with the documented backup cycle. Restoration shall not reinstate a superseded processing permission: outstanding deletion, restriction, and revocation instructions shall be reapplied before restored data returns to ordinary processing. Shared storage, deduplication, destination locks, and live references can mean removing a visible object is separate from reclaiming physical space. Solarius does not claim that revoking an encryption key proves every independently held plaintext or export was erased.

Customers control self-hosted storage, downloaded packages, external archives, recipients' copies, and providers they independently engage. Solarius cannot recall a public page from another party's archive or destroy a downloaded evidence package on a recipient's machine. Solarius identifies the affected boundary and cooperates within its actual control rather than reporting unsupported completion.

Completion and exceptionsCopy link

Upon an authorized request, Solarius shall provide confirmation identifying the data classes addressed, completed return or deletion actions, outstanding backup expiry, and each retained category with its lawful justification and review or expiry criterion. Receipt or acceptance of an instruction shall not be represented as completion. The DPA's confidentiality, security, and purpose limitations continue for covered data retained after termination. Solarius does not withhold a legally required privacy response because of a billing dispute. Valid resource charges and agreed storage commitments remain governed by the billing policy; retaining a narrow legal record does not by itself justify charging for an entire continuing service.