Security Policy

June 15, 2026

Executive Summary

Streya Technologies Inc. delivers a secure platform that lets organizations ask business questions of their own data and get decision-ready answers grounded in validated metrics. Streya connects to a Customer’s data warehouse, queries it live with read-only access, and returns answers as cards, charts, and tables in conversations and dashboards. This document outlines our security program, designed to protect customer data, maintain system integrity, and align with industry standards including GDPR and Canadian privacy law (notably Québec’s Loi 25). Streya is currently pursuing SOC 2 certification.

Our approach to security is built on five core principles:

  1. Zero Trust Architecture: We verify every access request regardless of source or location.
  2. Data Privacy by Design: We only collect, store, and process data with clear business justification and appropriate protections.
  3. Least Privilege Access: We grant permissions based on job requirements and regularly review access rights.
  4. Security by Design: We build security controls into our products and services from initial planning through development and deployment.
  5. Continuous Monitoring: We continuously monitor our systems, analyze security data, and rapidly respond to potential threats.

We want business users to fully understand the measures in place to protect their data:

  • Your data stays in your warehouse. Streya queries your data warehouse live with read-only access. It does not copy, ingest, or store your warehouse data. The only data Streya retains on your behalf is your encrypted connection credentials, your semantic model, and the conversations and dashboards you create.
  • You control what Streya can access. Connections are read-only and scoped to your workspace. Through access policies you can restrict columns and rows and mask sensitive values — including masking Personally Identifiable Information (PII) from the AI agent so it can reason over the shape of your data without ever reading raw personal details.
  • Independent verification. Our security architecture is subject to third-party review to validate our controls and alignment with industry standards. Our most recent independent assessment was conducted in 2025.

This policy applies to all employees, customers, users, and partners of the Streya platform. All parties are expected to adhere to these policies as applicable to their role.

1. Governance and Administration

1.1 Parties Involved

This document addresses the security relationship between:

  • Streya Technologies Inc. (“Supplier”): Legal entity incorporated in Canada (6570 Av. de l’Esplanade, Montréal, QC, Canada, H2V 4L5)
  • Employees: Individuals employed by Streya Technologies Inc.
  • Customers: Organizations that use the Streya application
  • Users: Members of a Customer’s organization who use the Streya application

1.2 Security Leadership

Security Controller:
Matthew Bélair, CEO
matthew@streya.app
(514) 291-7424

The Security Controller is responsible for:

  • Overseeing the security program
  • Approving access to sensitive systems
  • Managing the incident response process
  • Ensuring compliance with this security policy
  • Serving as the primary point of contact for security matters

1.3 Policy Enforcement

Violations of this policy may result in:

  • Remedial security awareness training
  • Revocation of system access
  • Disciplinary action up to and including termination of employment
  • Legal action when applicable

All policy enforcement actions will be documented and subject to appropriate review.

2. Data Protection Framework

2.1 What Streya Stores — and What It Does Not

Streya does not copy, ingest, or store Customer warehouse data. The agent queries the Customer’s warehouse live, with read-only access, and only when an answer is required.

The information Streya stores on a Customer’s behalf is limited to:

  • Connection credentials — encrypted and held in a dedicated secrets manager (AWS). Used only to run read-only queries against the Customer’s warehouse.
  • Semantic model — the Customer’s metric and dataset definitions (cubes, views, descriptions).
  • Conversations and dashboards — the answers and visuals created in a workspace, which may include query results returned by the warehouse.

Customers control what the Service can access. Connections are read-only and scoped to a single workspace. Access policies allow Customers to restrict columns (member-level security), restrict rows (row-level security), and mask values. The canonical use of masking is PII: sensitive columns can be hidden from the AI agent so it reasons over the shape of the data without ever reading raw personal details, while authorized users may still see the real values.

2.2 Data Deletion Requests

Customers may request the permanent deletion of the data associated with a connection — including its semantic model, conversations, and dashboards. Upon receiving such a request, Streya will remove the specified data from all active systems and backups within legally permissible timelines, subject to any applicable regulatory or contractual retention requirements. Because warehouse data is never stored by Streya, deleting a connection also ends Streya’s access to the underlying data. Deletion actions are logged and verified by the Security Controller.

2.3 Data Access Controls

  1. Streya implements access controls based on the principle of least privilege. Employees are granted only the access necessary to perform their job functions.

  2. Administrative access to production systems requires:

    • Multi-factor authentication (MFA)
    • Explicit approval from the Security Controller
    • Business justification

  3. Access rights to production systems are reviewed quarterly to ensure they remain appropriate.

  4. Access to sensitive systems is automatically revoked when an employee’s status changes (e.g., termination, role change).

  5. Access logs are maintained and regularly reviewed for unauthorized access attempts.

2.4 Data Encryption

  1. All data at rest is encrypted using industry-standard AES-256 encryption.

  2. All data in transit is encrypted using TLS 1.2 or higher.

  3. Connection credentials are encrypted and stored in a dedicated secrets manager with strict access controls and key rotation.

  4. Personally Identifiable Information (PII) in Customer Data can be masked from the AI agent and from unauthorized users through access policies, based on data sensitivity and Customer configuration.

  5. The encryption implementation is reviewed annually by qualified security professionals.

2.5 Data Leakage Prevention

  1. Information exposure in logs and monitoring systems is strictly prohibited. Log content is managed to prevent inclusion of sensitive data.

  2. Unauthorized or anomalous API activity triggers alerts to the Security Controller, who may block offending IP addresses.

  3. After repeated failed login attempts, user accounts are automatically locked and the Security Controller is notified.

  4. Regular penetration testing and vulnerability scanning verify the effectiveness of data protection controls.

  5. Access attempts to data outside a user’s authorization scope are blocked and trigger alerts.

3. Access Management

3.1 Authentication Requirements

User authentication is provided by Clerk. The platform enforces:

  1. Strong password requirements for all users:

    • Minimum 8 characters
    • Minimum password strength enforced
    • Rejection of compromised passwords, checked against known breach databases (e.g. HaveIBeenPwned)

  2. Multi-factor authentication (MFA) for:

    • All employee access to company systems
    • Customer administrative accounts
    • Access to sensitive data or functions

  3. Single Sign-On (SSO) integration, available and recommended for enterprise customers.

  4. Bot and brute-force detection with automated blocking of suspicious activity.

  5. Password-leak protection that alerts users if their credentials appear in known breach databases.

3.2 Authorization Controls

  1. Role-based access control (RBAC) governs system access. Access is organized at two levels — the organization and the workspace — with predefined roles for each.

  2. Access to a workspace’s data and the answers within it is restricted to authorized users within the Customer’s organization.

  3. Access policies enforce column-level security, row-level security, and data masking within a workspace.

  4. Access attempts outside a user’s authorized scope are blocked and trigger alerts.

  5. Privileged account access is limited to essential personnel and subject to enhanced monitoring.

4. Third-Party Risk Management

4.1 Subprocessor Evaluation

  1. All subprocessors undergo a security assessment before engagement, including:

    • Review of security certifications (SOC 2, ISO 27001, etc.)
    • Evaluation of data protection policies and capabilities
    • Assessment of incident response procedures
    • Verification of compliance with applicable laws and regulations

  2. Subprocessors must meet or exceed Streya’s security requirements and contractually commit to maintaining these standards.

  3. Current subprocessors include:

    • Amazon Web Services (AWS): Cloud hosting and secrets management, in the Canada Central region (ca-central-1) (SOC 2 Type 2, ISO 27001 compliant).
    • Anthropic: Large language models (Claude) that power the Streya agent. Under Anthropic’s Commercial Terms of Service — which govern Streya’s API use and include a Data Processing Addendum — Anthropic does not train its models on inputs or outputs submitted through its API.
    • Clerk: Authentication services (SOC 2 Type 2 compliant).

4.2 Ongoing Subprocessor Management

  1. All subprocessors are formally reviewed at least annually to verify continued compliance.

  2. Customers are notified 30 days in advance of any material changes to subprocessor relationships.

  3. Subprocessors are contractually obligated to report security incidents that may affect customer data.

  4. A current list of subprocessors is maintained and available to customers upon request.

5. Personnel Security

5.1 Employee Obligations

  1. All employees must complete security awareness training:

    • Upon hiring
    • Annually thereafter
    • Following significant security policy changes

  2. Employees must activate and use MFA on all company and third-party systems. The Security Controller verifies compliance periodically.

  3. Employees must maintain a “clean desk” policy, ensuring that:

    • Computers are locked when unattended
    • Sensitive information is not left visible
    • Mobile devices are secured when not in use

  4. Strong, unique passwords must be used for all company systems in accordance with the Authentication Requirements section.

  5. Background checks are conducted for all employees before being granted access to sensitive systems or data.

5.2 Secure Work Practices

  1. Information sharing is restricted to company-approved systems and communication channels.

  2. Remote workers must take additional precautions including:

    • Working in private locations
    • Securing devices when not in use
    • Using only approved devices for accessing company systems

  3. Employees must immediately report security concerns to the Security Controller, including:

    • Lost or stolen devices
    • Suspected data breaches
    • Potential policy violations
    • Security vulnerabilities

5.3 Termination Procedures

  1. Terminated employees must:

    • Return all company equipment
    • Return all documents containing sensitive information
    • Have all system access revoked immediately

  2. Legal obligations regarding confidentiality survive termination of employment.

6. Incident Response

6.1 Incident Categories

Security incidents are classified as:

  • Critical: Confirmed data breach, system compromise, or other event with significant business impact
  • Major: Suspected data exposure, significant system disruption, or advanced persistent threat activity
  • Minor: Isolated policy violation, contained malware, or other limited-scope event

6.2 Incident Response Process

  1. Detection and Reporting: All employees must immediately report suspected security incidents to the Security Controller.

  2. Assessment and Classification: The Security Controller will assess and classify reported incidents.

  3. Containment: Immediate actions will be taken to contain the incident and prevent further damage.

  4. Investigation: A thorough investigation will be conducted to determine scope and impact.

  5. Remediation: Actions will be taken to address the root cause and prevent recurrence.

  6. Notification: Affected parties will be notified in accordance with contractual obligations and regulatory requirements, including breach-notification obligations under applicable privacy laws (such as Loi 25 and GDPR).

  7. Documentation: All incidents and response actions will be thoroughly documented.

7. Compliance and Audit

7.1 Security Assessments

  1. Streya conducts regular security assessments including:

    • Annual penetration testing
    • Quarterly vulnerability scanning
    • Continuous automated security monitoring
    • Regular code security reviews

  2. Results of security assessments are reviewed by the Security Controller and addressed according to risk level.

8. Business Continuity

8.1 Data Backup and Recovery

  1. The data Streya stores (credentials, semantic models, conversations, and dashboards) is backed up regularly, with retention according to data classification requirements.

  2. Backup systems are encrypted and subject to the same security controls as production systems.

  3. Backup restoration is tested periodically to ensure recoverability.

8.2 Disaster Recovery

  1. Streya maintains disaster recovery capabilities designed to:

    • Resume critical operations within 4 hours
    • Restore full service within 24 hours
    • Prevent data loss through redundant systems

  2. The disaster recovery plan is tested annually and updated as needed.

9. Use of Artificial Intelligence (AI)

Artificial intelligence is core to the Streya platform: the Streya agent uses large language models to interpret questions, plan queries, and explain results. All use of AI follows the security, privacy, and compliance requirements outlined in this policy.

  1. What is sent to the model. To answer a question, Streya may send the agent the user’s question text, semantic-model metadata (such as table, dimension, and measure definitions), and query results returned by the Customer’s warehouse. Sensitive fields can be masked from the agent through access policies.

  2. Provider. The Streya agent is powered by models from Anthropic (Claude), accessed through Anthropic’s API under its Commercial Terms of Service.

  3. No training on Customer Data. Customer Data is never used to train or fine-tune AI models. Under Anthropic’s Commercial Terms of Service — which govern Streya’s API use and include a Data Processing Addendum — Anthropic does not train its models on inputs or outputs submitted through its API.

  4. Governance & oversight. AI use cases are reviewed and approved by the Security Controller to ensure compliance with applicable laws, regulations, and customer agreements.

  5. Transparency. Because AI is integral to the Service, Customers are informed of how their data is processed by the agent through this policy and the Data Processing Addendum.

10. Policy Management

10.1 Policy Review

This policy will be reviewed:

  • At least annually
  • Following significant security incidents
  • When required by changes in business practices or regulations

Glossary

  • AES-256: Advanced Encryption Standard with 256-bit key length, a strong encryption algorithm used to protect data
  • MFA: Multi-Factor Authentication — requiring two or more verification methods to grant access
  • PII: Personally Identifiable Information — data that can be used to identify an individual
  • RBAC: Role-Based Access Control — restricting system access based on the roles of individual users
  • Semantic model: The layer that defines what a Customer’s data means — which tables matter, how they join, and how metrics are computed — so every answer uses the same approved definitions
  • SOC 2: Service Organization Control 2 — an auditing standard for service organizations
  • SSO: Single Sign-On — an authentication scheme that allows a user to log in once to access multiple systems
  • TLS: Transport Layer Security — cryptographic protocols that provide communications security over a network

For any questions regarding this document, please contact the Security Controller.

Matthew Bélair, CEO
matthew@streya.app
(514) 291-7424