01 — Authentication
Strong authentication, by default.
Every Onsight account is protected by a Supabase Auth-managed password hash (bcrypt, never reversible). Two-factor authentication is one click away in account settings, and required for the internal admin role.
Password storage
bcrypt-hashed via Supabase Auth. Plain-text passwords are never stored, logged, or transmitted to Cascade Asia.
Two-factor (MFA)
TOTP via any authenticator app — 1Password, Authy, Google Authenticator, Microsoft Authenticator, or any RFC 6238 client. Enrollment is available for all roles today via account settings. A hard-gate enforcement flag (app_settings.admin_mfa_enforced) is wired and currently off pending team rollout; once flipped, the onsight-admin-* surfaces require an aal2 step-up. The soft banner already nudges admins to enroll. enforcement: rollout pending
Session lifetime
Sessions roll on activity. Sign-out-everywhere is available from Account → Security to invalidate all sessions instantly.
Password recovery
Email-based password reset; the reset link expires after one hour and is single-use.
Email verification
Required for sign-in. Email changes require verification of the new address before taking effect.
02 — Audit logging
Every consequential action is logged. Every read is logged.
SOC 2 and procurement teams ask "who did what, when?" The answer is a CSV away.
Admin action log
Every pricing change, brief approval, role change, jurisdiction edit, billing event, and customer-data change is recorded with before / after JSON, actor identity, timestamp, and optional note. live
Read audit log
Append-only record of who viewed which entity profile, opened which brief, or exported which CSV. Heavy-reader detection flags accounts whose volume looks like enumeration. live
Customer transparency
Every customer can see their own audit history under Account → Activity. Org admins can see their full team's activity.
Retention
Indefinite for the duration of the customer relationship. On deletion, audit rows are retained for compliance with the customer identity replaced by a stable anonymized token.
Export
CSV export from the admin audit page (for the customer's own auditors) or the customer's own activity export. Both filterable by date range.
03 — Encryption
Encrypted in transit and at rest.
In transit
TLS 1.2+ enforced on every endpoint. HTTP requests are 301-redirected to HTTPS. HSTS header on all production responses.
At rest
AES-256 encryption at the storage layer, managed by Supabase via AWS KMS. Backup snapshots are encrypted with the same key class.
Application-level PII encryption
For sensitive fields (individual full names, native-script names, addresses), application-level encryption with admin-managed keys is on the roadmap. planned
Database connections
All app-to-database connections use TLS. The service-role key never leaves server-side environments.
Secrets management
All API keys, webhook secrets, and credentials are stored in Supabase Vault or as environment-scoped secrets. Never committed to source.
04 — Cryptographic provenance
Every report we publish is anchored. Tampering is detectable by anyone.
Cascade hashes every audit-grade artifact — field briefs, evidence items, sanctions screenings, address verifications, field findings — and submits the hash to the public OpenTimestamps calendars, which batch-anchor it into the Bitcoin blockchain. The result is a cryptographic receipt that any third party, with any OpenTimestamps-compatible verifier, can use to prove the artifact existed at the recorded time and has not been altered since. Cascade does not need to be subpoenaed, online, or even in business for the proof to hold up.
For a litigator preparing to introduce a Cascade brief as evidence, or a regulator referring a finding upstream, this closes the loop that traditional “trust us” intelligence vendors leave open. The artifact_hash column on every customer-facing artifact table makes the proof reproducible from raw data.
What is anchored
field_briefs.artifact_hash, field_findings.evidence_hash, evidence_items.content_hash, sanctions_screenings.content_hash, address_verifications.evidence_hash. live
How it is anchored
Submitted to the OpenTimestamps public calendars (a.pool.opentimestamps.org, b.pool, finney.calendar.eternitywall.com). Calendars batch hashes into a Merkle tree and anchor the tree root to Bitcoin every ~10 minutes.
How to verify
Download the .ots receipt from the artifact page, run any OpenTimestamps verifier (CLI ots verify, ots.tools, the JavaScript verifier in the public OTS repo). The verifier checks the Bitcoin block, returns the timestamp, and confirms the hash. No Cascade involvement needed.
What this protects against
Backdating allegations, post-delivery alteration of a brief, internal-tampering by a Cascade employee, and the “the vendor went under so we cannot verify” failure mode. It does not protect against an artifact being deleted or never published — absence is not detectable, only presence.
05 — Hosting & data residency
Customer data stays in Singapore.
Onsight runs on Supabase, hosted on AWS in the ap-southeast-1 (Singapore) region. We do not replicate customer data to other regions. Edge Functions run in the same region; cross-region invocations are not used.
Primary region
ap-southeast-1 (Singapore) — every database row, file, and Edge Function execution.
Customer-data egress
Customer data does not leave Singapore except when you ourself export it (CSV / PDF) or when you grant access to a sub-processor (see below).
DNS & CDN
cascadeasia.com static assets are served via CDN with global edge caching. The CDN does not see authenticated customer data — only the public marketing site, jurisdiction-tier graphics, and methodology pages.
Multi-region failover
Not currently configured. RPO and RTO targets below assume a single-region recovery scenario.
06 — Backup & restore
30-day point-in-time recovery, drill-verified.
Backup frequency
Continuous WAL streaming from Supabase Postgres, plus daily full snapshots. 30-day point-in-time recovery window.
RPO target
≤ 1 minute (continuous WAL).
RTO target
≤ 4 hours for a full restore. The actual measured time in our quarterly drill has been under 30 minutes for a 200 MB database.
Restore drill
Quarterly. Documented in our internal Operations runbook. Each drill restores a recent backup to a fresh project, verifies row counts against production, and is logged.
Off-Supabase archive
Weekly pg_dump to a second-vendor object store (Backblaze B2). Encrypted with a customer-independent key. planned
Restore-on-request
If a customer accidentally deletes a watch list, finding, or report, we can restore from PITR within the 30-day window. Email
inquiries@cascadeasia.com with the timestamp.
07 — Access control
Row-level security on every table.
Cascade Asia uses Postgres row-level security (RLS) for authorization. Every table that holds customer data has RLS policies enforcing that customers can only read and write their own rows. There is no application-layer "is this user allowed to see this?" check that could be bypassed by a forgotten guard — the database itself refuses the query.
Roles
Four roles: client (customer), analyst + team_lead (Cascade Asia internal — analyst is the catch-all role for all Cascade field contributors regardless of employment status), admin (Cascade Asia leadership). Each role's permissions are defined as RLS policies.
Org admins
Customer organizations have a designated org_admin who can invite teammates, deactivate seats, and view their team's activity log. Other seats see only their own data.
Privileged operations
Sensitive admin actions (pricing changes, brief approvals, billing) run as SECURITY DEFINER RPCs that explicitly check the caller's role before executing.
Service-role key
The Supabase service-role key (which bypasses RLS) is never deployed to the browser. It is only used by Edge Functions, which run server-side.
08 — Source protection & compartmentalization
Field intelligence has its own threat model. So do its sources.
Cascade collects human-sourced intelligence (HUMINT — interview reporting from in-country contacts) and conducts site visits across Southeast Asia. The intelligence we deliver to a customer reflects work that real people did in real places, often involving in-country contacts who would face professional, regulatory, or physical risk if their identity surfaced. Off-the-shelf KYC databases do not have this problem because their data is scraped public records. Ours is not, and we treat the difference as the centre of gravity for our security architecture.
Analyst code names
Field reports stored in production carry an analyst code name (e.g. CA-JKT-04), never the analyst’s legal identity. The mapping between code name and legal identity lives in a separate system with separate access. A breach of the customer-facing database does not yield a roster of Cascade fieldworkers.
Source identity is not in production
Source identification (the actual person at the actual ministry, or the named industry contact) lives only in the analyst’s encrypted notes outside the customer-facing database. What reaches production is a source grade (A1 through F6) and a sanitised description (“provincial regulatory contact”), never the source’s name or contact details. A breach of Onsight production yields graded reports without the means to identify the network behind them.
Data minimisation at collection
Raw field notes — pre-redaction photos, GPS waypoints, candid interview transcripts, draft attribution — live on analyst-side encrypted storage and are destroyed on a defined schedule once the polished report has shipped. The customer-facing report is a derivative artifact. The breach blast-radius for raw notes is “one analyst’s laptop,” not the platform.
Compartmentalisation within Cascade
Analysts see only the engagements assigned to them. They do not have read access to other engagements involving the same target, or to the customer’s identity beyond what their engagement requires. The implication is that a customer’s anxiety — “what if your analyst’s cousin works at the target?” — is mitigated structurally: the analyst doesn’t know the customer’s broader interest in the target, nor whether other Cascade work has touched it.
Customer identity in field-engagement workflow
For sensitive engagements, the customer’s identity is masked from the executing analyst by default and revealed only to the team lead and engagement owner. Most customers will never need this, but it’s available for engagements where the customer’s interest in a target is itself sensitive.
09 — Incident response
Notification within 72 hours of confirmed incident.
If we confirm an incident affecting customer data, we will notify affected customers within 72 hours via the email on the customer's primary account. For confirmed breaches involving unauthorized access to customer data, the notification window is 24 hours.
Severity tiers
Critical: confirmed unauthorized access to customer data. High: service outage > 4 hours. Medium: service degradation. Low: internal-only events. Notification timing scales with severity.
Status & uptime
A public status page and any uptime-credit commitment will be introduced with Onsight’s general availability. Specific service-level commitments, where offered, are set out in the applicable order form or MSA. planned
Post-incident review
Every Critical or High incident gets a written post-mortem shared with affected customers within 14 days. Includes timeline, root cause, and remediation.
10 — Sub-processors
The vendors we use to deliver Onsight.
A "sub-processor" is a third-party service that processes customer data on our behalf. We use the following sub-processors. Customer notification of any change to this list will go out at least 30 days in advance.
| Vendor | What they do | Region | Data shared |
|---|
| Supabase Database, auth, storage, edge functions |
Primary infrastructure. Hosts the Postgres database, file storage, authentication, and serverless function runtime. |
AWS ap-southeast-1 (Singapore) |
All customer data |
| AWS Underlying cloud (via Supabase) |
Compute, storage, networking. Cascade does not have a direct AWS account; access is mediated by Supabase. |
ap-southeast-1 (Singapore) |
All customer data (encrypted) |
| Resend Transactional email |
Delivers notification emails (watch alerts, ticket replies, account verification). |
US (multi-region) |
Recipient email + email subject + body |
| Stripe Payment processing |
Invoice payment, webhook reconciliation. Customer billing details (card numbers) never reach Cascade Asia — they live in Stripe. |
US, EU (Stripe-managed) |
Org name, contact email, billing amount |
| Browserless / OpenTimestamps Evidence capture & timestamping |
Public-source webpage capture (for evidence) and Bitcoin-anchored cryptographic timestamps. Operate on public URLs only. |
EU (Browserless), public network (OTS) |
Public URLs only — no customer data |
| Google / Cloudflare DNS DNS resolution |
Resolves cascadeasia.com. |
Global |
None (just DNS records) |
A signed Data Processing Agreement is available on request for any sub-processor that handles customer data.
11 — Compliance roadmap
Where we are. Where we're going.
SOC 2 Type I
Engagement scoped for 2026. Targeting Type I report by Q4 2026. planned 2026
SOC 2 Type II
Following Type I, target audit window of 6 months. planned 2027
GDPR
Cascade Asia processes personal data of individuals subject to GDPR (where named on watched entities or as engagement subjects). Standard Contractual Clauses and a Data Processing Agreement are
published here; countersigned copies on request.
applicableSingapore PDPA
Cascade Asia is a Singapore-based service; PDPA applies. Our data residency in Singapore aligns with PDPA requirements for sensitive processing. applicable
ISO 27001
Not currently certified. We follow many of the ISO 27001 controls (audit logging, access control, encryption, incident response). Formal certification is in our roadmap behind SOC 2.
Data Subject Access Requests
Customer DSAR procedure documented in our internal Operations runbook. Acknowledgement within 72 hours; response within 30 days as required by GDPR. live
Customer-managed encryption keys (CMEK)
For Enterprise-tier customers who require their own KMS to hold the wrapping key for their data, CMEK is available on commitment. The customer’s AWS / GCP KMS key wraps a per-tenant data key; if Cascade is subpoenaed or breached, what we can produce is encrypted bytes — only the customer’s KMS can unwrap. Built per-customer rather than as a generic feature; engineering work funded by the engagement. on commitment
Tenant isolation snapshot test
A continuous-integration test that spawns two empty client orgs, writes data only to org A, then attempts every read path from org B’s authenticated context. Every result must return zero rows. The test is the structural guarantee that RLS policies cannot regress without the build failing. scheduled
12 — Responsible disclosure
If you find a vulnerability, tell us.
We don't run a paid bug bounty yet, but we take security reports seriously and will work with you to resolve and disclose responsibly. We commit to:
- Acknowledging your report within 2 business days.
- Assessing severity and giving you a triage decision within 5 business days.
- Resolving Critical and High issues within 30 days; Medium and Low within 90 days.
- Recognizing your contribution publicly (if you wish) once the fix has shipped, and via a "researcher hall of fame" page (forthcoming).
- Not pursuing legal action against good-faith security research that complies with the scope below.
In scope: the production Onsight platform on cascadeasia.com, the Supabase database, our Edge Functions, and the public marketing site. Out of scope: attacks on third-party sub-processors (please report to the sub-processor's program directly), attacks that require physical access, social engineering of Cascade staff or customers, and brute-force attacks against authentication.
Email security reports to security@cascadeasia.com with subject "Security vulnerability report". Please include reproduction steps and any proof-of-concept code. PGP key available on request.
