QortexOS Security Overview

This page describes how Qualsis, LLC protects customer data in QortexOS, our multi-tenant platform for managed service providers. It is a plain-English summary of the technical and organizational measures in Annex II of our Data Processing Addendum. The Data Processing Addendum is the binding commitment. Where this page and the Addendum differ, the Addendum controls, and nothing on this page extends it.

This page covers the QortexOS platform. Qualsis's corporate websites and future products are outside its scope.

One rule governs everything below: we state what is deployed and verified, not what we hope to have. Where a practice is still being built, we say so.

Architecture and tenant isolation

QortexOS is a multi-tenant platform, and tenant isolation is the control we invest in most heavily. It is enforced at independent layers, so that no single failure exposes another customer's data:

Application layer. Every data access path runs through repository classes that require tenant context. Application code does not reach the database outside these tenant-scoped repositories.
Database layer. PostgreSQL row-level security policies are enabled and enforced on tenant data tables and applied at every deploy. The database itself scopes every query to the requesting tenant, even if application code misbehaves, and the application connects as a non-superuser account that cannot bypass those policies.
Continuous verification. A dedicated isolation test suite runs on every change, as that same non-superuser database account, and proves that cross-tenant reads, writes, updates, and deletes are denied before code can ship.

Beneath the isolation model, all queries are parameterized, input crossing every input-bearing API boundary is schema-validated before processing, and database triggers reject any write that arrives without an authenticated service-account context, so no write is recorded without attribution.

AI features in QortexOS run on foundation models operated entirely within AWS infrastructure through Amazon Bedrock, AWS's managed foundation-model service, under Qualsis's AWS agreements. On Qualsis's current approved Amazon Bedrock deployment channel and approved models, the model providers do not receive or otherwise process customer data on Qualsis's behalf, and customer data is not used to train models. The full picture is on our subprocessors page.

Encryption

At rest. All customer data is encrypted at rest using AES-256 or equivalent. Storage encryption is on across the platform: the primary database, caches, object storage, secrets, and logs. The customer-data stores are encrypted under keys managed in AWS Key Management Service and separated by infrastructure domain to limit the effect of any single key compromise.
In transit. Traffic between your browser or API client and our load-balancer layer is encrypted with TLS 1.2 or higher, and connections to the database and cache require TLS. Traffic between the load balancer and the application services runs only on private, access-controlled subnets inside our virtual private cloud, with no public network path.
Credentials. Qualsis never stores passwords in plaintext at any layer. Customer authentication is managed by Amazon Cognito, which handles password hashing and verification.

Identity and access

Customer sign-in. Authentication runs on Amazon Cognito with multi-factor authentication required, together with Cognito's risk-based protections against compromised credentials and suspicious sign-in attempts.
Qualsis personnel. Access to production is limited to authorized Qualsis personnel with a business need. It uses named individual identities through AWS IAM Identity Center, requires multi-factor authentication, and runs on short-lived sessions.
No standing network path. There is no bastion host, no VPN, and no public database endpoint. Administrative access to production runs through AWS Systems Manager Session Manager, and administrative sessions are recorded in the audit trail.
Least privilege. Each service has its own IAM role scoped to what it needs. Our build pipeline authenticates through short-lived federated credentials instead of long-lived keys. Root access to the accounts that run the platform is centrally managed through AWS Organizations and reserved for break-glass recovery.
The full access-control commitment set is in Annex II, Section 5 of the Data Processing Addendum.

Monitoring and detection

Threat detection runs continuously across our AWS accounts: Amazon GuardDuty, AWS Security Hub with the AWS Foundational Security Best Practices standard, AWS Config, and VPC Flow Logs, alongside a multi-region AWS CloudTrail audit trail.
Application logging is structured and automatically redacts personal data before log entries are written. Security-relevant events tied to a customer are also recorded in a tenant-scoped audit table protected by the same row-level security model as the rest of that customer's data.
Security and audit logs are retained for at least twelve months, and the cloud audit trail is kept in write-once storage that cannot be altered or deleted during the retention period.
Incidents are triaged under the severity model (P0 through P3) in our incident response process, aligned with the Service Level Schedule.

Vulnerability management

Changes reach our development, staging, and main branches only through pull requests that pass required automated checks.
Dependency vulnerability scanning and automated secret detection run on our code.
Every build workflow action is pinned to a specific commit, protecting the build pipeline against upstream tampering.
All infrastructure is defined as code, and infrastructure changes are scanned for policy violations and misconfigurations.
A web application firewall runs at the network edge in front of the platform.
Qualsis engages qualified third parties for external security testing, including penetration testing, on at least an annual cadence beginning with the first SOC 2 Type II audit cycle.

Incident response

Qualsis maintains a written Incident Response Plan modeled on the NIST SP 800-61 incident-handling lifecycle, with severity levels P0 through P3 aligned to the Service Level Schedule, named roles, and scenario playbooks for the incident types that matter to a multi-tenant platform.

If a personal data breach affects your data, we notify you without undue delay after becoming aware of it. The timing targets, notice content, and follow-up commitments are in Section 10 of the Data Processing Addendum and, for protected health information, Section 5 of the Business Associate Agreement. They are stated there, in one place each, so that they cannot drift.

Communication cadences for availability incidents are in the Service Level Schedule.

Business continuity

The primary database runs on Amazon Aurora across multiple availability zones with automatic failover, and is protected against accidental deletion.
Backups run daily, with continuous transaction-log capture supporting point-in-time recovery. Backups are encrypted and are not used for active processing.
A written disaster-recovery runbook sets recovery time and recovery point objectives for the failure scenarios we plan for, from the loss of a single service to the corruption or loss of the database.
We test restoration from backup at least once a year. The most recent test was completed in August 2026.
Customer data, including backups, stays in the region assigned to your organization at signup, which follows your business location. Today every customer is hosted in the United States.

Data minimisation and benchmark privacy

QortexOS collects only the customer data necessary to deliver the Services, and every input-bearing API boundary validates against a schema before processing. Private peer benchmarking is engineered to prevent participants from being identified: the analytics pipelines enforce minimum cohort sizes, apply differential-privacy noise, and suppress or merge small cohorts before any benchmark output is produced.

Deletion and return of customer data when a subscription ends are described in Section 12 of the Data Processing Addendum.

HIPAA

If you are a HIPAA covered entity or business associate and the data you bring into QortexOS includes protected health information, our Business Associate Agreement applies automatically, on every plan. You accept it with the Terms of Service, and there is nothing to sign. A digitally signed copy is available upon request. Both of our subprocessors are bound to us by business associate terms. HIPAA at Qualsis explains how we handle protected health information and what remains your responsibility.

Personnel security

Access to production systems and customer data is limited to authorized Qualsis personnel who need it for their role. Before any employee or contractor is granted access, the personnel commitments in Annex II, Section 7 of the Data Processing Addendum apply: written confidentiality obligations, background checks to the extent law permits and the role warrants, and data protection and security training.

Shared responsibility

Security in a cloud platform is a division of labor. Ours:

Layer	Responsible party	What that covers
Physical data centers, hardware, and the cloud substrate	AWS	Physical security, hardware, and the managed services beneath QortexOS, under AWS's published controls and independent attestations, which Qualsis reviews and does not re-assert as its own.
The platform	Qualsis	Everything described on this page: application security, tenant isolation, encryption configuration, identity, monitoring, vulnerability management, incident response, and backups.
Your tenant	Customer	Your users and their access roles inside your tenant; the accuracy and lawfulness of the data you connect or upload, including your own role toward the individuals in that data; keeping your administrator contact details current; and your own devices and credentials.

Compliance and attestations

What we hold today. Qualsis does not yet hold a SOC 2 attestation of its own. We state that plainly because in-progress certifications are too often presented as held. What stands behind this page today is the verification discipline described on it, plus the independent attestations of the infrastructure beneath us.

Our attestation path. Qualsis is committed to obtaining and maintaining SOC 2 Type II attestation within twelve months of QortexOS general availability (Data Processing Addendum, Section 6.3). Until then, this security overview and reasonable security documentation are available on request to customers with a legitimate need.

Subprocessor attestations. We completed a documented review of our subprocessors on July 7, 2026, and we keep each provider's independent attestations on file. AWS holds a current SOC 2 Type II report (unqualified opinion, with Amazon Bedrock in scope) and ISO/IEC 27001:2022 certification. Databricks holds a current SOC 3 report (unqualified opinion) and ISO/IEC 27001, 27017, 27018, and 27701 certifications. We review each prospective subprocessor before engaging it, and we repeat the review at least annually and on material changes. These reports are the vendors' confidential information: we can confirm their status, but we do not republish them.

Payment security. Subscription payments are processed by Stripe. Your card data goes directly from your browser to Stripe and never touches QortexOS infrastructure. Stripe holds a current PCI DSS v4 Attestation of Compliance as a service provider. Stripe processes Qualsis's own billing records, not customer data, and is therefore described in our Privacy Policy and not on the subprocessors list.

GDPR. Qualsis processes customer personal data as a processor under the Data Processing Addendum, which incorporates the EU Standard Contractual Clauses (Decision 2021/914) and the UK and Swiss transfer mechanisms described there. The subprocessor list and change-notification mechanism are at https://qualsis.com/legal/trust/subprocessors.

Availability. Availability commitments and service credits for eligible subscription tiers are in the Service Level Schedule.

Reporting a vulnerability

If you believe you have found a security vulnerability in QortexOS or a Qualsis website, tell us through the Qualsis Security contact form, with enough detail for us to reproduce the issue. We will acknowledge your report and keep you informed as we investigate. Please do not include personal data or protected health information in a report.

Contact

Security questions and documentation requests: Qualsis Security contact form. Data protection and HIPAA questions: Qualsis Privacy contact form. Requests for a signed Data Processing Addendum or Business Associate Agreement: Qualsis ESign Request form. Legal notices: Qualsis Legal contact form.

About this version

This is version 1.0.2 of this page. It replaces version 1.0.1. The change is to the Business continuity section: where your data is stored follows the region assigned at signup. The effective date shown below is the date this version started applying. Archived versions and a change log of material updates are kept at https://qualsis.com/legal/trust/changelog.