BaytyAI → Security
When the data includes claims evidence, contractor identity, and government approvals — security is not optional.
BaytyAI is built for programs where a data breach is not a PR problem — it is a commercial liability and a regulatory event. Every control on this page is labelled with its real status: active in production, or on the roadmap.
Security Posture
Eight controls. Labelled by real status.
Six are active in production today; two are on a dated roadmap. We label each one so your evaluators never have to guess.
At-Rest Encryption
AES-256
Database fields containing personal data, identity documents, and financial records are encrypted with AES-256. Verification documents are held in private Supabase Storage buckets — never in public object storage.
In-Transit Encryption
TLS 1.3
All connections are served over modern TLS (1.3 negotiated where the client supports it). Legacy TLS 1.0/1.1 are not offered at the edge. No unencrypted data transmission is possible within the platform.
Data Isolation
Row Level Security
PostgreSQL Row Level Security enforces organisation-scoped isolation at the database query level. No organisation can read another organisation’s data — enforced by the database engine, not by application logic.
Authentication
Passwordless + MFA
Sign-in is passwordless email one-time-passcode today — no reusable passwords to phish. Mandatory TOTP-authenticator MFA for Owner, Administrator, and leadership roles is on the near-term roadmap. SMS 2FA will not be offered (SIM-swap risk).
Key Management
Separated Keys
Encryption keys are managed by the platform key service, logically separated from the data they protect. Application secrets and service-role keys are read only server-side and are never shipped to the browser.
Access Control
Verification-Gated
No organisation reaches sensitive program workflows without completing verified onboarding. Role-based policies govern what each verified party can see, submit, approve, and export.
Audit Integrity
Append-Only Logs
Every approval, rejection, document action, admin action, and data export is written to an append-only audit log. Records cannot be edited or deleted — only new entries can be added.
Certification Roadmap
SOC 2 Type II
SOC 2 Type II audit commissioned for 2027 Q2, following a six-month continuous evidence period. Underlying providers (Vercel, Supabase) are already SOC 2 Type II audited. ISO 27001 alignment assessed alongside.
Encryption Architecture
Data protected at every layer — at rest, in transit, and at the key.
At rest: AES-256
Database fields containing personal data are encrypted with AES-256. Supabase Storage buckets holding verification documents (Emirates IDs, trade licences, professional certificates) are private — no public URL, no indexable access. Documents are served exclusively via short-lived signed URLs generated by authenticated server-side functions.
Standard: AES-256 · Storage: Supabase private buckets · Access: signed URLs
In transit: TLS 1.3
TLS 1.3 is negotiated on all connections between client devices, the application layer, and the database, wherever the client supports it. Legacy TLS 1.0/1.1 are not offered at the Vercel and Supabase edge. HSTS is enforced with a one-year max-age and preload.
Standard: TLS 1.3 · Legacy: Not offered · HSTS: max-age 31536000; preload
Key management: separated
Encryption keys are managed by the platform key service and are logically separated from the data they protect. Service-role credentials are read only in the server environment and never reach the browser. Column-level encryption for the most sensitive references (national ID, payment identifiers) is on the roadmap as a second layer.
Keys: separated from data · Service keys: server-only · Column encryption: roadmap
Access Control Architecture
Who can access what — enforced at the database, not the application.
The most common security failure in multi-tenant SaaS is application-layer access control — where a compromised session can cross organisational boundaries by exploiting application logic. BaytyAI enforces data isolation at the PostgreSQL query layer via Row Level Security. A compromised application session cannot return another organisation’s data, because the database engine rejects the query before executing it.
Standard multi-tenant
- ✕ Access control enforced by application code
- ✕ A session-level vulnerability can bypass to another tenant’s data
- ✕ Penetration test must cover every application code path
- ✕ Audit: trace every data access through application logs
BaytyAI Row Level Security
- ✓ Access control enforced at the PostgreSQL query-planner level
- ✓ No application vulnerability can cross organisational data boundaries
- ✓ The security perimeter is the database — not the application code
- ✓ Audit: organisation_id scoping is enforced by the engine, not by logic
| Role | Create projects | Approve | Access documents | Export data | Manage users |
|---|---|---|---|---|---|
| Owner / Authority | ✓ | ✓ | ✓ | ✓ | ✓ |
| Consultant | — | ✓ | ✓ | Limited | — |
| Tier-1 Contractor | Limited | ✓ | ✓ | Limited | Limited |
| Subcontractor | — | — | Limited | — | — |
| Supplier | — | — | Limited | — | — |
| Administrator | ✓ | ✓ | ✓ | ✓ | ✓ |
HTTP Security Headers
Six headers. Five enforcing, one in report-only.
Security headers are configured in next.config and applied to every response. We show the real status of each — including the CSP, which runs in Report-Only while we tune it.
Strict-Transport-Security
max-age=31536000; includeSubDomains; preload
Forces HTTPS for all connections. Prevents SSL stripping and protocol downgrade.
X-Frame-Options
DENY
Prevents clickjacking via iframe embedding on any origin.
X-Content-Type-Options
nosniff
Prevents MIME-type sniffing attacks on uploaded documents.
Content-Security-Policy
Report-Only (enforcing planned)
Currently deployed in Report-Only mode to observe violations safely before enforcement. Enforcing CSP with no inline scripts is on the near-term roadmap.
Referrer-Policy
strict-origin-when-cross-origin
Limits referrer-header data leakage on cross-origin navigation.
Permissions-Policy
camera=(), microphone=(), geolocation=()
Disables browser APIs the platform does not use — removes unnecessary attack surface.
Verification Document Handling
Identity documents are the highest-risk data on the platform. They are treated accordingly.
BaytyAI handles Emirates IDs, Iqama cards, passports, DED trade licences, MOMAH contractor registrations, and professional certificates. These are sensitive personal data under UAE PDPL Federal Decree-Law No. 45/2021, Saudi Arabia PDPL, and GDPR Article 9. The controls below apply exclusively to this data category, in addition to all platform-wide encryption and access controls.
Storage Isolation
Verification documents are stored in dedicated private Supabase Storage buckets, separated from other platform data. Bucket-level access policies are enforced independently of application logic.
No Permanent URLs
Verification documents have no permanent URL. Access is exclusively via signed, time-limited URLs generated by authenticated server-side functions. Documents cannot be cached, indexed, or bookmarked.
Access Logging
Every access to a verification document is recorded with requesting user ID, organisation ID, document type, timestamp, and access method. Logs are append-only.
Retention & Deletion
Active account: documents retained for the account lifecycle plus 90 days. Closed account: personal data deleted within 30 days per UAE PDPL Article 14. Deletion is automated and generates a deletion confirmation record.
Breach Protocol
A confirmed breach affecting verification documents triggers TDRA notification within 72 hours per UAE PDPL, with affected data subjects notified within 10 business days. The incident-response plan is reviewed quarterly.
SOC 2 Type II Roadmap
A specific certification timeline — not a general alignment statement.
SOC 2 Type II requires a minimum six-month continuous evidence period before the audit can be commissioned. This timeline reflects that requirement.
2026 Q3
Controls Implementation
Document and implement all SOC 2 Trust Service Criteria controls — Security, Availability, Confidentiality. Access-control matrix documented. Incident-response plan finalised. Vendor risk assessments completed.
2026 Q4 – 2027 Q1
Evidence Collection Period
Six-month continuous compliance evidence period begins. Access logs, change-management records, security-incident logs, and availability metrics collected systematically. Internal audit conducted at midpoint.
2027 Q2
External Audit
SOC 2 Type II audit commissioned with a specialist information-security auditor. Scope: Security, Availability, Confidentiality. Evidence period: 2026 Q4 – 2027 Q1.
2027 Q3
Report Issued
SOC 2 Type II report issued and available to enterprise and government clients under NDA. Enables formal vendor approval for financial-services, government, and regulated-industry clients.
ISO 27001 scope assessment will be conducted alongside SOC 2 evidence collection. ISO 27001 certification will be evaluated based on enterprise client requirements in Year 3.
Data Residency
Where your data is stored — and how that changes as we scale.
| Region | Data types | Status |
|---|---|---|
| EU — Frankfurt (AWS) | All platform data at launch: user accounts, project records, verification documents, approval history | Active — current default |
| UAE — Bahrain (AWS) | UAE-jurisdiction client data; preference for government and public-sector programs | Roadmap — Month 12 |
| Saudi Arabia — Riyadh (AWS) | KSA-jurisdiction client data; required for Saudi PDPL government-program compliance | Roadmap — 2027 Q3 |
| Custom residency | Dedicated deployment for programs requiring single-jurisdiction isolation | Available — enterprise negotiation |
Data residency configuration is available as part of enterprise implementation planning. Programs requiring residency outside default regions should contact enterprise@baytyai.com to discuss dedicated environment options.
Security FAQ
What enterprise procurement asks — answered specifically.
BaytyAI is not currently SOC 2 Type II certified. Our SOC 2 Type II audit is scheduled for 2027 Q2, following a six-month evidence-collection period beginning 2026 Q4. The full roadmap is published on this page. Enterprise clients requiring SOC 2 certification before procurement should contact enterprise@baytyai.com to discuss interim security controls and documentation.
AES-256 is applied to database fields containing personal data, identity documents, and financial records. Verification documents in Supabase Storage are encrypted at the bucket level with AES-256. Column-level encryption of national ID references, payment identifiers, and verification-document references is on the roadmap as an additional layer.
TLS 1.3 is negotiated on all connections where the client supports it. Legacy TLS 1.0 and 1.1 are not offered at the Vercel and Supabase edge. HSTS is enforced with a one-year max-age and preload.
Data isolation is enforced at the PostgreSQL query level via Supabase Row Level Security. Every query is filtered by the authenticated user’s organisation before execution, so even a compromised application session cannot access another organisation’s data — the database rejects the query before returning results. This is database-layer isolation, not application-layer filtering.
Platform data is stored with our managed database provider in an EU (Frankfurt) region by default. UAE-region residency (Bahrain) is planned for Month 12; Saudi Arabia-region residency (Riyadh) is planned for 2027 Q3. Enterprise programs requiring specific data residency should contact enterprise@baytyai.com.
Verification documents are retained for the active account lifecycle plus 90 days post-closure. On account closure, personal data is deleted within 30 days per UAE PDPL Article 14. Deletion is automated and generates a deletion-confirmation record; binary documents are hard-deleted from storage and metadata is anonymised.
Sign-in is passwordless today via email one-time-passcode, so there are no reusable passwords to phish. Mandatory TOTP-authenticator MFA for Owner, Administrator, and leadership roles is on the near-term roadmap; SMS 2FA will not be offered due to SIM-swap risk. Contact enterprise@baytyai.com for the current MFA status on your program.
A third-party penetration test is planned prior to Enterprise client onboarding and annually thereafter, with automated security testing in the interim. Results and remediation reports will be available to enterprise clients under NDA. Contact enterprise@baytyai.com for current penetration-test documentation.
Your security team has questions we are prepared to answer.
BaytyAI will provide security documentation, penetration-test results, data processing agreements, and sub-processor lists to qualified enterprise and government programs under NDA.