Last March, a friend who manages three apartment buildings in Pārdaugava called me in a mild panic. The Data State Inspectorate — DVI, Latvia's data protection authority — had sent her a letter. Not a fine, not yet, but a request for information. Someone had filed a complaint about how their personal data was being handled, and DVI wanted answers within two weeks.
She'd been managing buildings on a shared Google Drive and a stack of Excel files. Resident names, personal ID numbers (personas kods), bank account details, payment histories, meter readings — all sitting in folders that four different people could access, with no audit log, no retention policy, and no documentation of why she had any of it. She asked me: "Am I in trouble?"
Probably not the kind of trouble that comes with a fine. But the kind of trouble that means you're doing GDPR compliance the way most property managers in the Baltics do it — which is to say, barely, and mostly by accident.
I spent a weekend helping her get organized, and in the process I learned more about GDPR for property management than I ever wanted to. Here's what I wish someone had told me before she got that letter.
You process more personal data than you think
The first thing I did was sit down with her and list every piece of personal data she handled. This is step one of what GDPR calls a Record of Processing Activities, or ROPA, under Article 30. You don't need one if you're a small operation — under 250 employees and not processing special categories of data — but honestly, do it anyway. It's the document DVI will ask for first.
Here's what we found in her case. Names and personal ID numbers from the land register. Phone numbers and email addresses collected during onboarding. Bank account numbers for direct debit setups. Payment histories going back six years — because she never deleted anything. Utility meter readings for every apartment, every month. Maintenance request photos that sometimes showed the inside of someone's apartment, including a child's bedroom in one case. A WhatsApp group where residents discussed noise complaints, which meant she had records of disputes between neighbors.
That last one surprised her. WhatsApp chats about neighbor disputes contain personal data about people who aren't even her tenants — the neighbor being complained about. If you're saving those messages or using them in any official capacity, that's processing.
The point is: "personal data" in a property management context is broader than most people think. It's not just names and bank accounts. It's consumption patterns, communication records, and sometimes images of the inside of someone's home.
The legal basis question nobody can answer
GDPR Article 6 says you need a lawful basis for every type of processing. There are six options, but for property managers, three actually matter.
Contract (6(b)) covers anything necessary to fulfill your lease or service agreement. Invoicing, payment processing, utility billing — all contract. This is your bread and butter.
Legal obligation (6(c)) covers records you're required to keep by law. In Latvia, the Accounting Law requires you to keep financial records for five years. The Law on Residential Property Management has its own record-keeping requirements. If a law says "keep this," you have your legal basis.
Legitimate interest (6(f)) is the fuzzy one. It covers things like sending payment reminders, communicating about maintenance, running building operations generally. But — and this is the part most managers miss — legitimate interest requires a balancing test. You have to weigh your interest against the resident's privacy rights. If you're sending payment reminders via SMS at 11 PM, that's probably not balanced. If you're using meter reading data to profile which residents are "high consumers" and targeting them with energy-saving tips they didn't ask for, that's probably not balanced either.
What about consent? Technically an option under 6(a), but I'd be careful here. Consent under GDPR has to be freely given, specific, informed, and withdrawable. If a resident has no real choice — because refusing means they can't get utilities — it's not freely given. Use consent for things that are genuinely optional, like receiving a newsletter or using a biometric building entry system. Don't use it as a catch-all.
The practical takeaway: for each type of data you process, write down which legal basis you're relying on. If you can't figure one out, that's a gap. I helped my friend build a simple spreadsheet: data type | purpose | legal basis | retention period. Three columns. It's not fancy, but it answers the question DVI asked.
The retention problem that catches everyone
This is where my friend was most exposed. She had payment records going back to 2019. Six years of invoices, bank confirmations, and resident communication logs. GDPR Article 5(1)(e) says personal data shouldn't be kept longer than necessary. But "necessary" depends on what law applies.
In Latvia, accounting records must be kept for five years under the Accounting Law (Grāmatvedības likums, Section 8). Tax records fall under the same period. So invoice and payment data has a clear retention window: five years, then delete or anonymize.
But what about meter readings? There's no specific legal requirement to keep them beyond the billing dispute window. Most billing disputes in residential property resolve within a year, so keeping readings for three years is more than enough. After that, they're just data you're holding for no reason.
Maintenance request records? Two years after resolution is reasonable. Communication logs? One year. Access logs (who viewed what data and when)? One year is standard for audit purposes.
The problem isn't knowing the retention periods — it's enforcing them. On a spreadsheet, "delete after three years" means you manually find and delete rows. Nobody does this. I've never met a property manager who has a working deletion calendar. The data just accumulates until someone leaves and their successor deletes everything in a panic.
A proper platform handles this with configurable retention rules. You set "meter readings: 3 years" and the system deletes automatically. If you're on spreadsheets, at minimum set a quarterly reminder to review and purge expired data. It's not perfect, but it's better than the default, which is "keep everything forever and hope nobody asks."
When DVI comes knocking
My friend's DVI letter was triggered by a specific resident complaint, but DVI also conducts periodic audits. If you're selected, here's what they typically ask for:
Your ROPA or equivalent documentation of what data you process and why. Your legal basis for each processing activity. Your retention schedule and evidence that you follow it. Your access controls — who can see what data. Your breach response procedure (Article 33 — 72 hours to notify DVI of a personal data breach). And your process for handling data subject rights requests.
That last one matters more than people realize. Under Article 15, any resident can ask for a copy of all personal data you hold about them. You have one month to respond. On a spreadsheet, this means manually searching every file, every email, every WhatsApp chat. My friend estimated it would take her two full days to produce a complete response for one resident. With a proper platform, it's an export button.
Article 17 — the right to erasure — is trickier. A resident can ask you to delete their data, but you can refuse if you have a legal obligation to keep it. Tax records? You keep them for five years regardless of what the resident wants. But communication logs, maintenance request photos, portal activity data — those you should delete if asked, assuming the retention period has passed.
Access controls: the thing that would have saved my friend
My friend's Google Drive had four people with full access. Her Excel files were shared with "anyone with the link." Her maintenance contractor had a login to her invoicing system that could see all resident data, even though he only needed to see work orders.
GDPR Article 32 requires "appropriate technical and organizational measures" to protect personal data. In practice, for a property manager, this means three things:
Role-based access. A maintenance worker needs to see work orders and maybe apartment numbers. They do not need to see bank account details or payment histories. A billing clerk needs invoices and payment records. They do not need to see maintenance request photos. Define roles, restrict access, and review who has what at least once a year.
Audit logging. Every time someone views or edits personal data, the system should log who, what, and when. This is your evidence if DVI asks "who accessed this resident's data and why." Without logs, you're guessing. My friend had no logs at all — she couldn't tell DVI who had accessed the complaining resident's file, because the answer was "anyone who wanted to."
Encryption. Data in transit (HTTPS, always) and at rest. If you're storing resident data in a shared Google Drive with link-sharing enabled, that's not meeting this requirement. Cloud storage is fine if access is controlled and encrypted. Open link-sharing is not.
What I'd do if I were starting today
If I were setting up a property management operation from scratch in Latvia or Estonia, here's my GDPR compliance checklist, in order of priority:
First, audit your data. List every type of personal data you collect, where it's stored, who has access, and why you have it. This is your ROPA, even if you never call it that. Second, define retention periods for each data type. Write them down. Set calendar reminders if you're manual, or configure automatic deletion if your platform supports it. Third, lock down access. Restrict who can see sensitive data. If your current system doesn't support roles, that's a sign you need a different system. Fourth, enable audit logging. If your platform doesn't log access to personal data, you can't demonstrate compliance — and that's the thing DVI actually checks. Fifth, set up a data export process. Test your ability to respond to an Article 15 request. If it takes more than an hour, you need better tooling. Sixth, write a breach response plan. Know who to notify at DVI (in Latvia, datu.valsts.inspekcija.gov.lv), how, and within what timeframe. Practice it once a year.
GDPR compliance for property managers isn't about hiring a lawyer or filling out forms. It's about having systems that respect residents' data rights by default. If your tools make compliance automatic — role-based access, audit logs, configurable retention, one-click data export — you can focus on managing buildings instead of managing legal risk. If your tools are a spreadsheet and a shared drive, you're doing compliance manually, and you're probably cutting corners.
My friend got through her DVI letter without a fine, but only because the complaint was minor and she responded quickly. She's since moved to a proper platform, set up retention rules, and restricted access. The next time DVI writes, she'll have answers in an hour instead of a weekend.
If you're not sure whether your current setup is compliant, start with the data audit. If you can't answer basic questions about who accesses resident data and how long you keep it, you have work to do. The good news is that the right platform makes this work straightforward — and permanent.
If you're managing residential buildings in the Baltics and wondering whether your data handling would survive a DVI audit, try Urbaneta free — 14-day trial, no credit card. Set up one building, check the role-based access controls and audit logging, and see if it covers the gaps in your current workflow.