Security

Security Policy

Last Updated: April 15, 2026

1. Our Security Commitment

At Cognitia, security is a foundational principle. We are committed to protecting the confidentiality, integrity, and availability of your data and our platform.

Current Development Stage: Cognitia is in active development phase. We have implemented foundational security controls and are continuously working toward enterprise-grade security features and formal certifications. This document outlines both our current security posture and our security roadmap.

Security is a shared responsibility. While we implement security controls at the platform level, your organization must also implement appropriate security practices for accessing and using our Services.

2. Security Framework and Compliance

2.1 Current Implementation

Our current security program includes:

  • OWASP Guidelines: Following OWASP Top 10 secure development practices
  • Cloud Security: Leveraging security features of our cloud infrastructure providers
  • Data Protection: Implementing controls for data privacy and security
  • Authentication: Secure authentication and access control mechanisms

2.2 Security Roadmap

We are working toward formal certifications and advanced security frameworks:

  • SOC 2 Type II: Planning for independent audit of security controls
  • ISO 27001: Information Security Management System certification on roadmap
  • GDPR & CCPA: Implementing compliance with data protection regulations
  • Third-Party Audits: Annual penetration testing and vulnerability assessments planned
  • NIST Framework: Aligning with cybersecurity framework principles

2.3 Industry-Specific Compliance

As we mature, we plan to support customers in regulated industries with:

  • HIPAA: Business Associate Agreements (BAAs) for healthcare data
  • PCI-DSS: Payment card data handling through certified processors
  • Industry Standards: Additional compliance frameworks as needed

3. Data Protection

3.1 Encryption

Data in Transit:

  • TLS 1.3 (minimum TLS 1.2) for all data transmission
  • Perfect Forward Secrecy (PFS) enabled
  • Strong cipher suites only (AES-256-GCM, ChaCha20-Poly1305)
  • HTTP Strict Transport Security (HSTS) enforced
  • Certificate pinning for mobile and desktop applications
  • API communications encrypted end-to-end

Data at Rest:

  • AES-256 encryption for all stored data (database, file storage, backups)
  • Separate encryption keys per customer (tenant isolation)
  • Hardware Security Module (HSM) or cloud KMS for key management
  • Encrypted database columns for sensitive PII and credentials
  • Encrypted disk volumes and object storage
  • Secure key rotation procedures (90-day rotation cycle)

3.2 Data Isolation and Segmentation

  • Logical Separation: Each customer's data is logically isolated in multi-tenant architecture
  • Database Segregation: Tenant-specific schemas with row-level security policies
  • Network Segmentation: Micro-segmentation and VPC isolation for production environments
  • Dedicated Instances: Physical isolation available for enterprise customers (optional)
  • API Rate Limiting: Per-tenant quotas prevent resource exhaustion attacks

3.3 Data Residency and Sovereignty

We offer data residency options to meet regulatory and compliance requirements:

  • Default: EU data centers — GCP europe-west1 (Belgium) — GDPR-compliant by default
  • US Region: GCP us-central1 or us-east1 — available on request for enterprise customers
  • APAC Region: GCP Asia-Pacific regions — planned on roadmap for enterprise accounts
  • UK Region: GCP europe-west2 (London) — planned for UK GDPR requirements

Enterprise customers can select their preferred data region. Cross-region data transfers are minimized and encrypted.

3.4 Data Sanitization and Destruction

When data is deleted:

  • Soft Delete: Initial deletion marks data for removal (30-day recovery period)
  • Hard Delete: Permanent deletion after retention period
  • Cryptographic Erasure: Encryption keys destroyed to render data unrecoverable
  • Media Sanitization: NIST 800-88 compliant procedures for decommissioned hardware
  • Backup Purging: Deleted data removed from all backup systems

4. Access Control and Authentication

4.1 User Authentication

  • Multi-Factor Authentication (MFA): Mandatory for all users; supports TOTP, SMS, and hardware tokens
  • Single Sign-On (SSO): SAML 2.0 and OpenID Connect integration for enterprise customers
  • Password Requirements: Minimum 12 characters, complexity requirements, breach detection
  • Password Hashing: Argon2id with per-user salts (OWASP recommended)
  • Session Management: Secure session tokens, 24-hour expiration, automatic logout
  • Biometric Authentication: Supported for mobile applications (FaceID, TouchID)

4.2 Authorization and Permissions

  • Role-Based Access Control (RBAC): Granular permissions based on predefined roles
  • Attribute-Based Access Control (ABAC): Dynamic permissions based on user attributes and context
  • Principle of Least Privilege: Users granted minimum permissions necessary for their role
  • Just-in-Time (JIT) Access: Time-limited elevated privileges for administrative tasks
  • Access Review: Quarterly review and recertification of user permissions
  • API Key Management: Scoped API keys with rotation and expiration policies

4.3 Administrative Access

Internal Cognitia employee access is strictly controlled:

  • Zero Standing Privileges: No permanent administrative access to production systems
  • Break-Glass Procedures: Emergency access requires approval and audit logging
  • Bastion Hosts: All production access through hardened jump servers
  • VPN Required: No direct internet access to production infrastructure
  • Activity Logging: All administrative actions logged and monitored
  • Background Checks: All employees undergo background verification

4.4 Account Security Features

  • Login Anomaly Detection: Suspicious login attempts flagged (unusual location, device, time)
  • Rate Limiting: Brute-force protection with exponential backoff
  • Account Lockout: Temporary lockout after failed login attempts
  • IP Allowlisting: Restrict account access to specific IP ranges (enterprise feature)
  • Device Fingerprinting: Recognize and trust known devices
  • Security Notifications: Email alerts for suspicious activities

5. Infrastructure Security

5.1 Cloud Infrastructure

Our platform runs on Google Cloud Platform (GCP), an enterprise-grade cloud provider that is ISO 27001, SOC 2 Type II, and FedRAMP authorized:

  • Compute: Google Cloud Run (fully managed serverless containers) in europe-west1 — auto-scaling from zero to thousands of instances
  • Database: Cloud SQL (managed PostgreSQL) with automatic backups, encryption at rest, and high-availability failover
  • Container Registry: Google Artifact Registry (europe-west1-docker.pkg.dev) with vulnerability scanning on every image push
  • CI/CD: Google Cloud Build — automated build, test, and deploy pipeline with audit logging
  • Secrets: Google Secret Manager — all credentials and API keys stored as versioned, encrypted secrets; never in environment variables or source code
  • Storage: Google Cloud Storage (GCS) for file uploads and backups, AES-256 encrypted at rest by default
  • DDoS & WAF: Google Cloud Armor (planned) — layer 7 protection with OWASP rule sets; Cloud Run ingress controls active now
  • Geographic Redundancy: Multi-region backup and disaster recovery on roadmap

5.2 Network Security

Current Implementation:

  • TLS Encryption: TLS 1.2+ for all data in transit
  • HTTPS: Enforced for all web traffic
  • Network Segmentation: Isolated network environments
  • API Rate Limiting: Protection against abuse and DDoS

Planned Enhancements:

  • Google Cloud Armor WAF with OWASP rule sets and adaptive protection
  • VPC Service Controls for private Cloud SQL access
  • Intrusion Detection/Prevention Systems (IDS/IPS) via GCP Cloud IDS
  • 24/7 network monitoring with Cloud Monitoring automated alerting

5.3 Application Security

  • Secure SDLC: Security integrated into development lifecycle
  • Code Reviews: Peer review and security-focused code review for all changes
  • Static Analysis (SAST): Automated code scanning (SonarQube, Snyk)
  • Dynamic Analysis (DAST): Runtime security testing in staging environments
  • Dependency Scanning: Continuous monitoring for vulnerable third-party libraries
  • Container Security: Image scanning, minimal base images, runtime protection
  • Secrets Management: No hardcoded credentials; all secrets stored in Google Secret Manager with versioning and audit logging; secrets injected at runtime via Cloud Run --set-secrets

5.4 API Security

  • Authentication: Bearer tokens (JWT) with short expiration times
  • Rate Limiting: Per-user and per-IP rate limits
  • Input Validation: Comprehensive validation and sanitization of all inputs
  • Output Encoding: Protection against injection attacks
  • API Versioning: Backward compatibility and deprecation policies
  • CORS Policies: Strict cross-origin resource sharing controls

6. Monitoring and Incident Response

6.1 Security Monitoring

Current Implementation:

  • Cloud Logging: All Cloud Run service logs (stdout/stderr) and Cloud Build audit events are automatically captured in Google Cloud Logging (CLOUD_LOGGING_ONLY mode) — centralized, queryable, and tamper-resistant
  • Application Logging: Security-relevant event logging (authentication, authorization, API calls, admin actions) written to structured log streams
  • Error Tracking: Automated error detection and alerting via Cloud Run health checks and log-based metrics
  • Infrastructure Monitoring: GCP Cloud Monitoring for system health, latency, and availability alerts

Planned Enhancements:

  • Security Information and Event Management (SIEM) via Google Chronicle
  • 24/7 Security Operations Center (SOC) monitoring
  • Threat intelligence integration
  • User Behavior Analytics (UBA)
  • Cloud IDS for network-level threat detection

6.2 Audit Logging

Comprehensive logging of security-relevant events:

  • Authentication Events: Logins, logouts, failed attempts, MFA usage
  • Authorization Events: Permission changes, role assignments, access denials
  • Data Access: API calls, data queries, exports, and modifications
  • Configuration Changes: System settings, integrations, user management
  • Administrative Actions: All admin operations logged with user attribution
  • Log Retention: Logs retained for 2 years (7 years for enterprise compliance)
  • Log Integrity: Write-once storage, cryptographic signatures

6.3 Incident Response

Our Security Incident Response Team (SIRT) follows a structured process:

  • Detection: Automated systems and manual monitoring identify potential incidents
  • Triage: Incidents classified by severity (P1-Critical to P4-Low)
  • Containment: Immediate actions to limit impact and prevent spread
  • Investigation: Root cause analysis and impact assessment
  • Remediation: Fix vulnerabilities and restore normal operations
  • Communication: Notify affected customers per legal and contractual obligations
  • Post-Incident Review: Document lessons learned and improve processes

6.4 Breach Notification

In the event of a data breach affecting your data:

  • Timely Notification: Within 72 hours of breach discovery (or as required by law)
  • Impact Assessment: Details of affected data and users
  • Remediation Steps: Actions taken to address the breach
  • Customer Guidance: Recommended actions to protect affected individuals
  • Regulatory Reporting: Assistance with regulatory notifications as needed

7. Business Continuity and Disaster Recovery

7.1 Backup Strategy

Verified Implementation (as of February 19, 2026):

  • Backup Method: PostgreSQL pg_dump with full database dumps
  • Backup Frequency: Configurable (currently on-demand, automated daily schedule in production)
  • Databases Backed Up: control_plane (tenant, user, billing data) and compliance (KYC/KYB data)
  • Backup Format: Plain SQL text format for maximum compatibility and recovery speed
  • Retention Policy: 30-day rolling retention with automatic cleanup of old backups
  • Storage Location: Local storage (development), Google Cloud Storage (GCS) for production — bucket cognitia-uploads-prod, AES-256 encrypted at rest by default
  • Backup Testing: Automated verification scripts with test restore capability
  • Verified Restore Time: 15 seconds for test database (5-30 minutes expected for production)

Planned Production Enhancements:

  • Automated hourly transaction log backups for point-in-time recovery
  • Off-site Google Cloud Storage with AES-256 encryption at rest, cross-region replication
  • Geographic redundancy across multiple regions (US, EU, Asia-Pacific)
  • Real-time monitoring and alerting for backup failures
  • Monthly disaster recovery drills with full restoration testing
  • Long-term archival backups (7-year retention for compliance)

Documentation: Comprehensive backup procedures and test results available in docs/2026-02-19/backup-configuration-report.md

7.2 Disaster Recovery

  • Recovery Time Objective (RTO): 4 hours for critical services
  • Recovery Point Objective (RPO): 1 hour data loss maximum (hourly backups)
  • Verified Recovery Metrics: 15-second restore time to isolated test environment
  • Failover Procedures: Documented restore and recovery procedures
  • DR Testing Schedule: Quarterly full restore drills, monthly verification tests
  • Incident Command: Defined roles and escalation procedures

7.3 High Availability

  • Load Balancing: Traffic distributed across multiple servers
  • Database Replication: Cloud SQL multi-zone replication with automatic failover (production)
  • Content Delivery Network (CDN): Global edge caching for performance
  • Health Checks: Automated monitoring and failover of unhealthy instances
  • Container Orchestration: Docker-based deployment with health monitoring

8. Vendor and Supply Chain Security

8.1 Third-Party Risk Management

  • Vendor Assessment: Security review before onboarding any vendor
  • Security Questionnaires: Detailed evaluation of vendor security practices
  • Contractual Obligations: Security requirements in all vendor contracts
  • Ongoing Monitoring: Periodic reviews of vendor security posture
  • Incident Coordination: Joint incident response procedures with critical vendors

8.2 Sub-Processors

We maintain a list of approved sub-processors who may access customer data:

  • Google Cloud Platform: Primary cloud infrastructure — Cloud Run, Cloud SQL, Secret Manager, Artifact Registry, Cloud Build, GCS, Cloud Logging (europe-west1)
  • SendGrid: Transactional email delivery (authentication emails, system notifications)
  • Sentry: Application error tracking and monitoring (planned)
  • Google Cloud Monitoring: Infrastructure monitoring, alerting, and log-based metrics

All sub-processors are bound by data protection agreements. We notify customers 30 days before adding new sub-processors.

9. Employee Security

9.1 Hiring and Onboarding

  • Background Checks: Criminal background verification for all employees
  • Confidentiality Agreements: NDAs signed before access to systems or data
  • Security Training: Mandatory security awareness training during onboarding
  • Least Privilege: Access granted based on job role requirements

9.2 Ongoing Training

  • Annual Training: Yearly security awareness and privacy training
  • Phishing Simulations: Regular testing of employee vigilance
  • Secure Coding Training: OWASP and secure development practices for engineers
  • Incident Response Drills: Tabletop exercises and simulations

9.3 Offboarding

  • Immediate Access Revocation: All system access disabled on last day
  • Asset Recovery: Return of laptops, security tokens, and access badges
  • Exit Interviews: Reminder of confidentiality obligations
  • Credential Rotation: Shared credentials rotated after departure

10. Vulnerability Management

10.1 Vulnerability Disclosure Program

We welcome security researchers to report vulnerabilities responsibly:

  • Coordinated Disclosure: 90-day window for remediation before public disclosure
  • Bug Bounty Program: Rewards for valid security findings (coming H2 2026)
  • Safe Harbor: Protection for good-faith security research
  • Response SLA: Acknowledgment within 48 hours, triage within 5 business days

10.2 Reporting Security Vulnerabilities

If you discover a security vulnerability, please report it to:

Legal Entity: Cognitia

Registered Address: Cairo, Arab Republic of Egypt

Email: support@cognitia-ai.ai

Website: https://cognitia-ai.ai/security

Please include detailed steps to reproduce the issue. Do not exploit vulnerabilities or access data beyond what is necessary to demonstrate the issue. We appreciate responsible disclosure and will respond to valid reports promptly.

10.3 Patch Management

  • Critical Patches: Applied within 24 hours of discovery
  • High Severity: Patched within 7 days
  • Medium/Low Severity: Patched within 30 days
  • Automated Updates: Security patches for dependencies applied automatically
  • Maintenance Windows: Scheduled updates with minimal service disruption

11. Customer Security Responsibilities

Security is a shared responsibility. While we secure the platform, you are responsible for:

11.1 Account Security

  • Enabling and maintaining MFA for all users
  • Using strong, unique passwords
  • Securing devices used to access the Services
  • Promptly reporting suspicious activities or unauthorized access
  • Regularly reviewing access logs and user permissions

11.2 Data Management

  • Classifying and handling data according to sensitivity
  • Implementing appropriate data retention policies
  • Obtaining necessary consents for processing personal data
  • Validating AI outputs before making critical decisions
  • Encrypting sensitive data before upload (optional additional layer)

11.3 Integration Security

  • Securing API keys and tokens; rotating regularly
  • Implementing proper authentication for webhooks and integrations
  • Restricting API access to specific IP ranges when possible
  • Monitoring API usage for anomalies

12. Security Updates and Changes

We continuously improve our security posture. This Security Policy may be updated to reflect new security measures, regulatory requirements, or industry best practices.

Material changes will be communicated via:

  • Email notification to account administrators
  • In-app announcements
  • Status page coming soon; incidents can be reported via support contact details below

We encourage you to review this policy periodically and watch for security announcements through our email and in-app channels.

13. Contact and Governing Law

13.1 Contact Information

For security-related inquiries, vulnerability reports, or compliance questions:

13.2 Governing Law

This Security Policy is governed by the laws of the Arab Republic of Egypt. For questions about compliance, data protection requirements, or security practices, please contact us at support@cognitia-ai.ai.

Note: This Security Policy is provided for informational purposes and does not constitute a contractual commitment. Specific security commitments for enterprise customers are documented in Service Level Agreements (SLAs) and contractual terms.

Last Updated: April 15, 2026

© 2026 Cognitia. All rights reserved.