CompanySecurity

Each operator’s data stays theirs. Down to the database row.

OmniPM holds passports, contracts, payment proofs and owners’ money for many operators on one platform. Here is exactly how it keeps them apart, what it encrypts, and who can see what.

Encryption in transitHTTPS only · HSTS preload

Operator secrets at restAES-256-GCM

Passwords and codesbcrypt, cost 12

ID and payment filesPrivate bucket · 1 h links

Checks before each release11, incl. isolation audit

Tenant isolation

One codebase, one database, every row stamped with its operator. A request that can’t say whose data it is gets refused, not guessed.

Request

A staff member, resident or website calls OmniPM with a session cookie or a hashed API key.

session → operator_id

Operator context

The session names the operator, held for the whole request so nothing downstream has to guess.

AsyncLocalStorage

Data layer

Every read is filtered and every write stamped. A write naming another operator throws.

where: { operatorId }

Database backstop

Operator columns can’t be empty, and triggers refuse a child row under another operator’s parent.

NOT NULL · triggers

Raw SQL is allowlisted file by file, with how each query is scoped. An audit fails anything new.

Isolation tests run in the suite, and the isolation audit is one of 11 checks before every release.

Controls, in plain language.

What we do for sign-in, sessions, files, payments, messages and AI — written for the operator, not the auditor.

Sign-in

Passwords and one-time codes are stored only as hashes. Codes expire in 10 minutes and stop after 5 wrong tries.

Sessions

Logins expire on their own and end for real at logout. A switched-off account is locked out at once.

Operators kept apart

Every database request is tied to one operator. One that can’t say whose data it is gets refused.

Access by role

Field staff see only the screens they are given. Owners see their buildings, never residents’ contacts or IDs.

Private files

Passports, IDs and payment proofs sit in private storage, opened by staff or a link that expires within an hour.

Payments

No card numbers are stored; your payment provider holds them. Payment and messaging keys are encrypted.

Verified notifications

Messages from payment and messaging providers are signature-checked before OmniPM acts on them.

AI access

AI access to resident data is off by default, granted per staff member, read-only, and every lookup is logged.

Roles and access

Everyone sees what their job needs. Nothing more.

Owners never see residents’ contacts, IDs or payment status. Contractors get one job by link and no login. A switched-off account is refused on its next click.

RoleWhat they seeSigns in with

Office staffThe full dashboardPassword or emailed code

Cleaners and field staffTheir own visits and jobs, on a phoneEmailed code

House leadersDuties in the building they live inEmailed code

ContractorsOne job: checklist, photos and hoursA private link

OwnersTheir portal and their buildingsEmailed code

Guests and residentsTheir check-in link or resident portalLink password or code

For your developers

The specific mechanisms, as implemented.

Passwords and codesbcrypt, cost 12. One-time codes: 6 digits, valid 10 minutes, 5 tries, single use.

SessionsSigned JWTs in httpOnly, Secure, SameSite=Lax cookies. Staff 24 h, residents 7 days; logout revokes on the server.

Secrets at restOperator credentials for payments, messaging, Google and e-signature encrypted with AES-256-GCM, never shown again.

Transport and headersHTTPS only with HSTS preload; nosniff, frame and referrer policies; a CSP with a per-request nonce.

FilesPrivate bucket. Opened by a staff session of the same operator, or an HMAC-signed link valid one hour.

API and webhooksAPI keys stored only as SHA-256 hashes, scoped and revocable. Provider payloads signature-checked.

ContractsSigning links carry a 256-bit token stored only as a hash. Signed PDFs sealed and time-stamped (RFC 3161).

RuntimeDocker container running as a non-root user. Migrations applied at start-up; a failed one rolls the deploy back.

Where your data goes

The services OmniPM relies on. Payment and messaging accounts are your own, connected with your keys.

RailwayApplication hosting and the PostgreSQL database

Cloudflare R2Private file storage: IDs, photos, contracts

AnthropicAI: ID and payment checks, drafts, translation

ResendSign-in codes and notification email

Square, PayPal, WisePayments, on your own accounts

LINE, WhatsAppMessaging, on your own accounts

GoogleCalendar, Sheets and Drive, when you connect them

freeeAccounting sync, when you connect it

On the security roadmap

Two-factor sign-in for staff
A published retention schedule for ID photos
An independent penetration test
A published statement on AI and your data

Report a vulnerability

Write to security@omnipm.app with the details and how to reproduce it.

Need a security questionnaire filled in? We’ll walk your team through it on a call.

Apply for the beta