Purpose
This document is a high-level summary of how Velaris Management Group LLC (“Xive”) protects data processed through the Services: where it generally lives, how access is controlled, and how we detect and respond to risk. It is meant for users, creators, and auditors who need orientation—not a full control matrix, architecture diagram, or penetration-test report.
- What we collect, legal bases, and international transfers are described in our Privacy Policy; how long we keep categories of data is in our Data Retention Policy.
- How we handle confirmed security incidents is summarized in our Incident Response overview.
- Detailed technical evidence, SOC-style control descriptions, and customer-specific assurances are shared under NDA for enterprise and regulatory engagements when we offer them.
Infrastructure and environment separation
We rely on established cloud and infrastructure providers that contract for baseline security, availability, and subprocessors appropriate to our workloads.
- Production workloads are separated from non-production (development, staging, test) environments where practicable, to reduce the chance of test data or debug tools touching live user data.
- Secrets, API keys, and signing material are stored in secure configuration systems—not hard-coded in client applications or public repositories.
- Network boundaries and service accounts are tightened so that only components that need a datastore or queue can reach it.
Encryption in transit and at rest
We use industry-standard protections so data is less exposed when it moves across the internet or sits on disk.
- In transit: connections between clients and our services use TLS (or equivalent) where the product stack supports it.
- At rest: encryption is often provided by the underlying cloud storage, database, or object store, sometimes layered with application-level controls depending on the dataset.
- Exact algorithms and key-management details vary by component; we align them with vendor guidance and our threat model rather than publishing a single static recipe here.
Access control and least privilege
Human and automated access to production systems and customer content is limited to what a role needs to do its job.
- Role-based access, break-glass procedures where used, and strong authentication—including multi-factor authentication (MFA) for privileged administrative accounts where we require it.
- Database policies such as row-level security, plus application-layer checks, reduce the risk of one customer’s data being exposed to another’s session.
- Employee and contractor access is tied to employment or contract status and is reviewed or revoked when roles change.
Logging, monitoring, and retention
We generate and review security-relevant telemetry to spot abuse, misconfiguration, and suspected breaches.
- Security logs are protected from casual tampering and are retained for periods consistent with our Data Retention Policy and legal obligations.
- Monitoring feeds alerting, on-call response, and post-incident review; not every event triggers a human ticket—noise is tuned where possible.
- We avoid logging more personal data than necessary to investigate an issue.
Vulnerability management and secure development
Security is treated as an ongoing practice, not a one-time gate before launch.
- Dependencies and container images are tracked; critical patches are prioritized when advisories affect production code paths.
- Automated checks in continuous integration (where configured) catch known classes of defects before merge or deploy.
- Independent researchers and customers may report vulnerabilities through the security contact we publish in the Service; coordinated disclosure helps us fix issues before they are widely exploited.
Vendor and subprocessors
We do not run every subsystem ourselves. Material subprocessors are reviewed for security and privacy posture and bound by contract.
- Categories of providers and how we govern them are described in our Third-Party Vendors policy.
- We expect vendors to notify us of breaches affecting our data according to their agreements and applicable law.
Contact
To report a security vulnerability, use the security contact published in the Service (for example, help or security disclosure pages). If no dedicated channel is listed, email [email protected] with enough detail to reproduce or scope the issue without including live user passwords.