Security & access
The contents of a significant home are sensitive by nature: where the safe is, who holds a key, what the gate code is, what a system cost. Wrenmont is designed on the assumption that this information must be narrowly held and that every access to it should be accountable.
Organization isolation
Role-based access
Private documents
Accountable history
Every record belongs to exactly one organization, and that boundary is enforced by the database's own row-level policies rather than by application code that could be bypassed. A query that reaches for another organization's property returns nothing — there is no code path that widens it.
Portfolio admin, property manager, field user and owner each see a different amount of the record. Access can be narrowed further to individual properties, so a caretaker responsible for one house does not see the rest of the portfolio.
Alarm codes, key locations, security procedures and confidential documents carry a sensitivity level. Raising the level narrows who can read the item, including inside the organization that owns it.
Files live in private storage. A file is reached through a short-lived, permission-checked link issued for one request; there is no open URL to guess, share by accident, or leave behind in a forwarded email.
Changes are recorded with the actor, the field-level difference, the timestamp and the property. Audit entries cannot be edited or deleted by anyone using the application — the database rejects the attempt.
Extraction from documents produces proposals, not records. A person reviews each one before it becomes part of the authoritative account, and document content is always treated as untrusted input rather than as instructions.
Team, owner and field users sign in through their own doors and land in the experience built for them, but they are governed by the same permissions. Nothing about a separate entrance grants separate rights.
An executive property summary can be shared with someone who has no account through a private link. The link points at a published snapshot, can carry an expiry, and can be revoked at any time.
Where it is held
The operating record lives in a database provisioned only for Wrenmont, not in a pool shared with other products. What a person may see is still decided by the rules above. The measures below are how the record is stored, moved, and kept off a page that anyone can read.
Each Wrenmont project has its own isolated database, identity service, and private file store. Another product on the same builder cannot reach these rows. Organization boundaries inside Wrenmont are still enforced by row-level policies in that database.
Disks that hold the record and its files are encrypted at rest. Connections to the application and to the database use TLS. Backups are stored encrypted. These are the host defaults; they do not replace the access rules on this page.
Payment keys and service credentials live in a server-side secret store, encrypted, and are used only by server functions. They are not shipped in the page the browser loads, not written into logs in plaintext, and not pasted into the record itself.
The builder and the database host each maintain SOC 2 Type II and ISO 27001 programs for their own infrastructure. Those attestations are theirs. They are not a Wrenmont certification, and they are not a substitute for invitation-only access or for the policies that keep one organization out of another.
We would rather answer them before you start. Ask in your access request and we will address them directly.
