Security Policy and Trust Center - Zirvo

1. Security Overview

1.1. Security Philosophy

At Zirvo, data security and reliability are not secondary features - they are the operational foundation on which all code is written and deployed. Our architecture assumes external component failures by design and actively works to mitigate and isolate threats autonomously.

1.2. Security Built into the Product

Every feature - from telemetry ingestion to executive SLA reports and integrations - undergoes rigorous security evaluations, minimizing the attack surface and ensuring systemic privacy and logical isolation of customer organizations (tenants).

2. Infrastructure Security

2.1. Next-Generation Cloud Environment

Our main platform is hosted and operated in a redundant, active fashion in high-infrastructure partner data centers, in strict physical and technical compliance with global industrial-scale standards. We do not manage local physical data centers or proprietary server hardware, leveraging the industrial perimeter protections of our cloud providers, under 24/7 physical and electronic security monitoring.

2.2. Infrastructure and Network Segmentation

Our components are logically segmented into strictly structured VPCs (Virtual Private Clouds), with perimeter intrusion protection and dynamic logical firewalls. Systems that process HTTP calls, such as the Zirvo API gateway, reside in protected areas separate from our analytical servers (PostgreSQL databases and high-latency cache management Redis cluster).

3. Application Security

3.1. Secure Development Practices

Zirvo adopts secure application development lifecycle practices aligned with OWASP ASVS milestones. All our Back-End code built on ASP.NET Core and Front-End operated under modern frameworks (Next.js) is designed to prevent top vulnerabilities by design, such as SQL Injections (SQLi), Cross-Site Scripting (XSS), header injections, and authentication logic failures.

3.2. Code Review and Change Auditing

Updates to our ecosystem must pass through an automated dynamic CI/CD compilation pipeline, static code verification (SAST) for dependency vulnerability detection, and database consistency integration tests before packaging. No change is promoted to the production environment without passing documented peer review.

4. Data Protection

We ensure that all data collected from billing or operational telemetry receives heavy cryptographic protection throughout its lifecycle:

• Encryption in Transit: Every request initiated against Zirvo (user browsers, external integration API calls, and webhook alert dispatches) is encapsulated and decoded with the TLS 1.3 cryptographic transport protocol as the strict standard path.
• Encryption at Rest: All PostgreSQL logical metric time-series and configuration history databases feature dynamic encrypted recording using the advanced industrial standard AES-256.
• Customer Credential Protection: Our administrative passwords, corporate seat credentials, and API Keys are converted and stored unidirectionally with Argon2 hashes cryptographically resistant to brute-force attacks.
• Secret Masking and Confidentiality: Our centralized logging systems and corporate pipelines perform automatic log masking to prevent accidental recording of sensitive parameters such as access keys and webhook tokens to plain debug disk.

5. Identity and Access Management

5.1. Authentication and JWT Claims

User identity and authorizations in our interface rely on short-lived JWT (JSON Web Tokens) audited with electronic rotation of encrypted refresh tokens. We validate “sub” type claims for precise identity isolation, preventing forgery abuse and administrative route fluctuations.

5.2. Principle of Least Privilege

We actively enforce the principle of minimum technical privileges: operational staff are granted access only to the systemic areas strictly indispensable for providing support, debugging, and necessary fixes, under audited routines with centralized log records.

6. Monitoring, Detection and Auditing

6.1. Centralized Audit Logs

Zirvo maintains a continuous and immutable internal audit log trail documenting critical administrative actions: complete workspace deletions, API key rotations, account limit changes, and support administrative accesses, maintaining precise history for your corporate organization compliance audit.

6.2. Automated Anomalous Behavior Detection

Our back-end automatically and in real-time evaluates the volumetric patterns and query frequency of tenants against our public APIs. If any call shows systemic anomalies (malicious request spikes characterizing brute-force or technical bypasses), we trigger defensive blocks via Rate Limits and network firewall restrictions adaptively.

7. Vulnerability Management

The robustness of our computational mesh depends on the constant correction and disposal of peripheral software failures:

8. Incident Response

8.1. Network Incident Detection and Response

In the event of confirmed virtual security incidents or imponderable loss of personal data processed in Zirvo, our internal technical team will conduct rigorous actions based on our incident response runbook: immediate logical containment and isolation of logical pods or databases, dedicated investigative triage with detailed records audit, targeted technical mitigation to restore systemic integrity, and timely post-incident communication.

8.2. Notification and Transparency

If the event results in technical record leaks or threatens the technical-financial privacy of your organization, we commit to formally reporting the non-conformity within 48 consecutive business hours of the physical confirmation of the event, providing the customer with crucial telemetry data to support their corresponding obligations before privacy regulators (ANPD/GDPR DPOs).

9. Business Continuity and Resilience

9.1. Active-Active Multi-Region Mesh

Unlike legacy active-passive systems that generate single points of failure, the entire global computational mesh of Zirvo workers and logical probes is based on a multi-region active-active design. If a network partition or serious interruption occurs at a structural data center location, our redundant orchestration asynchronously redirects operating traffic to maintain monitoring stability.

9.2. Data Protection and Backup

Our PostgreSQL time-series databases have rigorous daily policies for recording secured logical copies (Backups) with external custody under digital intrusion control. In Zirvo, write operations are designed to never block reads, ensuring that even in partial internal degradation scenarios, the customer's operational billing and dashboard charts continue to function asynchronously.

10. Operational and Employee Security

We extend compliance principles to the daily operational conduct of our internal technical professionals: all employees are subject to strict formal commercial intellectual data confidentiality agreements (Non-Disclosure Agreements - NDAs) with full civil validity, undergo systematic cybersecurity awareness training, and use logical cloud system access channels authenticated exclusively by encrypted firewalls and multi-factor authentication (MFA) keys.

11. Responsible Disclosure

11.1. Dedicated Security Research Contact

We support good-faith practices and investigations conducted by the global security research community. If you identify or detect any legitimate vulnerability, security breach, or inadequate parameter that could pose a threat to our systems, use our exclusive channel:

11.2. Responsible Disclosure Guidelines

We request that reports be formalized under strict privacy confidentiality until the respective fix by our engineering team, avoiding any leakage or publication of vulnerabilities before we provide the conclusive technical assessment and apply the corresponding systemic mitigation patch across the ecosystem.

12. Shared Customer Responsibilities

Robust shielding and data protection is a two-way street and depends on the correct fulfillment of shared responsibilities by your corporate organization:

• Access Credential Protection: The Customer is solely responsible for the custody, technical confidentiality, and non-improper sharing of their administrative passwords and JWT credentials.
• Seat and Team Control: Strictly keep the registration and logical permissions of workspace channel administrators up to date and immediately deactivate accounts of former employees.
• Compliant Configuration (Fair Use): Abstain from prohibited practices described in our AUP that could improperly force the integrity of our computational mesh or redundant Redis clusters.
• API Updates: Ensure that systems integrated with the Zirvo public API are updated to adapt to evolutions and secure token rotations disclosed in our change reports.