QLIA is a brand and operating name of QuantumLeap IconIQ AInnovations Inc., a corporation registered in Ontario, Canada. Security is a core operating principle, not an afterthought. This document describes how we protect the data entrusted to us, how we respond to incidents, how third parties can report vulnerabilities, and how we maintain compliance with applicable legal and regulatory frameworks.
We provide AI automation and cybersecurity services to small and midsize businesses. The same rigour we apply to client engagements applies to our own systems.
1. Data Security
1.1 Encryption
- All data in transit is encrypted using TLS 1.2 or higher. We enforce TLS 1.3 where supported and reject plaintext HTTP at the edge.
- All data at rest is encrypted using AES-256 or equivalent provider-managed encryption (Supabase/PostgreSQL, Convex, Cloudflare R2).
- Secret values (API keys, credentials, tokens) are never stored in source code, environment files, or configuration commits. All secrets are managed via Bitwarden Secrets Manager (BWS) and injected at runtime.
1.2 Data Classification
- Confidential: Client PII, payment references, authentication tokens, secret keys. Access restricted to system components that strictly require it.
- Internal: Operational metrics, analytics, internal communications. Accessible to authorised personnel only.
- Public: Marketing content, published documentation. No access controls required.
1.3 Data Minimisation
We collect only the data necessary to deliver our services. We do not sell personal information to third parties. Lead data collected through our platform (email, name, company) is used exclusively for the purpose stated at the point of collection.
2. Infrastructure Security
2.1 Edge & Network
- Our web platform is deployed on Cloudflare Workers (edge compute), providing global DDoS mitigation, WAF, and bot management by default.
- HTTP Strict Transport Security (HSTS) is enforced. Insecure HTTP requests are automatically redirected to HTTPS.
- Content Security Policy (CSP) headers are set on all responses to mitigate cross-site scripting (XSS) and injection attacks.
- Rate limiting is applied to all public-facing API endpoints to protect against credential stuffing, scraping, and abuse.
2.2 Cloud Providers
- Cloudflare — edge compute, CDN, DNS, DDoS protection (SOC 2 Type II, ISO 27001 certified).
- Supabase / PostgreSQL — primary relational database; data encrypted at rest and in transit; row-level security enforced.
- Convex — real-time backend; all data encrypted at rest (AES-256); fine-grained access control per function.
- Resend — transactional email delivery; compliant with CAN-SPAM and GDPR.
2.3 Network Segmentation
Production, staging, and development environments are logically separated. Production secrets are never accessible in non-production environments. Database credentials use least-privilege roles — application users cannot modify schema or access tables outside their scope.
3. Application Security
3.1 Secure Development Lifecycle
- All production code is version-controlled in a private GitHub repository and reviewed before merging to main.
- Static Application Security Testing (SAST) is performed weekly using Semgrep across the entire codebase. Critical findings are remediated before the next deployment.
- Dependency versions are pinned and overridden to resolve known CVEs (npm overrides applied in
package.json for transitive dependencies). - Secrets are scanned in CI to prevent accidental commits of credentials.
3.2 Authentication & Authorisation
- Administrative access to our platform uses JWT-based authentication with short-lived tokens. Tokens are signed with a secret never stored in source code.
- All admin operations require a valid, unexpired token. There is no "remember me" functionality for admin accounts.
- Convex backend functions are gated by a shared access key enforced at the function level, preventing unauthenticated access to data operations even if the Convex URL is publicly known.
- Password hashes use bcrypt with an appropriate work factor. Plaintext passwords are never stored or logged.
3.3 Input Validation & Injection Prevention
- All user-supplied input is validated server-side using type checking and schema validation before processing.
- Database queries use parameterised queries via Prisma ORM. Raw SQL is avoided; where used, parameters are always bound, never interpolated.
- Email addresses submitted to public-facing forms are validated and normalised before storage or use.
4. Access Controls & Least Privilege
- Access to production systems is restricted to authorised personnel. No team member has standing access beyond what their role requires.
- All cloud provider access uses API keys scoped to minimum required permissions. Keys are rotated periodically and immediately upon personnel changes.
- GitHub repository access uses branch-protection rules. Direct pushes to
main are restricted; deployments require code review. - Third-party integrations are reviewed before onboarding to ensure they do not receive unnecessary access to user data or production credentials.
5. Vulnerability Disclosure Policy
We welcome responsible disclosure of security vulnerabilities in our systems. If you believe you have found a security issue, please report it privately before public disclosure so we can investigate and remediate.
5.1 How to Report
Send vulnerability reports to contact@qlia.io. Include:
- A description of the vulnerability and its potential impact.
- Steps to reproduce (proof-of-concept, screenshots, or a video).
- Affected URL, endpoint, or component.
- Your contact information for follow-up questions.
5.2 Our Commitments
- We will acknowledge receipt of your report within 2 business days.
- We will provide an initial assessment within 5 business days.
- We will work to remediate confirmed vulnerabilities as quickly as reasonably possible, prioritising by severity.
- We will not pursue legal action against researchers who report in good faith, do not access or modify data beyond what is needed to demonstrate the vulnerability, and allow us reasonable time to remediate before public disclosure.
- With your permission, we will acknowledge you in our security acknowledgements.
5.3 Scope
In scope: qlia.io and all subdomains; QLIA-operated APIs and web applications; QLIA mobile or desktop products (if any).
Out of scope: Third-party services we use but do not control (Cloudflare, Supabase, Convex, GitHub); social engineering attacks targeting QLIA personnel; physical security testing; denial-of-service attacks.
6. Incident Response
6.1 Detection & Containment
Security events are detected through Cloudflare WAF alerts, application monitoring, and Semgrep scanning. Upon detection of a potential incident, we immediately assess scope, contain the affected systems, and preserve forensic evidence.
6.2 Notification
If a security incident results in a data breach affecting personal information, QLIA will notify affected individuals and relevant regulatory authorities as required by applicable law, including:
- PIPEDA (Canada): Within a reasonable time frame when there is a real risk of significant harm to the individual.
- GDPR (EU/EEA): Within 72 hours of becoming aware of a breach likely to result in risk to individuals' rights and freedoms.
- CCPA/CPRA (California): In the most expedient time possible and without unreasonable delay.
6.3 Post-Incident Review
Following any significant security incident, we conduct a blameless post-incident review to identify root cause, improve detection, and prevent recurrence. Changes to controls are implemented within 30 days of the review.
7. Regulatory Compliance
7.1 Applicable Frameworks
- PIPEDA / Bill C-27 (Canada): As a Canadian corporation, QLIA is subject to the Personal Information Protection and Electronic Documents Act and Ontario's privacy legislation. We apply PIPEDA's fair information principles across all data handling activities.
- GDPR (EU/EEA): Where we process personal data of individuals in the European Economic Area, we comply with GDPR requirements including lawful basis for processing, data subject rights, and data transfer safeguards.
- CCPA / CPRA (California): California residents have the right to know, delete, and opt out of the sale of personal information. QLIA does not sell personal information.
- CAN-SPAM / CASL: All commercial electronic messages sent by QLIA include unsubscribe mechanisms and comply with Canada's Anti-Spam Legislation (CASL) and the U.S. CAN-SPAM Act.
7.2 Security Standards
- Our security practices are informed by NIST SP 800-53, CIS Controls, and OWASP Top 10guidelines.
- We do not currently hold a SOC 2 Type II certification. Enterprise clients requiring attestation letters or security questionnaire responses may contact contact@qlia.io.
8. Third-Party & Supply Chain Security
- We evaluate third-party vendors and services before integration, with preference for providers holding recognised security certifications (SOC 2, ISO 27001, or equivalent).
- Open-source dependencies are reviewed for known CVEs. Vulnerable transitive dependencies are overridden in
package.json as security patches. - AI model providers (Anthropic Claude, OpenRouter) process only the data strictly necessary for the requested inference. No client PII is transmitted to AI models without explicit client consent and appropriate contractual protections.
- Data Processing Agreements (DPAs) are in place with vendors that process personal data on our behalf.
9. Data Retention & Deletion
- Lead and contact data is retained for as long as necessary to provide the requested service or fulfil a legitimate business purpose, typically no longer than 36 months from last interaction.
- Individuals may request deletion of their personal data by emailing contact@qlia.io. Deletion requests are processed within 30 days.
- Automated logs and analytics data are purged on a rolling 90-day basis unless required for active investigations.
- Backups are encrypted and retained for a maximum of 90 daysbefore permanent deletion.
10. Personnel Security
- All personnel with access to production systems or client data are required to complete security awareness training.
- Access credentials are unique per person. Shared credentials are not permitted for production systems.
- Access is revoked immediately upon termination of employment or contract.
- Personnel handling sensitive client engagements are subject to background checks in accordance with applicable law.
11. Changes to This Policy
We may update this Security Policy as our practices evolve. Material changes will be reflected with an updated "Last Updated" date at the top of this page. Continued use of our services after an update constitutes acceptance of the revised policy.
12. Contact
For all security enquiries, vulnerability reports, and privacy or data deletion requests:
contact@qlia.io
QuantumLeap IconIQ AInnovations Inc.
Beamsville, Ontario, Canada
qlia.io