# Building an access and permissioning model for property data
A single rent roll file, one spreadsheet with unit numbers, tenant names, lease terms, and rent amounts, sits at the center of a leasing dispute, a loan covenant test, and a quarterly audit, all in the same week. The broker who needs it to market a vacancy should never see the confidential lease concession negotiated with the anchor tenant. The lender's analyst who needs occupancy percentages should not see individual tenant names. The auditor needs everything, but only for the fiscal period under review. One file, four very different views. If your access model can't produce that, you have a governance gap, not a technology gap.
Real estate data is unusual because it blends three sensitivity layers in one document:
A generic "confidential spreadsheet, email it carefully" habit does not hold up once a portfolio has 50 properties, four broker relationships, two lenders, and an annual audit. You need role-based access control (RBAC), a system where permissions attach to a role (asset manager, leasing broker, lender, auditor) rather than to an individual person, so access rules survive staff turnover.
Start by inventorying who touches the rent roll and valuation file, and what decision each role is making with it.
| Role | Needs | Must not see |
|---|---|---|
| Leasing broker | Vacant unit specs, asking rents, comparable lease terms for units they're marketing | Other tenants' actual rents, security deposit amounts, tenant financial covenants |
| Asset manager | Full rent roll for their assigned assets, lease expirations, tenant credit notes | Portfolio-wide data outside their assigned assets |
| Lender / loan servicer | Aggregated occupancy, debt service coverage inputs, covenant compliance fields | Tenant PII, unit-level lease negotiation history |
| Auditor | Full historical detail for the audit period, with change logs | Live, unlocked editing rights; anything outside the audit window |
This is a field-level and row-level permissioning problem, not just a file-sharing one. Field-level means restricting specific columns (hide the "lease concession" column from brokers). Row-level means restricting specific rows (an asset manager sees only their 12 buildings, not the other 40 in the fund).
The mistake most firms make is keeping four separate spreadsheets, one per audience, that quietly drift out of sync. The fix is one authoritative dataset with permissioned views layered on top, typically enforced in a database or a BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.View full definition → tool like Tableau or Power BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.View full definition →, not by manually deleting columns before each email.
A simplified access rule set might look like this in pseudocode, the kind of logic a data or IT team would implement in the underlying system:
IF role == "broker" AND asset_status == "vacant":
SHOW asking_rent, unit_size, lease_term_offered
HIDE tenant_name, concession_value, security_deposit
IF role == "lender":
SHOW occupancy_pct, noi_aggregate, covenant_flags
HIDE tenant_name, unit_level_rent
IF role == "auditor" AND period IN audit_scope:
SHOW all_fields
LOG every_access_eventThe point isn't the syntax, it's the principle: access rules are written once, against roles, and the system enforces them consistently, rather than relying on someone remembering to redact column F before sending.
This isn't just good practice, it intersects with real legal obligations:
A good starting reference for GDPR's core principles is the ICO's guide to data minimization, useful even outside the UK as a plain-language explainer.
Knowledge check
1. Why does role-based access control (RBAC) hold up better than a 'confidential file, share carefully' approach as a portfolio scales?
2. A rent roll file contains commercially sensitive lease terms, tenant PII, and regulated financial data feeding loan covenants. What is the core governance challenge this creates?
3. A lender's analyst needs occupancy percentages to test a loan covenant but should not see individual tenant names. What principle does this scenario illustrate?
4. Select ALL correct answers about the sensitivity layers blended into a single rent roll or valuation file.
Select all the correct answers.
5. Select ALL correct answers about why a leasing broker's access should differ from an auditor's access to the same underlying property data.
Select all the correct answers.
An access model is only as good as the audit that verifies it's working. Three checks worth running quarterly:
1. Access log review. Every view of the rent roll should generate a timestamped log: who, what fields, when. Pull the log and check for anomalies, a broker account querying tenant PII fields it shouldn't have access to, or an unusually high volume of exports right before that broker left the firm.
2. Permission drift test. Roles change. An asset manager gets promoted, a broker's contract ends. Run a quarterly reconciliation: current active permissions against current active roles. A common finding: former employees or contractors retaining live credentials for 30 to 90 days after departure, an estimate based on common findings in access audits, not a hard figure.
3. Field-level exposure test. Pick a sample export from each role's view and manually confirm the restricted fields are actually absent, not just hidden or grayed out in the UI (a hidden column in Excel is still extractable data; a genuinely restricted field never leaves the query).
A simple worked example: if your portfolio has 40 properties, 4 broker relationships, 3 lenders, and 1 annual audit cycle, that's a minimum of 8 distinct permission sets to test (4 broker views may differ by assigned building, 3 lender views by loan covenant terms, 1 audit view). Testing each takes roughly 15 to 30 minutes manually, call it 2 to 4 hours per quarter for a mid-sized portfolio, an estimate, but it illustrates that this is a bounded, schedulable task, not an open-ended burden.
🎬 [VIDEO: "Role-Based Access Control Explained" - https://www.youtube.com/results?search_query=role+based+access+control+explained - A concise walkthrough of RBAC concepts applicable directly to permissioning shared property datasets]
The most common real-world failure isn't malicious, it's convenience. A property manager exports the full rent roll to a personal email to work on it over the weekend. A broker forwards a shared file link that has no expiration date. A lender's junior analyst gets CC'd on a thread with the unredacted valuation model attached.
None of these violate an access model that exists only on paper. They violate one that's actually enforced at the system level, expiring links, forced re-authentication, export logging, and disabled forwarding on sensitive fields. The technology (permission-aware BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.View full definition → tools, data rooms with audit trails like Intralinks or DealRoom, used heavily in real estate transactions) exists specifically because email attachments cannot be un-sent.