A property agency is a data business that happens to hold keys. Between application forms, lease files and payment records you are holding, for hundreds of people: full names, ID numbers, phone numbers, next of kin, employer details, sometimes bank details, and a complete history of what they earn and when they struggle to pay.
Kenya's Data Protection Act, 2019 sets out obligations for anyone holding personal data like that. This is not legal advice, and if you hold data at scale you should take some. But the practical shape of doing it properly is not complicated.
Collect less
The strongest protection against a data problem is not holding the data. Before adding a field to an application form, ask what decision it informs. Do you need a copy of the ID, or is sighting it and recording the number enough? Do you need the employer's address? Do you need next of kin for every applicant, or only for signed tenants?
Every field you don't collect is a field that cannot leak, cannot be misused by a departing member of staff, and cannot be requested back from you.
Know where it lives
Most agencies cannot answer this quickly, and it is the question everything else depends on. Write the list down: the management system, the shared drive, the WhatsApp groups where scanned IDs get sent, the personal phones with tenant numbers saved, the filing cabinet, the accountant's laptop.
The informal copies are the ones that cause incidents. A scanned ID forwarded to a WhatsApp group so a caretaker can confirm someone is a resident is now on an unknown number of devices, for good.
Limit who can see what
A caretaker logging a repair does not need the ledger. A cashier does not need employment details. Give each role the narrowest access that lets them do the job, and remove access the day someone leaves, not at the end of the month.
Shared logins make this impossible and should be the first thing to go. If four people use one account, you have no access control and no ability to say who did anything.
Keep a trail, and don't let it be edited
Being able to show who changed what, and when, is both a data protection measure and an ordinary business control. A record that can be silently altered is not evidence of anything. Corrections should be new entries that leave the original visible, not overwrites.
Say what you do, and be able to honour it
People whose data you hold can ask what you have about them, ask you to correct it, and ask you to delete it where you have no lawful reason to keep it. Two practical consequences: you need a retention position: how long you keep the file of someone who applied and was not offered a unit, or a tenant who left three years ago. You also need to be able to find everything about one person when asked.
When something goes wrong
Have a plan before you need it. Who is told, in what order, and how quickly. An incident handled openly and fast is a bad week. The same incident discovered by the affected people first is a different kind of problem entirely.
The short version
Collect less than you think you need. Know every place it lives, including the informal ones. Give people the narrowest access that works. Keep a trail nobody can quietly edit. Decide how long you keep things, and then delete them.
Software helps with the middle three. The first and the last are decisions, and they are yours.
The obligations, in the terms the Act uses
Kenya's Data Protection Act, 2019 is not written for property, but the duties it creates map onto an agency's day fairly cleanly. Again: not legal advice, and worth taking advice if you hold data at scale.
You are probably a data controller. If you decide what tenant data is collected and why, you are the controller, and the responsibility stays with you even when the data sits in someone else's software. Your management system provider is generally a processor acting on your instructions, which is why what they will sign matters.
You need a lawful basis for each thing you collect. Most tenancy data is held because it is necessary for a contract, since you cannot run a tenancy without knowing who the tenant is. Marketing is different and usually rests on consent, which means a tenancy does not entitle you to market to someone forever.
Purpose limitation binds you to the reason you collected it. Data taken to run a tenancy is not data you may pass to a friend vetting an applicant, sell to anyone, or use to build a list.
Data minimisation is a duty, not just good practice. Collecting a field you cannot justify is itself the problem, before any leak happens.
Accuracy matters, and people can require you to correct what is wrong.
Storage limitation means holding data only as long as the purpose requires, which is the whole subject of what to keep, and for how long.
Security is proportionate to sensitivity. You hold ID numbers and income histories for hundreds of households. That is not a low-risk holding.
Registration may apply. Controllers and processors above certain thresholds are required to register with the Office of the Data Protection Commissioner. Whether it applies to you depends on your size and activities, and it is a specific question worth asking rather than assuming.
Cross-border transfers have conditions. If your software stores data outside Kenya, as most cloud systems do, that is a question to put to your supplier in writing before you sign, not after an incident.
What tenants and applicants can ask you for
People whose data you hold have rights, and the practical test of an agency's housekeeping is how long it takes to honour one. The requests you will actually receive:
- "What do you hold about me?" You have to be able to find everything about one person, across the management system, the shared drive, email and paper. Agencies that cannot answer this quickly are usually the ones with data in five informal places.
- "Correct this." A wrong ID number, an outdated phone number, an employer they left.
- "Delete it." Honoured where you have no lawful reason to keep it, declined with a stated reason where you do: an open balance, a tax obligation, a live dispute.
- "Stop sending me marketing." Distinct from deleting the tenancy file, and it must actually stop, including on any list a third party sends on your behalf.
- "Give me my data in a usable form." Portability, where it applies.
Two operational habits make these survivable: a single index of where personal data lives, and one named person responsible for handling a request. Both cost nothing before a request arrives and are impossible to assemble after one does.
The incidents that actually happen in property
Not exotic. These five, repeatedly:
ID copies in WhatsApp groups. Sent so a caretaker can confirm a resident, and now on an unknown number of devices permanently. The fix is to stop needing the copy: sight the ID, record the number, and give the caretaker a resident list rather than documents.
Shared logins. Four people on one account means no access control and no ability to say who did anything. It is also the reason a departing staff member's access is still live three months later.
The departing employee's device. Tenant numbers, photographs of meter readings, an exported spreadsheet in a personal drive. Offboarding should include revoking access the day they leave and confirming what they held.
The application form that collects too much. Employer address, next of kin, ID copy, payslips, collected from everyone who enquires rather than from the person actually offered the unit. Move the heavy collection to the point of offer, and most of the risk disappears.
Vendor sprawl. Tenant lists pasted into a bulk SMS tool, a survey service, a chat product. Each is a transfer to a third party, and each should be a decision rather than something one person did on a Tuesday.
Practical security that fits a property business
- One login per person, with a password manager. No shared accounts.
- Two-factor authentication on the management system, email and anything holding money.
- Access by role: a caretaker logs repairs and cannot see the ledger; a cashier posts payments and cannot see employment details.
- A leavers' checklist, run on the last day rather than at the end of the month.
- Encryption on laptops and phones that hold tenant data, and a screen lock everywhere.
- Backups, tested by actually restoring one. An untested backup is a belief.
- An audit trail nobody can edit, which is a data protection measure and a business control at the same time. See a paper trail that survives a question.
- A written incident plan: who is told, in what order, how fast. The Act contemplates notification where a breach poses a real risk, and the time to work out what that means is not the day it happens.
Role-based access, the audit trail and one system of record instead of five informal copies are precisely what property management software built for Kenya should be giving you. The first duty and the last, collecting less and deleting what you no longer need, stay decisions, and they remain yours.
Common questions
Does the Data Protection Act apply to a small landlord?
The Act applies to the processing of personal data generally rather than only to large organisations, though registration obligations depend on thresholds and activities. A landlord holding ID numbers and payment histories for several households is holding personal data, whatever their size.
Can I share a tenant's details with another landlord?
Not as a matter of course. Data collected to run a tenancy was not collected to inform someone else's letting decision, and passing it on without a lawful basis is exactly the purpose-limitation problem the Act describes.
Do I need to keep a copy of a tenant's ID?
Ask what the copy does that sighting the document and recording the number does not. Where the copy is genuinely necessary, hold it in the management system with restricted access rather than in a shared folder or a chat group.
What should I do if tenant data leaks?
Work the plan you wrote in advance: contain it, establish what was affected and who, notify as the Act requires and inform the people affected, then fix the cause and record what happened. Handled openly and fast it is a bad week; discovered by the affected people first it is something else.
Who is responsible if my software provider has a breach?
You remain responsible to your tenants as the controller, which is why what the provider will commit to in writing matters before you sign: security measures, sub-processors, where data is stored, and what happens on exit.
How long can I keep an unsuccessful applicant's file?
Only as long as the purpose requires, which for someone you did not house is usually short. It is the most commonly over-retained category in property, and the easiest one to fix.