Data Residency
Last updated: 2026-09-08 · Reglint LLC
This page describes where your data is processed and stored, who processes it, and how long it is kept — as the system actually runs today, not as an aspiration. It is a plain-language companion to the Data Processing Agreement and the Privacy Policy, which govern in the event of any conflict.
1. Processing Location
All Reglint infrastructure runs in Amazon Web Services region us-east-1 (N. Virginia, USA). Compute (ECS Fargate and Lambda), the primary database (RDS PostgreSQL), the audit store (DynamoDB), object storage (S3), and the regulatory knowledge base (Bedrock) are all located there.
When a scan runs in full mode, the prompt/output pair is sent to our judgment-layer model provider over the public internet for the compliance decision (see §3). Everything else — the deterministic rules engine, retrieval of regulatory text, and all data at rest — stays within AWS us-east-1.
2. Sub-Processors
We use a small, fixed set of sub-processors. The authoritative list lives in the DPA; it is reproduced here for convenience.
| Sub-processor | Location | Purpose |
|---|---|---|
| Amazon Web Services, Inc. | us-east-1 (Virginia, USA) | Hosting, database, storage, Bedrock knowledge base, email (SES) |
| Anthropic PBC | USA | Claude API — the judgment layer for compliance decisions on scan payloads |
| Stripe, Inc. | USA | Payment and subscription processing (no scan content is shared) |
Your data and message content are never used to train any model — not by Reglint, and not by the model providers we use under their commercial terms.
3. Judgment Layer (Model)
The full-mode compliance decision is produced by Claude, from Anthropic PBC (USA), called directly over Anthropic’s API. This is the source-level default and the provider running in production today — verified against the live system.
Reglint’s architecture can support additional judgment models, but any change to the production model would be reflected in the DPA sub-processor list first. We do not silently route customer content to any provider not listed above.
4. Data Retention
Retention is enforced in code across every store, not merely promised:
- Scan payloads (prompt/output pairs) — 90 days, then irreversibly purged, uniformly across all stores: DynamoDB item TTL, a daily RDS content-purge worker, and an S3 lifecycle expiration rule.
- Logs — 90 days. CloudWatch log groups are set to a 90-day retention.
- Anonymized scan metadata (decisions, counts, timestamps, with no raw content) is retained beyond that window for product and accuracy tracking; it is not linkable to an individual after the payload is purged.
- Billing records — 7 years, to comply with U.S. tax law (IRC § 6001).
5. Custom Retention Windows
The default retention window for scan payloads is 90 days. Custom retention windows are available under enterprise agreements. This is an arrangement made with our team — it is not a self-serve setting in the product. To discuss a custom window, contact us.
6. How You Can Verify This
You do not have to take these claims on trust. Every scan writes a record to a tamper-evident, SHA-256 hash-chained audit trail — each record is cryptographically bound to the previous one, so any later edit to stored content breaks the chain.
Authenticated customers can export their audit records and confirm what is stored, what decision was made, and when a payload’s content was purged (the record carries a purge timestamp once the 90-day window passes).
7. Regional Residency (Roadmap)
Regional data residency in the Middle East (AWS me-central-1 / me-south-1) is planned. We are not committing to a date. Until it ships, all processing and storage is in us-east-1 as described above.
8. Contact
Questions about data residency, retention, or sub-processors? Contact us, or review the full Data Processing Agreement and Privacy Policy. Arabic version: العربية.