Security Policy

---

Executive Summary

Simply Asking LLC ("Simply Asking," "the Service," "we," "us," or "our") is committed to protecting the security, integrity, and confidentiality of customer data. This document outlines our comprehensive security practices, infrastructure, and controls.

---

1. Infrastructure Security

1.1 Hosting & Deployment

The complete subprocessor list, including every AI provider, is the Subprocessor Registry.

1.2 Geographic Distribution

• Primary Database: AWS US-East-2 (Ohio) via Supabase
• Edge Functions: Globally distributed via Supabase Edge
• Application CDN: Vercel Edge Network (300+ global locations)
• Static Assets: Vercel CDN with automatic optimization

1.3 Network Security

• All traffic encrypted via TLS 1.3
• HTTP Strict Transport Security (HSTS) enabled
• Automatic SSL/TLS certificate management
• DDoS protection via Vercel and Supabase infrastructure
• Rate limiting on API endpoints

---

2. Data Security

2.1 Encryption

2.2 File Security

All uploaded files are scanned for malware using ClamAV antivirus before processing. Infected files are quarantined and logged via security event tracking. File scanning runs on private infrastructure with no public endpoint exposed.

2.3 Data Isolation

We implement strict data isolation using 480+ Row-Level Security (RLS) policies:

• Users can only access documents within their organization
• Organization data is isolated at the database level
• Personal workspaces are completely separate from business workspaces
• Cross-organization data access is prevented by default

2.4 Data Classification

2.5 Data Retention

Retention windows are set by the Data Retention Policy, which is the source of truth. Summarized here:

• User Documents: Retained until user deletion or account termination
• Chat History: Retained until you delete it
• Audit Logs: Retained for 24 months
• Backups: 30-day rolling backups with point-in-time recovery

---

3. Authentication & Access Control

3.1 User Authentication

• Email/Password Authentication: Passwords hashed using bcrypt with salt
• Multi-Factor Authentication (MFA): Available for all accounts
• Session Management:
  • Configurable session timeout per organization
  • Maximum session duration enforced
  • Concurrent session limits configurable
• OAuth Providers: Google (optional)

3.2 Role-Based Access Control (RBAC)

JWT-Based RBAC Enforcement: A custom authentication hook embeds organization context (org_id, org_role, is_platform_admin, department_ids) directly into JWT claims at login. Row-level security policies read claims from the signed token, eliminating subqueries and ensuring consistent enforcement across all database operations.

3.3 Platform Administration

• Platform administration restricted to company founders
• Admin access logged and auditable
• Privileged access requires additional authentication
• Admin actions subject to review

---

4. Application Security

4.1 Secure Development Lifecycle

• Code Review: All changes reviewed before merge
• Static Analysis: Automated security scanning on pull requests
• Dependency Scanning: Automated vulnerability detection in dependencies
• Secret Detection: Automated scanning for exposed credentials

4.2 API Security

• Authentication: JWT-based with short-lived tokens
• Authorization: Server-side validation on every request
• Input Validation: Strict input sanitization and validation
• Rate Limiting: Per-user and per-IP rate limits
• CORS: Origin validation against an explicit allowlist (no wildcards)
• Content Security Policy (CSP): Headers restrict script sources, prevent inline injection, and block unauthorized third-party resources
• SSRF Prevention: Server-side URL fetching blocks private and internal network addresses (localhost, RFC 1918 ranges, link-local)

4.3 Cryptographic Standards

• CSPRNG: All security-sensitive random values (OTP codes, MFA tokens, correlation IDs) use crypto.getRandomValues() for cryptographically secure generation
• Self-Hosted Fonts: All fonts are served from our own infrastructure; no external font CDN requests are made, preventing third-party tracking via font loading

4.4 Third-Party Integrations

All third-party OAuth tokens are encrypted with AES-256-GCM before storage.

Per-User Connection Ownership & Admin Governance

Integrations are owned by individual users, not by the organization. Each team member who connects an integration authorizes it under their own account and the resulting OAuth tokens are scoped to that user.

Role-based access (server-enforced at the API layer). Every privilege in the matrix below is checked on the server in the corresponding edge function route; the user interface only mirrors what the server allows.

The role gate is implemented in can_user_connect_integration() (manager-or-above check, scoped to the caller's JWT org_id). Admin reads route through list_org_connections(), which checks org_id IS DISTINCT FROM get_jwt_org_id() OR NOT is_org_admin() and rejects unauthorized callers with RAISE EXCEPTION 'unauthorized'. The "Allow members" toggle is set via the dedicated update_org_allow_member_integrations() RPC, which checks for the Owner role specifically (not the broader is_org_admin() set).

• Token isolation. OAuth refresh and access tokens are readable only by the service role (server-only). Direct database SELECT on the access_token and refresh_token columns is revoked for the authenticated role at the column level (defense-in-depth on top of row-level security). No client-side code path reads tokens.
• Row-level security. A team member sees only their own connections in the standard user_connections SELECT policy (user_id = auth.uid()). A second PERMISSIVE policy grants org Owners and Admins read access to every connection in their organization (org_id = get_jwt_org_id() AND is_org_admin()), but only via the list_org_connections SECURITY DEFINER RPC, which projects the safe columns and redacts tokens.
• Default role gate. By default, only Owners, Admins, and Managers may initiate /connect/start. Owners may opt in to allow all members to connect via the organizations.allow_member_integrations flag.
• Admin actions are audited. Every connect, disable, re-enable, and reauth event is written to an immutable user_connection_audit_log table with actor, target, timestamp, and reason. The log is append-only by RPC; direct INSERT is not granted to client roles.
• Soft-disable preserves audit trail. When an Admin disables a member's connection, sync stops immediately, but the row, OAuth tokens, and audit history are retained so the connection can be re-enabled by a single action. The pre-disable sync_status is snapshotted so re-enable restores the prior health state instead of falsely reporting "active."
• Membership-tied lifecycle. When a team member is deactivated or removed from an organization (org_members.is_active = false or DELETE), database triggers soft-disable all of that user's connections in that organization.
• Reauth alerts. When an OAuth token-refresh fails (most commonly because the third-party provider revoked the refresh token), a daily cron sends a reauthorization email to the connection owner. The cron applies a 24-hour cooldown via last_alert_sent_at and auto-stops after 7 consecutive days to prevent spam.

---

5. AI & Machine Learning Security

5.1 AI Model Providers

5.2 AI Data Processing

• User queries processed in real-time, not stored by AI providers
• Document embeddings stored in our database, not shared externally
• AI responses generated per-request with no persistent context
• No customer data used to train any AI models

5.3 Prompt Injection Prevention

• Input sanitization on all AI-bound queries
• System prompts isolated from user input
• Output validation before display

---

6. Payment Security

6.1 PCI DSS Compliance

• We never store, process, or transmit credit card data
• All payment processing handled by Stripe (PCI DSS Level 1)
• Payment forms embedded via Stripe Elements (iframe isolation)
• Subscription management via Stripe Customer Portal

6.2 Billing Security

• Billing history accessible only to account owner
• Usage data anonymized for internal analytics
• Refunds processed only through verified channels

---

7. Monitoring & Incident Response

7.1 Continuous Monitoring

• Uptime Monitoring: Automated health checks via Vercel and Supabase
• Error Tracking: Real-time error detection via Sentry
• Security Logging: Authentication events logged via Supabase Auth
• Metrics & Alerts: Application metrics and alerting via Vercel Analytics

7.2 Audit Logging

We maintain comprehensive audit logs including:

• User authentication events (login, logout, failures)
• Document access and modifications
• Permission changes
• API access patterns
• Administrative actions

7.3 Incident Response Plan

We follow a structured incident response process:

Response times vary based on incident severity and complexity.

7.4 Breach Notification

In the event of a data breach affecting customer data:

• Affected customers notified within 72 hours
• Regulatory authorities notified as required by law
• Full incident report provided within 30 days

---

8. Business Continuity

8.1 Backup Strategy

Backup and recovery is managed by our infrastructure provider (Supabase):

• Database: Daily automated backups with point-in-time recovery
• Files: Redundant storage via Supabase Storage (S3-backed)
• Configuration: Version-controlled infrastructure-as-code

8.2 Disaster Recovery

Disaster recovery capabilities are provided by our infrastructure partners:

• Database Failover: Managed by Supabase infrastructure
• Storage Redundancy: Multi-availability zone via AWS S3
• Application: Edge deployment via Vercel with automatic failover

8.3 Service Availability

• Availability: We use commercially reasonable efforts to maintain high availability
• Infrastructure SLAs: Subject to Supabase (99.95%) and Vercel uptime guarantees
• Support Response: Best effort response within 24-48 hours
• Scheduled Maintenance: Announced in advance when possible

---

9. Compliance

9.1 Regulatory Compliance

Note: We implement privacy and security practices aligned with these regulations. Our OWASP ASVS Level 1 self-assessment covers 73 controls across authentication, session management, access control, input validation, cryptography, error handling, data protection, communications, HTTP security, file handling, API security, configuration, and business logic. Our infrastructure partners maintain their own compliance certifications.

9.2 Data Processing Agreements

• Standard DPA available for enterprise customers
• Sub-processor list maintained and updated
• Data processing limited to service provision

---

10. Security Contact

Reporting Vulnerabilities

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

• Email: dev@simplyasking.io
• Response Time: Initial acknowledgment within 24 hours
• Disclosure: We support coordinated disclosure

Security Questions

For general security questions or to request compliance documentation:

• Email: legal@simplyasking.io
• Subject Line: "Security Inquiry"

---

11. Document History

---

This security policy is reviewed and updated at least annually, or more frequently as needed to address emerging threats and changes to our infrastructure.