Security and Trust
How QLAC protects data, projects, reports, and access without claiming certifications it has not obtained or promising zero risk.
Last updated: 2026-05-11
1. Security principle
QLAC is designed to handle technical project information with separation between internal console and Client Portal, role permissions, ownership validation, and traceability for sensitive actions.
2. Access and isolation
- Backoffice reserved for authorized internal profiles.
- Client Portal separated by routes, layouts, policies, and filtered data.
- Clients should only see projects, reports, documents, and evidence authorized for their tenant.
- Private downloads through authorized controllers without exposing real storage paths.
3. Files, repositories, and evidence
ZIPs and project files are treated as untrusted. QLAC validates format, size, dangerous paths, symlinks, nested archives, and private storage. Client flows do not execute uploaded code.
GitHub and GitLab, when available, should use explicit consent, minimal permissions, encrypted tokens, and visible revocation.
4. Audits and limits
Lighthouse runs with SSRF validation, queues, timeouts, and private artifact storage. Results are lab data and labeled as such. QLAC does not present Lighthouse as certification or direct real INP measurement.
5. Billing and payment data
Paddle acts as payment provider when checkout is active. QLAC stores states, plans, events, and references required for subscription management, but does not store card or bank details.
6. Transparency
QLAC communicates reasonable measures, limitations, and responsibilities. It does not claim ISO 27001, SOC 2, OWASP certified, NIST certified, or absolute security unless a real and verifiable certification exists.