Security & Compliance

1. Compliance & Certifications

2. Encryption

2.1 Data at Rest

All data stored in our infrastructure is encrypted using AES-256 encryption. This applies to:

• Databases (application data, user accounts, billing records)
• Object storage (logs, backups, exports)
• Disk volumes attached to compute instances
• Database backups and snapshots

Encryption keys are managed through a cloud-native Key Management Service (KMS) with automatic key rotation every 90 days. Keys are stored in FIPS 140-2 Level 3 validated hardware security modules (HSMs).

2.2 Data in Transit

All data in transit is encrypted using TLS 1.3 (with TLS 1.2 as minimum supported version). This applies to:

• All API endpoints (HTTPS only; HTTP requests are rejected, not redirected)
• Internal service-to-service communication (mutual TLS)
• Database connections (encrypted client connections mandatory)
• Backup transfers between regions

We support modern cipher suites only. Deprecated protocols (SSLv3, TLS 1.0, TLS 1.1) and weak ciphers (RC4, 3DES, NULL) are disabled.

2.3 Encryption in Processing

API inputs are decrypted only within the secure processing boundary of our inference pipeline. Model inputs and outputs are held in memory during processing and are not written to persistent storage in unencrypted form.

3. API Key Security

3.1 Key Storage

• API keys are stored using one-way bcrypt hashing -- the plaintext key is shown only once at creation and cannot be retrieved
• Key prefixes (xln_live_, xln_test_) allow identification without exposing the secret portion
• Keys are bound to specific accounts and cannot be transferred between organizations

3.2 Key Rotation

• Customers can rotate keys at any time from the dashboard with zero-downtime overlap period
• When a new key is generated, the old key remains valid for a configurable grace period (default: 24 hours)
• Enterprise customers can enforce automatic key rotation policies (30, 60, or 90 day cycles)

3.3 Key Scope and Restrictions

• Keys can be scoped to specific endpoints, IP allowlists, and rate limit tiers
• Sandbox keys (xln_test_) cannot access production data or incur charges
• Compromised keys can be revoked instantly; revocation propagates within 30 seconds globally

4. Network Security

4.1 Infrastructure Isolation

• Virtual Private Cloud (VPC): All production infrastructure runs within isolated VPCs with strict ingress/egress rules
• Network segmentation: Application tier, database tier, and management tier are network-isolated with firewall rules permitting only required traffic
• Private connectivity: Internal services communicate over private network paths; no internal traffic traverses the public internet

4.2 DDoS Protection

• Layer 3/4 DDoS mitigation at the network edge (volumetric attack absorption)
• Layer 7 application-level protection with intelligent rate limiting and request filtering
• Automatic traffic shaping during attack detection with minimal impact to legitimate traffic
• Geographic traffic analysis for anomaly detection

4.3 Firewall Rules

• Default-deny ingress policy; only explicitly permitted ports and protocols allowed
• Web Application Firewall (WAF) with OWASP Top 10 rule sets
• Egress filtering to prevent data exfiltration
• Real-time firewall log analysis with automated blocking of malicious IPs

5. Audit Logging

5.1 What We Log

Event Category	Examples	Retention
Authentication events	Login, logout, MFA challenges, failed attempts, key creation/revocation	12 months
Authorization events	Permission changes, role assignments, scope modifications	12 months
API access	Request metadata (endpoint, method, status code, latency, source IP)	90 days
Administrative actions	Configuration changes, deployment events, secret access	12 months
Data access	Database queries by internal systems, export operations	12 months
Security events	Rate limit triggers, blocked requests, WAF alerts, anomalies	12 months

5.2 Log Integrity

• Logs are written to append-only storage with cryptographic integrity verification
• Log data is encrypted at rest and access-controlled separately from application data
• Administrative access to logs requires separate credentials and is itself logged
• Logs cannot be modified or deleted by application-level code or operators

5.3 Customer Access

Customers can access their own audit logs (API access, authentication events, key management) via the dashboard and API. Enterprise customers receive extended log access including detailed request metadata.

6. Penetration Testing

6.1 Internal Testing

• Continuous automated vulnerability scanning of all production infrastructure
• Static application security testing (SAST) integrated into CI/CD pipeline
• Dynamic application security testing (DAST) run weekly against staging environments
• Dependency vulnerability scanning with automated alerting for critical CVEs

6.2 External Testing

• Annual penetration test conducted by an independent third-party security firm
• Scope includes: API endpoints, authentication system, network infrastructure, web applications
• Findings are remediated based on severity (Critical: 24h, High: 7d, Medium: 30d, Low: 90d)
• Summary reports available to Enterprise customers under NDA

6.3 Customer Testing

Enterprise customers may conduct their own penetration tests against their XALEN-hosted endpoints with 14 days advance written notice to security@xalen.io. Testing must not impact service availability for other customers. Coordinated testing windows are available.

7. Bug Bounty Program

7.1 Scope

We maintain a responsible disclosure program for security researchers. In-scope targets include:

• xalen.io and all subdomains
• XALEN API endpoints (api.xalen.io)
• Authentication and authorization systems
• Data exposure or leakage vulnerabilities

7.2 Out of Scope

• Social engineering (phishing, vishing)
• Denial of service (DoS/DDoS) attacks
• Physical security testing
• Third-party services (payment processor, email provider)
• Sandbox/test environments

7.3 Reporting

Report vulnerabilities to security@xalen.io with:

• Description of the vulnerability and its potential impact
• Steps to reproduce
• Proof of concept (if applicable)
• Your contact information for follow-up

7.4 Our Commitment

• Acknowledge receipt within 2 business days
• Provide initial assessment within 5 business days
• No legal action against good-faith security researchers
• Public recognition (with permission) for valid findings
• Reward consideration based on severity and impact

8. Data Residency

8.1 Available Regions

Region	Location	Use Case
India	Mumbai (asia-south1)	Default for Indian customers. DPDPA compliance. Lowest latency for South Asia.
United States	Iowa (us-central1)	Default for US/global customers. SOC 2 aligned infrastructure.
European Union	Available on request	GDPR-native processing. Data never leaves EU boundaries. Dedicated infrastructure.

8.2 Data Residency Guarantees

• When a region is selected, all persistent data (databases, logs, backups) remains within that geographic region
• Inference processing occurs within the selected region unless the Customer explicitly enables cross-region failover
• Enterprise customers receive contractual data residency commitments as part of their DPA
• Region selection is immutable once configured; migration to a new region requires explicit Customer action

9. Incident Response

9.1 Incident Classification

Severity	Description	Response
Critical	Active data breach, unauthorized access to customer data, service-wide compromise	Immediate response, Customer notification within 72 hours, regulatory notification as required
High	Vulnerability with active exploitation potential, targeted attack detected	Response within 1 hour, patch within 24 hours, Customer notification within 72 hours
Medium	Vulnerability without active exploitation, suspicious activity patterns	Response within 4 hours, remediation within 7 days
Low	Informational findings, configuration improvements, hardening recommendations	Tracked and addressed in regular maintenance cycles

9.2 Incident Response Process

1. Detection: Automated monitoring, security alerts, or external reports
2. Containment: Isolate affected systems to prevent further impact
3. Investigation: Determine scope, root cause, and affected data
4. Remediation: Patch vulnerabilities, restore systems, strengthen controls
5. Notification: Inform affected customers within 72 hours of confirmed breach
6. Post-Incident Review: Document findings, implement preventive measures, publish RCA

10. Personnel Security

• Background verification for all employees with access to production systems or customer data
• Mandatory security awareness training upon hire and quarterly refresher training
• Principle of least privilege: access granted only for job function requirements
• Quarterly access reviews with automatic deprovisioning of unused privileges
• Immediate access revocation upon employment termination (within 1 hour)
• Confidentiality and data protection clauses in all employment agreements
• Segregation of duties for sensitive operations (deployment, secret access, billing)

11. Additional Security Measures

11.1 Secure Development

• Security-focused code review required for all changes to authentication, authorization, and data handling code
• Automated security scanning in CI/CD pipeline (SAST, dependency scanning, container scanning)
• Immutable infrastructure: production containers are rebuilt, not patched in place
• Secret management via dedicated secret manager service; no secrets in code or environment files

11.2 Supply Chain Security

• Software Bill of Materials (SBOM) maintained for all production dependencies
• Automated alerts for critical CVEs in dependencies with SLA for remediation
• Container images built from minimal base images with regular rebuild cycles
• Signed container images with verification at deploy time

11.3 Business Continuity

• Multi-region deployment with automatic failover (RTO: 4 hours, RPO: 1 hour)
• Daily encrypted backups with tested restore procedures (restore tested monthly)
• Disaster recovery plan documented and exercised semi-annually
• No single point of failure in critical path infrastructure

12. Contact

For security inquiries, vulnerability reports, or compliance documentation requests:

XALEN Technology Pvt Ltd
Pune, Maharashtra, India

Security team: security@xalen.io
Privacy/DPO: privacy@xalen.io
Enterprise sales: enterprise@xalen.io
General: hello@xalen.io

Enterprise customers seeking compliance documentation (SOC 2 reports, penetration test summaries, completed security questionnaires) should contact their account manager or email enterprise@xalen.io.