Access is decided by your relationship to a property.
Crecy holds rent, leases, identities and financial history for organizations that have nothing to do with each other. That makes isolation the first design constraint rather than a feature. This page describes the controls that exist today, in plain terms, and is explicit about what has not been independently assured.
One organization cannot read another's rows.
Every record belongs to an organization, and that ownership is enforced by the database itself — not by application code remembering to add a filter.
Row-level security on every tenant table
Tables carry an organization identifier and a row-level policy that resolves the caller’s own memberships. A query that forgets its filter returns nothing rather than someone else’s data.
The browser can read, never write
Client credentials are granted read access under policy and have insert, update and delete revoked. All writes go through server-side command functions that re-check authorization.
Sensitive tables are not readable at all
Records such as invitations are unreadable even to an authenticated client, and are reached only through functions that return a deliberately sanitized result.
Active context, not ambient access
An operator working in one organization has their session narrowed to it. The narrowing can only reduce what a query sees; it can never widen it.
Isolation is tested, not assumed
The test suite replays the full schema and drives real requests as residents, owners, staff and outsiders, asserting that each cross-tenant attempt is refused.
Server-side entitlements
Plan limits are evaluated on the server. Hiding a control in the interface is not treated as authorization.
A leasing agent should not be able to move money.
Staff access is a role plus, optionally, a set of properties. Permissions are granular — read and manage, per domain — and every command checks the specific permission it needs against the specific property it is touching.
Role-based permissions
Roles carry explicit permissions across property, resident, lease, finance, maintenance, owner and document domains. Reading requires the read permission; writing requires manage.
Property-scoped staff
A staff member can be limited to named properties. Their access to everything else — including reports and search — is narrowed to that scope.
Resident and owner self-service
Residents reach their own tenancy. Owner entities reach the properties they hold an interest in. Both are separate gates from staff access, not a weaker version of it.
Portal access requires an invitation
A resident or owner account only becomes connected to a tenancy or an ownership entity through an invitation the operator issued and the recipient accepted.
Multi-factor for privileged actions
Privileged operations require a session that has completed a second factor. The requirement is checked at the point of the action, not only at login.
Membership changes take effect immediately
Ending a membership ends the access it granted. There is no cached grant that outlives it.
Financial records are append-only, and actions are recorded.
The most useful security property of a rental ledger is that nobody can quietly change what it said last month.
Posted entries cannot be edited
The database rejects an update or delete against a posted journal entry. A correction is a new, balanced reversing transaction, so the original and the fix both remain visible.
Audit events for state changes
Commands write an audit record naming the actor, the action, the resource and a correlation identifier that ties every effect of one request together.
Idempotent commands
Requests carry an idempotency key. A retried or replayed request returns the original result instead of charging, paying or inviting twice.
Private storage, scanned before release, reached by short-lived links.
A lease is one of the most sensitive things an operator holds. Crecy never puts one behind a guessable public URL.
Quarantine, then scan, then release
An upload lands quarantined. It is scanned for malware before it can be read, and a file that fails is rejected rather than delivered. A scan that keeps failing is dead-lettered and surfaced for a human, not retried forever in silence.
Private buckets and access-checked links
Files are stored privately. Access is granted as a short-lived link minted only after the same permission check the rest of the system uses.
Secure delivery links are stored hashed
When a document is delivered by secure link, only a hash of the token is kept, and the token is scrubbed from the delivery queue once the job is finished.
Restricted file types
The accepted document types are constrained, and the same allowlist is enforced at the upload grant, the storage bucket, the import path and the API.
Versions supersede rather than overwrite
Replacing a document keeps the version a resident actually received.
Delivery is recorded
Who a document was sent to, when, and whether they acknowledged it.
Payments
Crecy does not hold resident rent.
Online payments are processed through eligible operators' connected payment accounts under the provider's connected-account model. The operator is the merchant of record for their own rent; the provider's processing charges are the operator's responsibility under those terms.
- Card numbers and bank credentials are handled by the payment provider. Crecy stores provider references, not payment instruments.
- Payment webhooks are signature-verified and processed idempotently, so a replayed event cannot double-post.
- Before confirming, a payer sees the merchant, amount, currency, method, any fee, and whether it settles immediately or pends.
Support access
Support cannot quietly look at your data.
Crecy staff have no standing access to a customer organization. Access requires an explicit, time-boxed support session, and the reads it permits are narrow by construction.
- A support session is opened deliberately, recorded, and ends — one active session per staff member.
- Support access is read-only. There is no support action that writes to your records.
- Support reads go through purpose-built queries returning a fixed, sanitized shape — not raw table access — and a support session grants no bypass of the row-level policies that protect your data.
- Each support read is itself recorded as an audited event.
Collect what the job needs; keep it where it belongs.
Crecy is a rental operations system, so it holds names, contact details, tenancies and payment history. It is designed not to accumulate more than that.
Projections, not raw rows
Residents, owners and vendors receive server-selected projections containing only the fields their screen needs.
No credit or screening data in the pilot
Crecy does not run tenant screening, credit checks or automated housing decisions, and does not store the data that would require.
Operational logs are sanitized
Diagnostic surfaces expose identifiers, states and bounded reason codes — never document contents, storage locations, delivery tokens, message bodies or payment credentials.
Privacy requests are first-class
Access and deletion requests are handled as recorded workflows rather than ad-hoc database edits, and financial records that must be retained are retained deliberately.
Deletion does not rewrite history
Removing an operational record cannot erase the financial history that references it, because that history is append-only.
Regional data handling
Crecy is designed for the United States, Canada and Mexico, with each property carrying its own country, currency and time zone.
What we do not claim
Controls we have built, not assurances someone else has signed.
Everything above describes how the system is built. None of it is an independent audit, and we will not imply otherwise.
- No SOC 2 report. Crecy holds no SOC 2 or equivalent certification, and none of the controls above should be read as one.
- No published uptime figure. We do not quote an availability percentage without monitoring data over a declared period.
- No penetration-test claim. We will state one when there is a signed report with a date, a scope and a remediation record.
- Accessibility is a target. WCAG 2.2 AA is what Crecy is built toward; it is not a conformance claim from an external audit.
- No guarantees. No system is free of downtime, fraud or defects, and a vendor promising otherwise is telling you something untrue.
- Availability is being prepared. North American availability depends on payment, support, privacy and localization gates that are still in progress.