RBAC and Audit Trails for Regulated Apps: Lessons from Real Estate

When an app handles money, legal documents or personal records, "who can do what" stops being a UI concern and becomes the core of the product. A buyer must never see another buyer's documents. A realtor sees their clients' files but can't sign on their behalf. And when something goes wrong, someone will ask: who changed this, when, and why?

Role-based access control (RBAC) answers the first question; audit trails answer the second. This guide covers how to design both for regulated apps, using a real estate closing platform as the running example, because closings involve several parties, sensitive documents and strict expectations about evidence.

Key takeaways

• Model roles around real responsibilities, then map them to fine-grained permissions, not the other way round.
• Scope permissions to resources: a role on this transaction, this organisation or this file, not a global role.
• Enforce permissions on the server for every request; the app only hides what users can't do.
• Audit logs should be append-only, record who, what, when, where and before/after values, and be protected from tampering.
• Design for evidence: exports, retention rules and clear history views for support and compliance.

Roles, permissions and scope

A simple RBAC model has three parts:

The key insight for multi-party apps is scoped roles: a person isn't "a realtor" globally; they're the buyer's realtor on transaction A and have no role on transaction B. Store memberships as (user, role, resource) and check permissions against the resource being accessed.

Designing permissions that hold up

• Start from actions, not screens. List every sensitive action (view, upload, sign, approve, share, delete) and decide which roles may perform it at each stage.
• Include state: some actions are only allowed at certain stages (documents lock after signing).
• Prefer deny by default: new endpoints start closed until permissions are defined.
• Centralise checks in a policy layer or middleware, so every endpoint uses the same rules.
• Test permissions explicitly, with automated tests that try forbidden actions for each role.

Enforcement: server first, always

The mobile app hides buttons a user can't use, which is good UX. But every API request must be checked on the server, against the user's membership for that specific resource. In multi-tenant systems, add database-level isolation (such as row-level security) underneath, so a missing check in application code can't expose another customer's data.

From the field: On Expetitle, a digital real estate closing platform in Miami later acquired by The Real Brokerage (NASDAQ: REAX), I built mobile and web experiences for buyers, sellers, realtors and brokers to run a residential closing end to end, with secure document warehousing, e-signature and remote-notarisation handoffs, milestone reminders and role-scoped dashboards for four stakeholder types, all to escrow-grade standards: RBAC, audit trails, encrypted storage and careful PII handling.

Audit trails that are actually useful

An audit log records security-relevant and business-relevant events. Each entry should capture:

Store logs append-only: no updates or deletes from application code, separate permissions for writing and reading, and protection against tampering (for example, a write-once store or hash chaining). Log access to sensitive records, not only changes, because "who viewed this document" is often the question that matters.

Making the history visible

Audit data is most valuable when people can use it:

• A timeline per transaction showing key events in plain language, visible to the parties involved.
• Admin search across logs for support and compliance teams.
• Exports for regulators, disputes or customers' own records.
• Retention policies that match legal requirements, with deletion handled deliberately.

Privacy alongside auditability

Audit trails and privacy can pull in opposite directions: you need evidence, but you shouldn't hoard personal data. Log identifiers rather than full personal details where possible, restrict who can read logs, encrypt sensitive fields, and define how account deletion interacts with records you're legally required to keep.

Delegation and temporary access

Real workflows include people acting for others: an assistant uploading documents for a broker, a support agent viewing an account to help a customer, an attorney added for one stage of a closing. Model these explicitly instead of sharing logins. Give delegated users their own identity with a scoped, time-limited grant, record "acting on behalf of" in the audit log, and make support access visible to the customer where appropriate. Expiring grants automatically removes the most common source of permission creep, access that outlives the reason it was given.

Common mistakes

• Global roles where scoped roles are needed ("realtor" across all transactions).
• Permission checks only in the app, or only on some endpoints.
• Audit logs that are mutable, incomplete or never reviewed.
• Logging full documents or secrets into audit or application logs.
• No tests for forbidden actions, so a refactor quietly opens a door.

FAQ

What is role-based access control (RBAC)?

RBAC grants permissions to roles (such as buyer, realtor or admin) rather than to individual users, then assigns users to roles. In multi-party apps, roles are usually scoped to a resource, such as a specific transaction or organisation, so a person can have different roles in different contexts.

What should an audit trail include?

Who performed the action (and in what role), what they did and to which resource, when, from where (IP or device), and before and after values for changes. For sensitive data, also log who viewed it. Store entries append-only and protect them from tampering.

Should permissions be enforced in the app or on the server?

On the server, for every request. The app can hide actions a user can't take, which improves the experience, but only server-side checks protect data. In multi-tenant systems, add database-level isolation as a second layer.

How long should audit logs be kept?

It depends on your industry and jurisdiction. Regulated sectors often require several years. Define a retention policy with legal advice, apply it automatically, and make sure deletion requests are handled consistently with what you're required to keep.

Next steps

If you're building an app that handles documents, money or sensitive personal data, I can design the roles, permissions and audit trail with you so they hold up to customers, auditors and acquirers. Get in touch, or see how I work as a full-stack developer.

Sources

• OWASP Authorization Cheat Sheet, OWASP
• OWASP Logging Cheat Sheet, OWASP
• Role-based access control, NIST
• Row security policies, PostgreSQL docs