How we secure your data, end to end.

Scinops AI is a Software-as-a-Service platform that ingests structured assessment answers, runs deterministic scoring, enriches them with retrieval-augmented LLM calls and returns an executive-grade AI advisory report. The data we hold is modest in volume but sensitive in nature: operational profiles of security and HR firms, contact details, payment metadata and the generated reports themselves.

Our security programme follows the principle of least privilege, defence in depth and verifiable controls. Wherever possible we use managed services with auditable security postures (AWS, Stripe, NextAuth providers, OpenRouter) rather than building our own. This document is reviewed at least every six months and after any material change to the platform.

Production workloads run in AWS me-central-1 (UAE). Compute is containerised behind an AWS-managed load balancer. Application data lives in a managed MariaDB cluster with encrypted storage, automated minor-version patching and point-in-time recovery. Object storage (PDF reports, uploaded attachments) sits in S3 with default encryption and versioning enabled.

Environments

• Production — isolated VPC, restricted ingress, short-lived deployment credentials.
• Staging — same architecture as production, seeded with synthetic data only.
• Development — local containers; no customer data permitted under any circumstance.

The platform is a Next.js 14 application written in TypeScript with strict mode enabled. We apply the OWASP ASVS Level 2 controls as our baseline for application security.

• All inputs validated through Zod schemas at the API boundary before they reach business logic.
• Output encoding handled by React; we forbid dangerouslySetInnerHTML except for JSON-LD blocks rendered server-side.
• CSRF protection through SameSite cookies and NextAuth session tokens; mutating routes require an authenticated session.
• Content Security Policy and standard hardening headers (HSTS, X-Content-Type-Options, Referrer-Policy) applied at the edge.
• Dependencies pinned via lockfile; automated audits run on every pull request and a weekly schedule.
• Secrets stored in AWS Secrets Manager and injected at boot; no secret values ever committed to source control.
• Pull requests require code review and a green CI pipeline before merge to the main branch.

Customer authentication is delegated to NextAuth with email magic links and optional OAuth providers. Internal access to AWS, the application database and observability tooling is gated through:

• Single sign-on with mandatory multi-factor authentication for every Scinops team member.
• Role-based access control mapped to job function; no engineer has standing production database write access.
• Just-in-time elevation for break-glass operations, with automatic revocation after the session.
• Quarterly access reviews; immediate revocation on role change or departure (within one business day).
• All admin actions in the application emit an immutable audit-log entry.

The application is reachable only through an HTTPS endpoint protected by a managed Web Application Firewall. Database and internal services are private to the VPC and are not exposed to the public internet. Outbound traffic is restricted to documented destinations (LLM providers, Stripe, email, telemetry).

• Application logs, request logs and audit logs are centralised and retained for at least 365 days.
• Anomaly alerting on authentication failures, privilege escalation, unusual data egress and error-rate spikes.
• Stripe and OpenRouter webhooks signed and verified; replayed events rejected.
• Infrastructure metrics, traces and alerts route to an on-call rotation 24×7.
• Customers can request a copy of access logs related to their account upon written request.

• Dependency CVE scans on every build; critical findings block deploys.
• Container base images rebuilt at least weekly and on emergency CVEs.
• Static analysis (TypeScript strict + ESLint security rules) on every pull request.
• External penetration testing on a 12-month cycle, with retest of high/critical findings.
• Service Level Objectives for remediation: Critical ≤ 7 days, High ≤ 30 days, Medium ≤ 90 days, Low ≤ 180 days.

We maintain a written incident response plan covering detection, triage, containment, eradication, recovery and post-incident review. Severity is graded SEV-1 through SEV-4, and the on-call engineer is the incident commander until formally handed off.

• Database point-in-time recovery with a 7-day window; daily full snapshots retained for 35 days.
• Object storage versioning enables recovery from accidental deletes for 30 days.
• Recovery objectives: RPO ≤ 1 hour, RTO ≤ 4 hours for a full regional restore.
• Disaster recovery drill executed at least annually with documented evidence.

We use a small set of vetted sub-processors. A current list is maintained on the data residency page and changes are notified to enterprise customers at least 30 days in advance, except where a faster change is required to mitigate a security risk.

• Background checks (where legally permitted) for every employee with access to production systems.
• Annual security and privacy training, with topic-specific modules on UAE PDPL and AI safety.
• Confidentiality clauses in every employment and contractor agreement.
• Hardened laptops with full-disk encryption, MDM, automatic patching and anti-malware.

Scinops AI is designed against the controls of ISO/IEC 27001:2022, SOC 2 Type II trust services criteria, the UAE Information Assurance Standards (NESA / SIA) for moderate-impact systems and the UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021). We are happy to share our internal control mapping and current attestation status under NDA.

If you believe you have found a security vulnerability, please email security@scinops.ai with a clear description and reproduction steps. We commit to acknowledging your report within two business days, keeping you updated and crediting you on our hall of fame if you wish. Please act in good faith: do not access data that is not yours, do not run automated scanners against production and do not publicly disclose before we have had a reasonable opportunity to fix the issue.