← Back to home

    Security

    Security at Valerium

    Last updated: 2026-09-13

    This page summarizes the technical and organizational measures Grovic Data applies to protect the Valerium platform, and what our customers are responsible for on their side. It is informational: the contractual allocation of responsibilities is set out in the Terms of Service, and personal data handling in the Privacy Policy.

    On this page

    • 1. Shared responsibility model
    • 2. Encryption
    • 3. Tenant isolation
    • 4. Authentication and access control
    • 5. Application security
    • 6. Logging and monitoring
    • 7. Infrastructure
    • 8. Secure development
    • 9. What customers must do
    • 10. Incident response
    • 11. Responsible vulnerability disclosure
    • 12. Limitations
    • 13. Contact

    1. Shared responsibility model

    We are responsible for the security of the platform: the application, the infrastructure we operate or contract, tenant isolation, encryption, and how our team accesses systems.

    The customer is responsible for how the platform is used: protecting passwords and API keys, enabling multi-factor authentication, deciding who has access and with which role, removing former staff, securing the devices and networks used to log in, the links and exports it shares, and the third-party integrations it connects. Incidents that originate on the customer's side are the customer's responsibility, as set out in section 6 of the Terms of Service.

    2. Encryption

    • In transit: traffic to the platform is served over HTTPS (TLS), with HSTS.
    • At rest: the database and file storage are encrypted at rest by our infrastructure provider. Sensitive integration credentials are additionally encrypted at the application layer before being stored.
    • Passwords: never stored in plain text; they are handled by our authentication provider using strong hashing.

    3. Tenant isolation

    Each organization is logically separated. Access to tenant data is enforced by authorization checks in the API and, for data read with the user's own session, by Row-Level Security policies in the database, so a single faulty check is not meant to be enough to expose another organization's data.

    4. Authentication and access control

    • Multi-factor authentication is available to every account, along with sign-in through Google and Microsoft.
    • Sessions are validated on the server; authorization, input validation and rate limiting are enforced server-side rather than trusted to the browser.
    • Organizations manage roles and permissions for their own members.
    • Access by our personnel to production systems is limited to what is needed to operate and support the Services.

    5. Application security

    • Strict schema validation of inputs, with protections designed against common classes of vulnerability, including broken access control, injection and cross-site scripting.
    • HTML sanitization before rendering user-provided content, and content-based validation of uploaded files.
    • Signature verification of incoming webhooks where the provider supports it, and rate limiting on public endpoints.
    • Supply-chain controls: pinned dependency versions and a quarantine window before newly published package versions can be installed.

    6. Logging and monitoring

    Sensitive operations, such as financial and destructive actions, are recorded in an audit log. Application errors are monitored and alerted on, and access logs are kept for at least 6 months as required by Brazilian law.

    7. Infrastructure

    • Managed PostgreSQL database hosted in the São Paulo, Brazil region, with the backup capabilities offered by our database provider. Customers should keep their own exports of business-critical data.
    • Payments are processed by PCI-DSS compliant providers; full card numbers are not stored on our systems.
    • Our sub-processors are listed in the Privacy Policy.

    8. Secure development

    Changes go through automated checks, including security-focused tests for sensitive endpoints, and periodic security reviews. Issues rated high or critical are prioritized for remediation before release.

    9. What customers must do

    • Enable multi-factor authentication for every member.
    • Use unique, strong passwords and never share accounts.
    • Grant the least access needed, and remove members as soon as they leave.
    • Keep API keys and integration tokens secret, and rotate them if they may have been exposed.
    • Review the permissions of every third-party integration you connect.
    • Treat shared links, customer portals and exports as sensitive, and revoke them when no longer needed.
    • Report suspected account compromise to support@grovicdata.com within 24 hours.

    10. Incident response

    We investigate security events, contain and remediate confirmed incidents, and notify affected customers as described in the Terms of Service and the Privacy Policy. We may suspend an account immediately when that is necessary to contain a threat.

    11. Responsible vulnerability disclosure

    If you believe you have found a vulnerability, email support@grovicdata.com with enough detail to reproduce it. We will not pursue legal action against good-faith research that avoids privacy violations, data destruction and service degradation, does not access or retain data beyond what is needed to demonstrate the issue, and gives us reasonable time to fix it before any disclosure. We do not operate a paid bug bounty program.

    12. Limitations

    No system is completely secure. The measures described here are reviewed and may change over time, and this page is not a warranty or a contractual commitment beyond what the Terms of Service provide.

    13. Contact

    Security: support@grovicdata.com · Privacy: dpo@grovicdata.com.