Security & Incident Response
Effective: February 22, 2026 | Last updated: February 22, 2026
Attorney Review Pending
This document is in draft form and is subject to legal review. Security practices and procedures are continuously evolving.
1. Security Overview
Aliff Solutions FZC takes the security of client data seriously. As a platform serving government contractors, we understand the sensitivity of the information entrusted to us and implement security measures appropriate to the nature, scope, and purpose of the data we process.
Our security program encompasses the following areas:
- Infrastructure security and network hardening
- Application-level security controls
- Data encryption in transit and at rest
- Access control and authentication
- Multi-tenant data isolation
- Monitoring, logging, and alerting
- Incident response and breach notification
- Vulnerability management and disclosure
2. Infrastructure Security
- Encryption in transit: All connections to the platform are encrypted using TLS 1.2 or higher. We enforce HTTPS on all endpoints and set HTTP Strict Transport Security (HSTS) headers
- Encryption at rest: Data stored in our database and file storage systems is encrypted using AES-256 encryption
- Network security: Our infrastructure is protected by firewall rules (UFW) restricting access to necessary ports only. SSH access requires key-based authentication
- Container isolation: Platform services run in isolated Docker containers with resource limits and network segmentation
- SSL certificates: TLS certificates are automatically provisioned and renewed via Let's Encrypt with no manual intervention
3. Application Security
- Authentication: User authentication is handled through Supabase Auth with support for email/password and social OAuth providers. Passwords are hashed using bcrypt. JWT-based session management with JWKS validation ensures secure authentication flows
- Authorization: Role-based access control (RBAC) with four permission levels (owner, admin, member, viewer) governs what actions users can perform within their organization
- Multi-tenant isolation: PostgreSQL row-level security (RLS) policies enforce organization-scoped data access at the database level. See our OCI Policy for details on information barriers
- Rate limiting: API endpoints are rate-limited using SlowAPI to prevent abuse and denial-of-service attacks
- Security headers: All responses include security headers (Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy)
- Input validation: All API inputs are validated using Pydantic models with strict type checking and constraint enforcement
4. Vulnerability Disclosure Policy
We welcome responsible disclosure of security vulnerabilities. If you discover a potential security issue in our platform, please report it to us promptly.
How to report: Please contact us with the subject "Security Vulnerability Report" and include:
- A detailed description of the vulnerability
- Steps to reproduce the issue
- The potential impact if the vulnerability were exploited
- Any supporting evidence (screenshots, proof-of-concept code)
Our commitment:
- We will acknowledge receipt within 2 business days
- We will provide an initial assessment within 5 business days
- We will not take legal action against researchers who follow responsible disclosure practices
- We will credit researchers (with consent) when vulnerabilities are resolved
Out of scope: Social engineering attacks against our staff, denial-of-service testing, physical security testing, and vulnerabilities in third-party services are outside the scope of this disclosure policy.
5. Incident Classification
Security incidents are classified according to the following severity levels:
| Priority | Description | Response Time |
|---|---|---|
| P1 — Critical | Active data breach, unauthorized access to client data, complete service outage, or compromise of authentication systems | Immediate (1 hour) |
| P2 — High | Exploitable vulnerability discovered, partial service degradation affecting multiple clients, or unauthorized access attempt detected | 4 hours |
| P3 — Medium | Potential vulnerability identified, minor service degradation, suspicious activity detected requiring investigation | 24 hours |
6. Data Breach Notification Procedure
In the event of a confirmed data breach involving personal data or client proprietary information, Aliff Solutions will follow this notification procedure:
- Within 72 hours: Notify affected clients of the breach, including the nature of the breach, categories and approximate number of records affected, likely consequences, and measures taken or proposed to mitigate the breach — in compliance with GDPR Article 33 and our Data Processing Agreement
- Regulatory notification: Where required, notify relevant data protection authorities including the UAE Telecommunications and Digital Government Regulatory Authority (TDRA) and any EU supervisory authorities for affected EEA data subjects
- Data subject notification: If the breach is likely to result in a high risk to the rights and freedoms of natural persons, assist affected clients in notifying data subjects without undue delay (GDPR Article 34)
- Ongoing updates: Provide affected clients with regular status updates during the investigation and remediation process
- Post-incident report: Deliver a comprehensive post-incident report including root cause analysis, impact assessment, remediation actions taken, and preventive measures implemented
7. Forensic and Investigation Process
When a security incident is confirmed or suspected, Aliff Solutions follows a structured investigation process:
- Containment: Immediately isolate affected systems to prevent further unauthorized access or data exfiltration
- Evidence preservation: Preserve logs, system snapshots, and forensic artifacts in a secure, tamper-evident manner
- Investigation: Conduct a thorough investigation to determine the scope, root cause, and impact of the incident
- Remediation: Implement fixes to address the root cause and prevent recurrence
- Lessons learned: Conduct a post-mortem review and update security controls, policies, and procedures as necessary
8. Compliance and Certifications
Aliff Solutions currently implements security controls aligned with industry standards. The following describes our current compliance posture:
- GDPR: Our data processing practices, breach notification procedures, and data subject rights handling comply with GDPR requirements. See our Data Processing Agreement
- UAE PDPL: We comply with UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data
- PCI DSS: Payment card processing is handled entirely by Stripe (PCI DSS Level 1 certified). Aliff Solutions does not store, process, or transmit payment card data
- SOC 2 / FedRAMP: Aliff Solutions does not currently hold SOC 2 or FedRAMP authorization. We do not represent or warrant that the platform meets FedRAMP, FISMA, or CMMC requirements for our own systems. Our CMMC compliance features assist clients in tracking their own compliance posture
We are transparent about the boundaries of our security certifications. If your organization has specific compliance requirements, please contact us to discuss how we can meet your needs.
9. Operational Model & Data Handling
Aliff Solutions operates a cloud-hosted SaaS platform. The following describes our current operational model and data handling practices:
- Data residency: All client data is stored on infrastructure located within the United States, including our primary database (Supabase — AWS us-east-1) and application servers
- AI processing: AI inference requests are processed by third-party AI providers under contractual data protection terms. No client data is used for model training. Prompts and responses are transient and not retained by inference providers beyond the processing window. See our AI Terms of Service and Subprocessors page for details
- Payment processing: All payment card data is processed exclusively by Stripe. Aliff Solutions never stores, processes, or transmits cardholder data. Stripe is PCI DSS Level 1 certified
- Access controls: Production system access is restricted to authorized personnel only. Database access is governed by row-level security (RLS) policies enforcing organization-scoped isolation. Application-level RBAC ensures users can only perform actions appropriate to their role
Controlled Information Restriction
The Aliff Labs platform is not authorized for the processing, storage, or transmission of:
- Controlled Unclassified Information (CUI) as defined by 32 CFR Part 2002
- Classified National Security Information at any level
- International Traffic in Arms Regulations (ITAR) controlled technical data
- Export Administration Regulations (EAR) controlled technical data
Clients are contractually prohibited from uploading controlled information to the platform. See our Terms of Service (Section 5), Acceptable Use Policy, and Export Control Policy for full details.
To report a security concern, vulnerability, or incident, please contact us with the subject line "Security."
Entity: Aliff Solutions FZC, United Arab Emirates