Renting Out as a Team – Roles, Workflows, and Data Protection

From the outside, renting out a flat looks like a one-person job: post the ad, run a viewing, sign the contract. In reality, every flat carries a dozen small decisions – who writes the listing, who answers the twenty enquiries on the first evening, who sorts the applications, who runs the viewing, who decides in the end. The moment more than one person is involved – a Hausverwaltung (property management) firm with several case handlers, a WEG (Wohnungseigentümergemeinschaft — homeowners' association) with a manager, an owner couple, an agent acting on instruction – "doing" turns into "coordinating." And that's exactly where the typical friction appears: duplicate work, contradictory commitments, lost information – and data protection mistakes that can get expensive.

This guide sorts out the three layers a rental team has to keep under control at the same time: roles (who does what), workflows (how it fits together without anything being done twice or not at all), and data protection (who is even allowed to see which applicant data). The legal side isn't an afterthought here – it's central, because tenant applications contain highly sensitive data, and the GDPR turns "who may see this?" into an obligation, not a nice-to-have.

Why renting out rarely runs solo#

Even a single re-letting generates a surprising mountain of micro-tasks. Write and photograph the ad, organize reach, answer enquiries, screen applications, check creditworthiness and self-disclosure, coordinate viewings, decide after the viewing, send rejections, draft the contract, schedule handover. In a firm managing fifty units, several such processes run in parallel – and every one of them touches the personal data of people who have applied.

As soon as two or more people are involved, three risks appear at once: duplicate work (two people answer the same enquiry), information loss (a colleague doesn't know an applicant has already been promised the flat), and data protection sprawl (self-disclosures land in a shared mailbox everyone can read). The good news: all three can be defused with the same two tools – clear roles and a single, up-to-date shared view. That's the thread running through this article.

Allocating roles sensibly#

The most important decision is made before the first ad goes live: who is responsible for what? A clean allocation of roles isn't bureaucracy – it's speed. Everyone knows what to do, and nobody waits on anyone else. Four roles are enough for most teams:

1. Advertiser / first impression. Responsible for the listing, photos, description, and the quick first response to enquiries. This person shapes who applies in the first place – a good ad attracts a fitting pool and saves screening work later. The good rental listing guide covers how to do it.
2. Screener / shortlist. Goes through the applications, checks completeness, creditworthiness, and self-disclosure against criteria defined in advance, and proposes a shortlist. Consistency is decisive here – arbitrary gut calls aren't just unfair, they can become legally risky on discrimination grounds. The article on choosing tenants explores which criteria are permitted and sensible.
3. Viewer / on site. Runs the appointments, answers questions about the flat, gathers impressions. This role needs the fullest data access at the moment of the appointment – but only then, and only for the people invited.
4. Decider / sign-off. Makes the final choice and drafts the contract. In a WEG or with several owners, this is often not one person but a coordinated resolution – which raises the question of data protection responsibility directly (more on that below).

In small teams, one person takes on several roles – that's perfectly fine. What matters isn't the number of heads but that, for every task, it's clear who owns it and who steps in when they're away.

Collaboration without duplicate work or information loss#

Roles answer "who." Workflows answer "how does it fit together." The enemy here isn't malice but the gap: two people who know nothing of each other reliably produce chaos. Three principles keep a team in sync:

• One shared view instead of scattered truths. Applications, status (screened / invited / rejected / accepted), and notes belong in one place that everyone involved can see – not across five private mailboxes and three WhatsApp chats. Scattered information is the main source of contradictory commitments.
• Status instead of memory. Every application has a clear status at any point in time. Whoever touches an enquiry leaves a trail – so the next person knows what's already happened without asking. That prevents the double rejection just as much as the double acceptance.
• Clear handover points. The roles need defined interfaces: when does screening hand off to viewing, when does viewing hand off to the decision? Without those points, applications stall – or get worked on by two people at once.

Who's allowed to see which applicant data?#

Now for the core – and the point where many teams unknowingly break the law. A tenant application contains a concentration of sensitive data: name, address, income, employer, creditworthiness, sometimes bank statements. The GDPR requires that only the people who need it for their task have access – the so-called need-to-know principle. An access-rights concept that records who may access which data is mandatory as a technical and organizational measure under Art. 5 and Art. 32 GDPRQuelle.

In concrete terms for a rental team: the person running the viewing must see the contact details of the invited applicants – but not necessarily the bank statements of every rejected enquiry. The person at the front desk coordinating appointments needs names and times, not income proofs. Access isn't a status symbol; it's a function of the task.

Equally important: how much is even collected depends on the phase. Data protection law allows applicant data to be gathered in stages – not all at once just because it's convenient:

1. Before the viewing, only general contact data is permitted – name, address, phone, email. The legal basis is legitimate interest (Art. 6(1)(f) GDPR). Questions about marital status, nationality, or the previous landlord are generally impermissible at this stage.
2. Once there's concrete rental interest, creditworthiness-relevant details may be added – the classic self-disclosure.
3. Only at the contract decision may proof be requested: income statements, creditworthiness evidenceQuelle.

Special categories under Art. 9 GDPR – religion, ethnicity, health, union membership, sexuality – are generally taboo and must even be redacted from submitted documents. And: the data of rejected applicants must be deleted once it's no longer neededQuelle.

Need-to-know principle

is therefore not just theory but the yardstick a team must use to align its access rights.

Joint controllers or data processing on behalf?#

The moment an external service provider joins in – an agent, an external manager, an IT service – a question arises that many overlook until the supervisory authority asks: in what data protection role does this third party act? There are three possible answers, and they entail different contracts.

• Own controller. Whoever determines the purpose and means of the processing themselves is their own controller. A property manager acting within their original duties is usually a controller in their own right – not merely an extended armQuelle.
• Joint controllers (Art. 26 GDPR). When two parties jointly determine the purpose and means of the processing, they are joint controllers. Art. 26 GDPR then requires an agreement that transparently allocates responsibilities – and whose essence must be made available to the data subjectsQuelle.
• Data processing on behalf (Art. 28 GDPR). If the third party acts purely on your instructions, without its own decision about purpose and means, you have Auftragsverarbeitung (data processing on behalf / DPA). A data processing agreement is then mandatoryQuelle.

The classification is case-by-case – there's no blanket pigeonholeQuelle. A practical rule of thumb: if the provider only executes what you decide (e.g. an IT system that stores applications), much points toward processing on behalf plus a DPA. If they help decide on substance (an agent who selects independently and sets criteria), joint controllership with an Art. 26 agreement may apply.Auftragsverarbeitung

Whoever helps decide the "why" and "how" of the processing is a controller – whoever merely executes is a processor. This one question determines which contract is missing when the supervisory authority comes knocking.

Clear responsibilities as protection against mistakes#

Roles and responsibilities aren't just about efficiency – they're the best error prevention a team has. Most data protection and letting mishaps don't happen out of bad faith but because no one felt responsible. The self-disclosure nobody deleted because it was unclear who owned it. The acceptance two people gave at once because no one kept the status. The access rights of the departed colleague that nobody revoked.

Three responsibilities should be explicitly assigned to one person in every team:

1. Data ownership. One person is responsible for ensuring applicant data sits in the right place, access is separated by role, and rejected applications are deleted on time. Access rights must be reviewed at fixed intervals and revoked immediately on departure – a defined offboarding process is not optional under Art. 32 GDPRQuelle.
2. Decision authority. One person (or a defined body) makes the final acceptance. That way there are never two parallel commitments – and the applicant gets a clear point of contact.
3. Communication authority. One voice to the outside per application. Applicants shouldn't hear contradictory things from two team members.

Handovers and cover#

Every team has gaps: holidays, illness, weekends, staff changes. But a letting doesn't wait – the right applicant gets in touch exactly when the responsible colleague is away. Without arranged cover, one of two things happens: the application stalls (and the applicant is gone), or someone outside the role accesses sensitive data in an unregulated way (a data protection problem).

Both are solved by the same preparation: for every role it's clear in advance who steps in if someone is out – and that cover person has the necessary access then, not permanently "just in case." This is exactly where data protection meets practicality: cover access is legitimate when the task requires it, but it must be kept narrow and traceable. With a staff change, the reverse applies: the departing person's access rights are revoked immediately, the shared view remains – the knowledge stays in the team, the access goes with the role.

Team setup in 5 steps#

1. 1

   Name the roles

   Define who advertises, who screens, who shows, and who decides – even if one person takes on several roles. Write it down; verbal arrangements don't survive the first stressful letting day.

2. 2

   Create one shared view

   Applications, status, and notes belong in one place that everyone involved can see – not in private mailboxes. Invite colleagues deliberately instead of forwarding documents around.

3. 3

   Separate access by need-to-know

   Everyone sees only what their task requires. Define a simple access-rights concept and review it at fixed intervals – especially on departures and role changes.

4. 4

   Classify the external role under data protection law

   If you bring in an agent or external manager, clarify first: own controller, joint controllers (Art. 26), or processing on behalf (Art. 28)? Put the right contract in place before data flows.

5. 5

   Define cover and deletion

   Assign cover for every role and one person for data ownership – including timely deletion of rejected applications and offboarding on staff changes.

How WOHNO supports working as a team#

The three levers of this article – shared view, roles, access restriction – are exactly the problems a team feature is built for. On WOHNO you invite colleagues into your rental team instead of forwarding applications by email. Everyone works from the same up-to-date view: who screened, invited, or rejected an application is visible to the team – the double acceptance disappears. And because applicant data sits in one place rather than in five private mailboxes, access can be steered sensibly in the first place.

This replaces neither data protection advice nor a DPA – but it removes the structural main source of team mishaps: scattered truths. For how to organize applications and viewings beyond that without anything stalling, see the article on organizing applications and viewings.

Rent out as a team – with a shared view instead of scattered mailboxes

Invite colleagues, work from one up-to-date view, and keep track of who's handling which application. That's how you avoid duplicate work and keep control over sensitive data.

Set up your team

FAQ – frequently asked questions#