Security
Built to be checked, not just trusted.
Screening counterparties means holding sensitive research on the organisations our customers deal with. Below is exactly how that data is isolated, what protects it in transit, how we treat the web content a screening pulls in, and where we still have work ahead of our first audit. If your security team has a questionnaire, send it — we'll answer it directly.
SOC 2 Type II — underway
We've engaged an independent auditor and are working through control evidence collection now. We'll share the completed report under NDA once it's ready. Until then, the sections below describe the actual controls in place today — not a roadmap.
Tenant isolation
Every table that holds customer data — counterparties, screenings, matches, alerts, reports — carries a foreign key back to your organisation. Application code doesn't query those tables directly: a dedicated data-access layer is the only sanctioned path, and it scopes every read and write to the caller's organisation automatically.
We run an automated test suite on every change that deliberately tries to make one organisation read, modify or list another's records — through the API, the data-access layer, and the audit log — and asserts it fails every time. That suite runs before anything reaches production.
Authentication
Passwords are hashed with scrypt and never stored or logged in plain text. Sessions are httpOnly, marked secure, and expire after seven days with rolling renewal on activity. API keys for programmatic access are 256-bit random values — only a hash is ever stored, and the full key is shown once, at creation. Sign-in attempts are rate-limited to blunt credential-stuffing and brute-force attempts.
Single sign-on and multi-factor authentication aren't live yet — they're on our roadmap. If either is a requirement for your organisation, tell us and we'll factor it into prioritisation.
How we treat the web content we screen
A screening pulls in pages from sanctions lists, registries and open media — content we don't control. Every page is fetched through a hardened fetcher that only allows HTTPS, pins the connection to the address it actually resolved to, and blocks private, loopback and link-local addresses outright, so a page can't be used to redirect a request into an internal network.
Once fetched, that content is wrapped and explicitly labelled untrusted before structured extraction. Content inside the wrapper is treated as data to analyse, never as instructions to follow. The extracted output must pass a defined schema before the product can use it.
Each adverse-media claim must be backed by a verbatim quote from the page it cites. If the exact quote does not appear in that source, Sightline discards the claim before it reaches the memo.
Audit trail
Each organisation has its own append-only audit log. Counterparty changes, screening runs, monitor and alert activity, API key issuance and revocation, and membership changes are all recorded with who did what and when — there's no update or delete path for that log from application code. Org owners can export their own audit history at any time.
Deleting an organisation removes the underlying data, but a minimal record of who deleted it and when is kept separately, so deletion itself stays accountable.
Infrastructure & data
Sightline runs on Railway, in Australia, backed by managed Postgres. Every connection — from your browser to us, and from us out to every sanctions, registry and media source we query — is encrypted in transit. Backups run daily with a seven-day retention window.
Deleting your organisation removes your data from the live database immediately; it ages out of backups within that same seven-day window.
Who else touches your data
We use a small number of vendors to run the product. Here's what each one is for, and what it sees.
| Vendor | What it's for | What it sees |
|---|---|---|
| Memo synthesis service | Structured memo preparation | Subject names, fetched media text, generated memo content |
| OpenSanctions | Sanctions & PEP screening | Counterparty name and country |
| US Dept. of Commerce | Export-control screening (Consolidated Screening List) | Counterparty name |
| NZ Companies Office | Company registry lookups (NZBN) | Counterparty name and registration details |
| Tavily | Adverse-media web search | Counterparty name |
| Stripe | Billing | Subscription and payment data |
| Resend | Transactional email | Recipient email address |
| Cloudflare R2 | File storage | Generated report PDFs, kept separate per organisation |
| Railway | Hosting | Everything above, at rest |
Our marketing site, sightline.nz, separately uses Google Analytics for traffic statistics. It does not receive counterparty or product-account data.
Access & operations
We're a small team. Production access is limited to the people who need it to operate the service, and we're formalising an access-review process as part of our SOC 2 work.
Found a problem?
Email [email protected] — a person reads it, not a ticket queue.
Last reviewed July 2026 · updated as our SOC 2 audit progresses