Security Policy

Last Updated: July 2026

This policy is the operating detail beneath the sovereignty model described on /security: three deployment tiers, an orchestration layer that carries the audit envelope, and a model layer that stays swappable. Nothing below overrides that page. Where the two would ever read as inconsistent, /security governs.

---

01. Data Hosting and Residency by Tier

Hosting follows whichever of the three sovereignty tiers the engagement selects: on-premise frontier (infrastructure the principal owns, nothing leaves the principal's perimeter), private enterprise deployment (isolated within the principal's own cloud VPC), or hyperscaler with safeguards (public cloud under signed data-protection agreements, customer-managed encryption keys, and jurisdictional residency controls). The tier is fixed at engagement start and does not shift without the principal's sign-off.

The architecture is designed with alignment to the UAE PDPL, ADGM and DIFC data regimes, Saudi NDMO and NCA requirements for in-Kingdom clients, and EU GDPR as design intent from first build decision, not a retrofit. See /security for the full framework list.

---

02. Encryption and Access Controls

Applied uniformly across all three tiers:

• Encryption in transit using TLS 1.2+ for all data communications.
• Encryption at rest using AES-256 for all stored data, including backups and archives.
• Multi-factor authentication (MFA) enforced for all internal access to systems and client data.
• Least-privilege access controls ensuring team members only access systems and data required for their specific role.

---

03. Monitoring and Vulnerability Management

Maintained continuously at the orchestration layer, regardless of which tier or model sits beneath it:

• Continuous monitoring of all infrastructure, applications, and network traffic for anomalous or unauthorized activity.
• Patch management processes to ensure all systems are updated promptly against known vulnerabilities.
• Regular penetration testing conducted by qualified security professionals to identify and remediate potential weaknesses.

---

04. Incident Response

In the event of a security incident that affects client data, we are committed to prompt and transparent communication:

• Affected customers will be notified within 72 hours of confirmed incident discovery, in accordance with applicable regulations.
• Immediate containment measures will be deployed to minimize impact and prevent further exposure.
• A full post-incident report will be provided, including root cause analysis, scope of impact, and remediation actions taken.

---

05. Vendor and Infrastructure Security

QSA builds and operates on SOC 2-compliant infrastructure, using cloud environments that hold their own SOC 2 Type II and ISO 27001 certifications. Vendor and infrastructure controls are inherited from that certified foundation.

• Vendor contracts include strict data protection clauses, confidentiality obligations, and regular audit rights.
• We conduct periodic reviews of vendor security practices and compliance status.
• Corporate infrastructure partnerships (Google Cloud, Crayon) are named on /board.

---

06. Shared Responsibility

Security is a shared responsibility between QuantumSpirit AI and our clients:

• Our responsibility: We secure the platform, infrastructure, AI systems, and all data processing environments under our control, per the tier selected.
• Client responsibility: Clients are responsible for protecting their own access credentials, managing user permissions within their organization, and reporting any suspected security concerns promptly.

We provide guidance and best-practice recommendations to support clients in maintaining their security posture.