Who owns your member data? A checklist for boardsWho owns your member data? A checklist for boards

Ask a vendor who owns your member data and the answer is always you do. Ask how you would get it out, in what shape, and whether the system would still work afterwards, and the answers get longer. Ownership is not a line in a contract. It is a set of practical facts, and a board can check them.

The checklist below applies equally to an AMS you rent, the association management system that holds members, and to a platform a studio builds for you. Ask it of both, and compare.

The checklist

1. Whose name is on the accounts? The database, the hosting and the domain. If they are in a vendor's or a studio's name, you are a tenant. Ask for them to be in the association's name from day one.
2. Can you get a full copy of the data today? Not a report. A complete export, every table, in a standard format. Ask how long it takes and what it costs. If the answer involves a support ticket and a fee, note it.
3. Is the data in a standard database? PostgreSQL, MySQL or similar, which any developer can read, or a proprietary format only the vendor understands? Standard means portable. Proprietary means the export is all you will ever get.
4. Who else can see it? Which of the vendor's staff, which subcontractors, which other systems it is copied to. Ask for the list in writing.
5. Are member permissions enforced in the database or only in the screens? If a member can see only their own record because the screen hides the rest, a bug exposes everything. If the database itself refuses, it does not.
6. Where are the backups, and have you ever restored one? Daily backups are common. A tested restore is rare. Ask when it was last done.
7. Do you own the code? For a rented system, no, and that is normal. For a custom platform, the answer must be yes, with the source in a repository you control.
8. What happens if the vendor or studio disappears? For a rented system: the export, and a migration project. For a custom platform on an open stack: another team takes over the code. Ask for the written handoff document either way.
9. Can you leave without breaking the website? If the website and the member system are separate products from separate vendors, leaving one breaks the other. If they are one platform you own, there is nothing to leave.
10. Is any of this in the contract? Ownership of data, code and accounts; export rights; handoff obligations. If it is not written, it is not agreed.

How the answers usually go

Ask the checklist of a rented system and the pattern is consistent. The accounts are the vendor's. The export is a report or a support ticket, in the vendor's format. The database is theirs, and nobody outside the vendor has seen its shape. Permissions are enforced in the screens. Backups exist; restores have not been tested by you. Code is theirs, and the website is somebody else's product, so leaving one breaks the other. The contract says you own the data and says nothing about how you would get it.

Ask the same questions of a custom platform built properly and the answers are short. The accounts are the association's. The export is a command. The database is PostgreSQL. Permissions are enforced by the database. Backups are daily and the last restore is dated. The code is in the association's repository. The website and the member system are one thing, so there is nothing to leave. The handoff is written.

Neither set of answers is a moral judgement. A rented system is honest about being rented, and for many associations that is fine. The failure is a board that believes it holds the second set of answers when it holds the first.

Reading the answers

No system scores perfectly, and a rented AMS will honestly fail several of these by design. That is fine if the board knows it. The problem is a board that believes it owns the data because the contract says so, and finds out otherwise on the day it tries to move.

A custom platform should score well on all ten, or the studio building it is not doing what it says. Accounts in your name, a standard database, source code in your repository, permissions enforced in the data layer, and a written handoff are not extras. They are the reason to build rather than rent.

Putting it in the contract

Whatever the answers, write them down. A short schedule to the agreement, one line per question, turns a vendor's reassurance into an obligation and a studio's promise into a deliverable. Ownership of code, data and accounts; the export format and how long it takes; the handoff document and when it is delivered; who holds backups and how a restore is tested. Ask for it before signing. A partner who owns your system in practice will not mind putting that in writing. One who does not will find reasons to delay.

One more question

Ask who wrote the privacy policy your members see, and whether it describes the systems you actually run. Members are increasingly asking, and the board is the answer.