How we protect your data

We're currently preparing for SOC 2 Type Iand have implemented core security controls including role-based access, audit logging, and secure infrastructure. Below is what's in place today and what's coming next.

Controls in place today

Authentication & access

• Role-based permissions. Owner / manager / coordinator / VA / analyst roles, each with a scoped permission set (properties, scheduling, billing, exports, team management).
• Per-account access codes with rate limiting on every login surface — both per-email and per-IP, so credential-stuffing is throttled at multiple layers.
• Session cookies set with httpOnly, secure, and sameSite flags. Sessions expire after 14 days.
• Admin actions are audit-logged — see below.

Audit logging

• Every sensitive action — admin login, subscriber updates, vendor payouts, team-member changes, subscription state, room deletions — writes an append-only record with actor, timestamp, IP, and a structured detail blob.
• Logs are read-only at the application layer. Redactions (GDPR, PII) are operator-initiated and tracked separately.
• Operators can request an export of audit events tied to their workspace.

Data & transport

• TLS 1.2+ on every connection. HSTS enforced for one year.
• Encryption at rest via Postgres + Supabase Storage defaults (AES-256).
• Stripe handles all payment information. We never see or store card numbers.
• File uploads are validated by content (magic-byte check), MIME type, extension, and size cap before being written — defends against polyglot files even if a Content-Type is spoofed.

Application & network

• Content Security Policy restricts script and connection origins to ScopeIQ and our vetted infrastructure providers. frame-ancestors 'none' blocks clickjacking.
• Stripe webhooks are signature-verified. Forged webhook payloads are rejected before any state change.
• Rate limits on all public endpoints — login, signup, checkout, public token portals — with per-IP and per-key throttles.
• Secrets live in Vercel encrypted env vars. Source code is private.

Operational

• Defense-in-depth. If one layer fails (rate limit, auth gate, validation), there's another behind it.
• Vendor escrow. PM-funded turn payments are held until QA-approved before release; payouts are blocked when a PM has flagged a quality issue.
• Tenant photo isolation. Move-in / move-out photos are scoped to the operator workspace; no cross-tenant access path.
• Deploy gates. Production deploys go through type-check + build before promotion. Schema migrations are versioned and reviewed.

Coming next

• SOC 2 Type I. In active preparation — control documentation, policy authoring, and evidence collection. Type II window opens after Type I report is issued.
• Postgres row-level security policies for tenant isolation enforced at the database layer (currently enforced at the application layer).
• Multi-factor authentication (TOTP) on admin and operator accounts.
• Penetration test against the production environment before our next major enterprise milestone.
• Customer-controlled data export and deletion endpoints in the workspace UI.

Responsible disclosure

Found something? Email admin@scopeiq.tech with reproduction steps. We commit to acknowledging within 2 business days and will not pursue legal action for good-faith research that follows responsible-disclosure norms (no data exfiltration, no service degradation, no targeting of other customers).

Contact

Compliance questionnaires, security reviews, vendor-due-diligence forms: admin@scopeiq.tech.

This page describes ScopeIQ's security posture as of 2026-04-27. Specific control implementations may evolve as the product and threat model change.