Knowledge — security and privacy

Housing community data security: ten questions to ask a software vendor

A housing community system brings together owner data, financial records, documents, payment information, resolutions and technical cases. Security therefore needs to be more specific than “the data is in the cloud”.

A likely data problem does not always begin with a server attack. It may begin with a settlement sent to the wrong owner, an account retained by a former employee or a file covering every managed community on a private laptop. An administration company needs to know where data is held, who can access it and what happens after an error. This guide concerns housing communities in Poland. It combines GDPR requirements with recommended controls whose scope needs to match the actual processing and risks. It does not describe housing-association law in other jurisdictions.

Software for managing a Polish housing community

Establish the roles for each processing activity

A GDPR data controller and a company described as a property administrator are different concepts. The actual determination of processing purposes and means determines the role, rather than the title of a contract. A company may process community data on its behalf while acting as a separate controller for its own recruitment. Assess the roles for each activity instead of assigning one label to the entire relationship. [1]

Make a simple map covering the community, administration company, software supplier, hosting, accounting provider and technical service. Record what data each receives, for which purpose and on which basis. Where processing on behalf of a controller requires an Article 28 agreement, it needs to match the actual service. An attachment signed years earlier does not explain a new provider or a changed operating arrangement. [1]

Assign a data-protection contact and a substitute. That does not automatically mean that every housing community must appoint a data protection officer; the statutory criteria require a separate assessment. [1] Employees nevertheless need to know whom to contact immediately after misdirected correspondence, a lost device or suspected unauthorised access. The contact must be reachable when the regular case handler is absent.

Inventory the data and avoid unnecessary copies

Follow the actual community workflow: owners, shares, contact addresses, balances, meter readings, resolution records, maintenance reports and correspondence. Identify storage locations as well as the principal software. Data may remain in downloaded spreadsheets, email attachments, shared folders, paper records and phone copies. Without an inventory, you cannot establish the real scope of access and deletion controls.

For each collection, identify the purpose, lawful basis, authorised roles and retention arrangements. The GDPR includes data minimisation, purpose limitation and storage limitation. [1] These principles do not prohibit keeping necessary documentation. They require a reason for retaining particular information and its additional copies. A file that nobody uses but every employee can download creates exposure without an obvious operational benefit.

Do not copy a resident's entire personal story into a maintenance description. Arranging a repair generally needs relevant contact and access details, rather than extensive information about the family. Where a document includes more information than is needed by a particular recipient, establish how to limit further disclosure. An original that must be preserved and a working copy intended for wider circulation may need different access arrangements.

Give access to tasks rather than the entire portfolio

An employee serving one community should not receive access to every property simply because that makes account creation easier. Separate maintenance handling, financial settlements, board access and technical support. Permissions should correspond to the task and the period during which it is performed. This is a practical way to implement risk-appropriate protection, not one role structure mandated for every administration company. [1]

Use individual accounts and an additional authentication factor where the risk and service capabilities support it. Define onboarding, role-change and departure procedures. Grant temporary cover access for a specified period, then check that it has been withdrawn. A shared team password makes it difficult to establish who actually performed a change and complicates revocation when one person leaves.

Periodically compare the account list against the actual team and the communities each employee serves. Check board access after membership changes and supplier support permissions too. Preserve the review outcome and resolve the exceptions. Sending a list to a manager without decisions about unnecessary accounts does not reduce risk. Assign each outstanding item to a named role and confirm when the access change is completed.

Check the recipient before disclosing a document

The premise number, owner name and contact address need to identify the appropriate recipient. For batch communication, preview real recipient-and-attachment pairs and unusual cases. Test ownership changes, co-ownership and shared correspondence addresses. A single shifted spreadsheet row can attach another owner's settlement to every message in a mailing. Checking that the total number of files looks correct will not detect that problem.

An owner's right to inspect the board's activity does not authorise arbitrary distribution of individual settlements. [2][3] On 20 April 2026, UODO reported a PLN 5,000 penalty for a housing community's failure to notify a breach promptly after a settlement was disclosed to an unauthorised person. [3] One misdirected document therefore deserves an actual assessment even when it contains no special-category data.

For higher-risk documents, consider controlled access with authentication instead of a publicly accessible link. Test who can download the document, whether the link can be revoked and what an unauthorised person sees. An obscure URL is not an access control. Test access while logged out and from another community's account. Check attachments, previews and mobile downloads too. A restriction on one screen does not necessarily protect every linked file. When ownership changes, establish which historical documents should remain accessible and to whom. Assess the purpose, entitlement and scope rather than automatically transferring the entire folder to a new account. Provide a workable route for owners who use paper correspondence as well, and check that their documents are not accidentally included in somebody else's envelope.

Verify the supplier and the recovery arrangements

Before implementation, request an account of the service, processors, data locations, support access and any transfers outside the EEA. A European data-centre address does not establish that every operation is confined to the EEA. The GDPR has separate requirements for transfers to third countries. [1] Compare a supplier's statements against the agreement and actual scope of the service.

Establish who creates backups, how long they are retained and who can request restoration. Ask for evidence of a recovery test or run an agreed exercise using test data. Check documents, balances, relationships and permissions after restoration. A file that cannot be opened or linked to the correct community does not meet the practical purpose of recovery, even if the backup job reported success.

Plan termination of the service. You need an agreed export, information about further retention, return or deletion of data, and a check that access has been closed. Do not rely on unsubstantiated statements about compliance, certification or complete security. Verify a specific mechanism, document and test outcome. Software can support protection, but it does not remove responsibility for correctly organising the processing. A company serving many communities also needs to hand over one client separately. Ask whether the export excludes other properties, how attachments are mapped and whether the recipient can read files without the former system's licence. Assign a verification date and role. If the supplier cannot demonstrate this operation, treat it as a gap requiring explanation before migration.

Assess the error and document the response

When an employee discovers a wrong-recipient message, they should notify the assigned contact immediately. Preserve the time, recipients, affected documents and actions taken. Limit further disclosure where possible. Do not begin by deleting messages and history. Evidence is necessary to assess the event, identify its scope and decide which measures can reduce the consequences.

GDPR Article 33 requires notification to the supervisory authority without undue delay, where feasible within 72 hours of awareness, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. A processor informs the controller without undue delay. Breaches must be documented. Communication to the individual under Article 34 depends on the applicable conditions, including high risk and the specified exceptions. [1][4]

The assessment should consider the data, identifiability, recipient, scale and likely consequences. Saying that only one owner was involved does not complete it. Record the reasons for the decision and the responsible person. Missing information does not create unlimited time to wait for an internal investigation. Set a clear escalation path so that a technical uncertainty does not silently become a missed reporting assessment.

Exercise three situations before implementation

First, test whether a former employee can use their old account. Check that access has been withdrawn and that staff can confirm the outcome. Second, assign a test settlement to the wrong recipient and see whether the sending control detects it. Third, assume the supplier is unavailable and establish whether the company can recover documents needed for current service. Use test material rather than actual misdirected owner data.

Record the results, gaps, responsible roles and completion dates. For a small team, a short procedure everyone can carry out is more useful than a lengthy document left in a folder. Repeat relevant controls after changes to suppliers, staff or communication arrangements. An instruction alone is not evidence that a control works. Add an exercise involving a contractor's bank-account change. An employee receives a new number but confirms it through a previously established channel with the appropriate person before updating it. Use fictional details. Check that the procedure protects both the information and payment and records the verification. A message resembling previous invoices should not bypass that control. Preserve the outcome and verify the corrective action, not merely the planned action.

If you are evaluating WM Administrator, use these situations when discussing scope and configuration. View the program description and check its fit with your data-protection process. Ask about specific roles, supplier documentation, export and error handling. Confirmed answers allow you to assess whether the tool meets your company's requirements and those of the Polish communities you serve.

See the security page

What WM Administrator currently communicates publicly

WM Administrator states EU jurisdiction for persistent data, separate housing community contexts, individual roles and MFA for privileged roles, a history of significant operations, complete export and controlled offboarding. Processing details and the current subprocessor list are available in the public legal package.

Do not reduce this to “GDPR compliant by default”. Compliance also depends on the organisation’s own purposes, legal bases, permissions, procedures and use of the system.

Sources and scope

For information only. This is not legal, tax or accounting advice; adapt the procedure to the documents and circumstances of the specific housing community.

Related articles