Security Policy

May 1, 2025

Executive Summary

Streya Technologies Inc. delivers a secure SaaS platform that facilitates controlled data sharing between third-party SaaS ecosystems and authorized consumers. This document outlines our comprehensive security program, designed to protect customer data, maintain system integrity, and alignment with industry standards including SOC 2, GDPR, HIPAA, and Canadian Privacy Laws (e.g., Loi 25).

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

Furthermore, we want business users to fully understand the security measures in place to protect their data:

  • Complete Data Control: You decide exactly what data Streya can access. Only information explicitly selected in your workspace is synced. Any data not specifically chosen remains untouched and inaccessible to our systems.
  • Built-in Privacy Protection: Our platform automatically identifies sensitive fields that may contain Personally Identifiable Information (PII) and enforces appropriate protection methods—anonymization, encryption, or hashing. Raw, unprotected data is never stored in our systems.
  • Regular Independent Verification: Our security architecture undergoes regular third-party audits by certified security experts to validate our compliance with industry standards and ensure we’re following best practices.

This policy applies to all employees, customers, users, partners, and end users 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 (4629 Av. Christophe-Colomb, Montréal, Qc, Canada, H2J 3G7)
  • Employees: Individuals employed by Streya Technologies Inc.
  • Customers: Organizations that use the Streya application
  • Users: Employees of customers who use the Streya application
  • Partners: Organizations that integrate with customer instances of Streya
  • End Users: Employees of partners who interact with 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 Data Classification

Streya processes the following types of information (“Information”), when applicable:

  • Customer Data: Contact information, demographic information, communication history, sales pipeline, account details, and other data provided through Streya’s integrations catalog
  • Transaction Data: Sales records, pricing information, inventory levels, and other data provided through Streya’s integrations catalog
  • Operational Data: Information about business operations, including financial data, employee information, and other data provided through Streya’s integrations catalog
  • Other: Any other data provided through Streya’s integrations catalog

Streya uses reasonable efforts to ensure that Privately Identifiable Information (PII) is properly hashed, encrypted, or anonymized before being stored in the Databases. This is done by identifying which data fields may contain PII, and blocking other transformation types in the UI. The Supplier does not store any Information that has not been explicitly shared by the Customer or the Partner.

2.2 Data Deletion Requests

Customers may request the permanent deletion of all data associated with any integration from Streya’s integrations catalog. 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. 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. All database access requires:

    • Authentication through the secure company VPN
    • 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. Database access logs are maintained and regularly reviewed for unauthorized access attempts.

2.4 Data Encryption

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

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

  3. Encryption keys are managed using a secure key management system with regular rotation and strict access controls.

  4. Personally Identifiable Information (PII) is encrypted, hashed, or anonymized before storage based on data sensitivity and customer preferences.

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

2.5 Data Leakage Prevention

  1. All production database access requires connection through Streya’s secure VPN.

  2. Information exposure in logs and monitoring systems is strictly prohibited. Log content is automatically scanned to prevent sensitive data inclusion.

  3. Unauthorized API requests trigger immediate notifications to the Security Controller who may add unknown IP addresses to the company blacklist.

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

  5. Automated data loss prevention (DLP) tools scan for potential data exposure across company systems.

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

  7. Access attempts to information outside of a user’s authorization scope trigger immediate alerts and access blocking.

3. Access Management

3.1 Authentication Requirements

  1. The Streya platform enforces strong password requirements for all users:

    • Minimum 8 characters
    • Minimum password strength is enforced with a score of 3 or higher
    • No common dictionary words or patterns, powered by HaveIBeenPwned
    • No password reuse for 24 password cycles

  2. Multi-factor authentication (MFA) is required for:

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

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

  4. The platform includes bot and brute force detection with automated blocking of suspicious activity.

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

3.2 Authorization Controls

  1. Role-based access control (RBAC) governs system access, with predefined roles for various user types.

  2. Access to customer data is restricted to authorized users within the customer’s organization and explicitly permitted partners.

  3. Partner access requires explicit authorization from the customer and is limited to the specific data needed.

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

  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 comprehensive 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): Hosting provider (SOC 2 Type 2, HIPAA, CCPA compliant)
    • Nango: API connection management (SOC 2 Type 2, GDPR compliant)
    • Clerk: Authentication services (SOC 2 Type 2, HIPAA, CCPA 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 monthly.

  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. Company visitors must be escorted by authorized employees at all times and their access restricted to appropriate areas.

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

  3. Remote workers must take additional precautions including:

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

  4. 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.

  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. Customer data is backed up daily 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 quarterly 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)

Streya may leverage Artificial Intelligence (AI) and Machine Learning (ML) technologies to enhance platform features, improve security monitoring, and assist in operational processes. All use of AI follows the same security, privacy, and compliance requirements outlined in this policy.

  1. Customer Data Protection

    • Customer data is never used to train or fine-tune AI models unless explicitly authorized in writing by the customer.
    • Any AI processing involving customer data is conducted within Streya’s secure environment and is subject to encryption, access controls, and monitoring.

  2. Third-Party AI Services

    • When AI services from third parties are used, they must meet or exceed Streya’s security standards, including SOC 2 compliance, and sign contractual agreements to safeguard data.

  3. Governance & Oversight

    • All AI use cases are reviewed and approved by the Security Controller to ensure compliance with applicable laws, regulations, and customer agreements.
    • AI-generated outputs are subject to human review before use in decision-making processes that affect customers or their data.

  4. Transparency

    • Customers will be informed if AI technologies materially impact how their data is processed, analyzed, or presented.

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
  • 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 with a single ID to multiple systems
  • TLS: Transport Layer Security - cryptographic protocols designed to provide communications security over a computer network
  • VPN: Virtual Private Network - extends a private network across a public network, enabling secure access to private resources

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

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