Security
Isolation you can inspect, not a paragraph in a brochure.
Multi-tenant accounting software has exactly one unforgivable failure: showing one company another company’s numbers. Here is precisely how iPACER prevents it, in enough detail that your own engineers can judge whether the argument holds.
Tenant isolation
Isolation implemented as a habit fails the first time somebody is in a hurry. It has to be structural.
One choke point, not one per endpoint
The usual multi-tenant breach is a single endpoint that forgot its filter. In iPACER application code cannot get an unfiltered database handle. Every query goes through a tenant-bound proxy that injects the tenant predicate itself — on reads, joins, inserts, updates and deletes alike.
Unknown tables fail closed
Each table is explicitly classified as tenant-scoped or global. A table nobody classified throws instead of returning rows, so adding a feature cannot quietly create a leak. A health endpoint asserts the classification is complete on every deploy.
Cross-tenant references are rejected on write
Supplying a parent record id belonging to another company is refused at write time, not discovered later as a dangling reference that reads across the boundary.
Ordering cannot defeat the filter
A tenant filter that a later clause can overwrite is not a filter. The predicate is combined rather than replaced, so it survives regardless of the order the query is assembled in.
Access control
Membership is checked per request
Sessions are validated against live membership on every request rather than trusting a token issued earlier. Removing someone from a workspace revokes their access on their next request, not at their next login.
Roles are per workspace
A user can belong to more than one company with a different role in each. Authorization reads the role for the active workspace, so elevated access in one place grants nothing in another.
Customer logins see one customer
Client portal accounts are bound to a single customer record. Requesting a project or invoice belonging to anyone else returns not-found. An unbound client account is refused rather than defaulted to full visibility.
Financial actions are role-gated
Posting and voiding journal entries, sending invoices, approving change orders and closing periods require an appropriate role. Approvers are recorded from the authenticated session, never from a value the browser supplied.
Data handling
Credentials
Passwords are stored as PBKDF2-SHA256 derivations with a per-user random salt and 100,000 iterations. Plaintext is never written anywhere. Invitation links are stored only as a SHA-256 hash, so a copy of the database does not yield a working invite.
Sessions
Session cookies are HttpOnly, Secure and SameSite=Lax, and state-changing requests are origin-checked.
Records are archived, never destroyed
Removing a record marks it archived and hides it from working views. The row, and its history, remain. Financial history is corrected by posting a reversing entry — an entry that has been posted is never edited away.
Backups are verified
Database exports are checked after they are written rather than assumed to have worked. An unverified backup is a rumor you get to test on the worst day of the year.
Straight answers
- Where is the data hosted?
- On Cloudflare’s network, using D1 for the database and R2 for file attachments. Traffic is served over HTTPS from edge locations, and the application runs as an isolated Worker rather than a shared server.
- Is iPACER SOC 2 certified?
- No. iPACER has not completed a SOC 2 audit, and we will not imply otherwise. The controls described on this page are properties of the software that we will happily demonstrate in a live workspace. If a formal attestation is a requirement for your organization, tell us during evaluation.
- Can you see our data?
- Operating the service requires administrative database access, as it does for any hosted application. We do not use customer data for anything other than running and supporting the service.
- What happens to our data if we leave?
- It is yours. You can export it, and archived records are retained rather than purged, so an export is a complete history rather than a snapshot of what is currently visible.
Send us your security questionnaire
We would rather answer the hard questions during evaluation than discover a mismatch after you have migrated.