How VeraStream protects your AP ledger data.
The controls, sub-processors, and compliance posture behind VeraStream — written for the CFO, Controller, and Chief Audit Executive who has to sign off on a vendor before AP spend ever reaches our detectors.
Data handling
What we ingest — and what we deliberately don't
VeraStream runs against the AP transaction rows you choose to share. The default data envelope is narrow: enough signal for the detectors to be useful, no PII beyond vendor name unless you ship it.
What we ingest
- Vendor name and vendor ID
- Invoice number, amount, posting date, and currency
- Cost center, GL account, and approver (when present)
- Uploaded CSV files for auditor-initiated runs
What we don't ingest by default
- Bank account numbers or routing numbers
- SSNs, EINs, or other government identifiers
- Employee SSNs or payroll data of any kind
- Card primary account numbers (only tokenised billing data)
Retention & deletion
Retention is customer-configurable with a 90-day default for uploaded CSVs and in-progress run reports retained per tenant settings. Customer-managed deletion is available from the tenant console at any time. On written request to the POC email below, we will delete all tenant data and confirm in writing within 30 days.
Encryption
Encrypted in transit, encrypted at rest, scoped on access
Every byte that moves across the wire is wrapped in TLS; every byte that lands on disk is wrapped in AES-256. Report-level downloads add a third layer: signed, single-purpose access tokens.
In transit
All browser-to-edge and edge-to-service traffic uses TLS 1.2 or higher. The edge enforces HSTS, so a downgrade attempt is rejected before any application data is read.
At rest
Render-managed Postgres and object storage both encrypt data at rest with AES-256. Uploaded audit files are stored encrypted and access-scoped by signed per-report download tokens issued by /api/audit/download/[id].
Access controls
Email-gated access, least privilege, no prod data in dev
Access is gated at the artifact level — reading a report means holding a token tied to that single report and that single recipient.
Email-gated access
Every shared report requires a signed download token tied to a specific report ID. Tokens expire and cannot be reused across reports.
Least privilege
Internal application access follows least privilege: read-only roles for support, write only for the auditor-facing endpoints, no broad data-export role for any team.
No prod data in dev
Production data is never present in dev or staging. Internal testers run against fully synthetic or fully anonymised slices — never against real customer ledgers.
Sub-processors
Three named sub-processors, full data-category disclosure
Every party that touches your data is listed below. This list is reproduced verbatim in customer DPAs on request.
| Sub-processor | Purpose | Data category shared |
|---|---|---|
Render | Hosting, managed Postgres, and object storage | Transactional AP ledger rows (vendor name, invoice number, amount, posting date) plus per-tenant configuration |
Postmark | Transactional email delivery | Recipient email address and email body — no ledger data ever crosses the wire |
Stripe | Billing and invoicing | Billing email and card token — raw PAN never stored |
Compliance posture
SOC 2 Type I is in progress — here's what we already have shipped
We do not claim certifications we have not earned. The list below is the set of controls currently operating in production.
- Encryption in transit (TLS 1.2+ at the edge, HSTS-enforced) and at rest
- Per-request access logging on every API endpoint
- Secrets managed exclusively via Render environment variables with vaulted injection
- Automated Postgres backups with point-in-time recovery
- Documented incident-response runbook with on-call coverage
- Change management via code review and a deploy audit log
Incident response
A documented runbook, named POC, fixed notification SLA
If something goes wrong, the path from detection to customer notification is rehearsed and the clock starts at confirmation, not at suspicion.
Notification SLA
We commit to notifying affected customers of any material security incident within 72 hours of confirmation. The clock starts once the incident has been triaged and confirmed material — not at first suspicion.
Point of contact
For incident reporting, security questions, or DPA/sub-processor requests, write to verastream@polsia.app. Responses within one business day, escalation within 24 hours if you mark the subject Urgent.
Data residency
US by default, EU on request for enterprise plans
Region is a contractual lever, not a runtime toggle. Pick the region you want at contract time and we provision a tenant there.
US (default)
Production tenants ship in Render's Oregon region. Backups, object storage, and the audit API all live in the same region.
EU (on request)
Enterprise plans can be provisioned in a dedicated EU region. EU residency is available via contract — request it during procurement and it is in place before your first ledger row lands.
Vulnerability disclosure
Responsible disclosure is welcome and acknowledged
If you find a vulnerability in VeraStream, tell us first. We will acknowledge within 72 hours and keep you updated as we work the report.
How to disclose
Send the technical detail to security@verastream.app. Encryption is not required — but please do not include production customer data in the report.
- We will acknowledge within 72 hours, every report.
- Please avoid automated scanners, load tests, and denial-of-service testing. Manual testing against your own tenant is welcome.
- We do not pursue legal action against good-faith security research under this policy.
See it on a real-shaped ledger
These controls wrap every detector run
A worked sample on a 2,400-row synthetic ledger, or drop your own AP CSV into the in-browser audit — same envelope, same controls, no signup required.