This article is general guidance, not legal advice. For decisions about your own obligations, speak to a solicitor or data protection adviser, and see the guidance published by the Data Protection Commission.
If your software holds personal data about customers, staff or members, data protection law applies to how it is built and run. Thinking about it early costs far less than fixing it later. Here is a practical checklist to work through with whoever is building your system.
1. Know what personal data you hold, and why
List the personal data the system will store: names, emails, addresses, health information, anything that identifies a person. For each, note why you need it and which legal basis you rely on. If you cannot explain why you hold something, you probably should not.
2. Collect less
The safest data is data you never collected. Ask of every field: do we genuinely need this? Fewer fields mean less risk, less to secure and less to delete.
3. Control who can see it
Access should follow job roles. Staff should see only what their work requires. Make sure the system supports separate roles, and that access is removed promptly when someone leaves. (See security basics.)
4. Decide how long you keep it
Data should not be kept forever. Decide retention periods and make sure the system can actually delete or anonymise information when the time comes.
5. Handle people's rights
Individuals can ask what you hold about them, ask for corrections, and in some cases ask for deletion. Can your system find everything about one person quickly? Can it remove it? Test that before the first request arrives.
6. Check who else touches the data
Hosting providers, email services and other tools that process personal data on your behalf need proper agreements, and you should know where data is stored. Ask your developer and host to explain this plainly.
7. Build in security
Appropriate technical and organisational measures include sign-in controls, encryption in transit, validation of inputs, regular updates and tested backups. The right level depends on how sensitive the data is.
8. Be ready for a breach
If a breach affecting personal data occurs, you may have to notify the Data Protection Commission within 72 hours of becoming aware of it, and in some cases tell the individuals affected. Know who decides, who is contacted, and how the system records what happened. An audit trail makes this far easier.
9. Document your decisions
Keep short, clear records of what data you hold, why, who can access it, how long you keep it, and the measures in place. Writing it down also exposes gaps.
10. Tell people what you do
Privacy notices should be clear, accurate and easy to find, and reflect what the software really does.
Questions to ask your developer
Where is data stored? Who can access it? How are backups protected? How would we find and delete one person's data? What logging exists? What happens if there is a breach?
Good partners welcome these questions. If you are planning a system that handles personal data, talk to us early. It shapes the design far more cheaply than a fix later.