Trust center
Plain English about how we run, where data lives and what we file.
DSP Watch is the audit-log layer behind your takedowns, so the trust questions get specific fast — SOC 2 status, uptime, residency, who signs, and how we stay on the right side of DMCA §512(f) and Lenz. The answers below are current and honest. For the technical controls underneath, see /security.
Posture
Where we are on certifications and uptime.
No theatre. The honest status of our certifications, service objective and where customer data lives.
-
SOC 2 Type II — target Q3 2027
We are in the readiness phase for SOC 2 Type II, with an audit window targeting completion in Q3 2027. The honest status today: controls are designed and operating, the formal observation window has not yet closed. We will publish the report and bridge letter to enterprise customers under NDA once issued.
-
Uptime target 99.5%
Our service objective is 99.5% monthly availability for the application and API, measured end to end from a third-party probe. That budget is ~3 hours 39 minutes of unavailability per 30-day month. Status incidents and post-mortems are published when an outage exceeds 5 minutes of customer impact.
-
Data residency: arn + AP-Northeast-1
Customer database lives in Supabase AP-Northeast-1 (Tokyo). Compute for scanners, evidence rendering and adapter workers runs on Fly.io in arn (Stockholm). Cloudflare's global edge serves static assets from the nearest PoP; no customer content is cached at the edge.
-
Incident response runbook
On-call rotates 24/7. A Sev-1 (customer-impacting outage or data integrity event) opens an incident channel within 5 minutes of detection, posts to status within 15, and is followed by a written post-mortem within 5 business days. The runbook is reviewed quarterly.
Data residency
Where does customer data live, exactly?
Database in Tokyo, compute in Stockholm, object storage on R2. Cloudflare's global edge serves static assets; customer content is not edge-cached.
| Layer | Vendor | Region | Notes |
|---|---|---|---|
| Edge / CDN | Cloudflare | Global PoPs | Static assets, WAF, bot management. Customer content is not edge-cached. |
| Primary database | Supabase | AP-Northeast-1 (Tokyo) | Postgres + RLS. Daily encrypted backups retained 30 days. |
| Compute | Fly.io | arn (Stockholm) | Scanners, evidence rendering, adapter workers. Private flycast network. |
| Object storage | Cloudflare R2 | Auto (global) | Evidence PDFs keyed by SHA-256, accessed via workspace-bound signed URLs. |
| Resend | US | Transactional only — verification, attestation, counter-notice warnings. |
Compliance posture
How do we stay inside §512?
DSP Watch only sends takedowns that meet the statutory elements, with a human signer on every filing and a fair-use review gate per Lenz.
-
DMCA §512(c)(3) — all 6 elements, verbatim
Every takedown notice DSP Watch files contains the six statutory elements of 17 U.S.C. §512(c)(3)(A): physical/electronic signature, identification of the work, identification of the infringing material, contact information, the good-faith statement, and the accuracy / authorization statement under penalty of perjury. The wording is reproduced verbatim and the signing user attests to it.
-
§512(f) — human-in-the-loop on every filing
We do not auto-file takedowns. Every notice requires a human review and MFA-fresh signer attestation before submission. This is the operational backstop against §512(f) liability for knowing material misrepresentation, and it is hard-wired into the action lifecycle.
-
Lenz v. Universal — fair-use consideration enforced
Under Lenz v. Universal Music Corp., 801 F.3d 1126 (9th Cir. 2015), copyright holders must consider fair use before sending a takedown. The DSP Watch signing flow gates the submit button on a fair-use review checkbox tied to the signer's attestation, and records the consideration in the audit log.
-
Counter-notice clock tracked
The §512(g) counter-notice window is tracked from the moment a counter-notice lands. We fire an action.counter_notice_warning event at T-3 business days so legal can decide whether to file an action to keep material down before reinstatement.
Incident response
What happens when something breaks?
A Sev-1 incident opens an internal channel within 5 minutes of detection, posts to a public status update within 15 minutes, and generates a written post-mortem within 5 business days. The full runbook is reviewed quarterly and is available under NDA to enterprise customers.
T+5 min
Detect and triage
On-call acknowledges the page, opens the incident channel, and classifies severity. Sev-1 is customer-impacting downtime or integrity loss.
T+15 min
Communicate
A status update goes out via email and the status feed. Updates continue every 30 minutes until resolution.
T+5 days
Post-mortem
A written post-mortem with timeline, root cause and corrective actions is published to affected customers within 5 business days.
FAQ
Quick answers.
- Is DSP Watch SOC 2 certified today?
- Not yet. We are SOC 2 Type II readiness as of 2026 with a target audit window completing in Q3 2027. Controls are designed and operating; the formal Type II observation window has not yet closed. We will share the report under NDA with enterprise prospects when issued.
- What is the uptime guarantee?
- Our service objective is 99.5% monthly availability. That is a target, not a contractual SLA on self-serve plans. Enterprise contracts can include a written SLA with credits — talk to sales.
- Where is customer data stored?
- Primary database in Supabase AP-Northeast-1 (Tokyo). Compute in Fly.io arn (Stockholm). Object storage in Cloudflare R2. Static assets are served from Cloudflare's global edge; customer content is not edge-cached.
- Do you file takedowns automatically?
- No. Every takedown requires a human signer who re-authenticates with MFA within 5 minutes of submission, reviews the §512(c)(3) evidence package and confirms fair-use consideration per Lenz v. Universal. The submit button does not light up otherwise.
- Where do I read the security details?
- Technical control specifics — RLS, hash-chained audit log, MFA-fresh JWTs, Cloudflare WAF, Fly flycast, R2 signed URLs and the Worker-Fly JWT replay-protection scheme — are on /security.
Need the security controls?
RLS, hash-chained audit log, MFA-fresh signing, edge controls and sub-processors are documented on the security page.