You collect personal data from grant applicants and grantees. Names. Email addresses. Bank details. Budget information. Project descriptions. Under UK GDPR, you must protect this data and respect the rights of the people it belongs to.
GDPR compliance is not optional. It is not a box to tick. When you mishandle grant applicant data, the ICO (Information Commissioner's Office) can fine you thousands of pounds. More damaging is the loss of trust from applicants and the public. People will not apply for your grants if they think you will lose their information.
What you will learn Why data protection matters for grant funders. The key GDPR requirements that apply to grant applications. How to handle data retention and subject access requests. What to look for in grant management software that meets GDPR standards.
Who this is for Government grant managers overseeing public funding. Higher education administrators managing research and student support grants. Anyone handling applicant and grantee personal data under UK GDPR.
Grant applicants trust you with sensitive information. They tell you about their organisations' finances. They share personal details about the people they serve. When you fail to protect that data, you betray that trust.
GDPR enforcement is real. In 2023, the ICO fined a university 80,000 pounds for insecure handling of student data. Another organisation paid 90,000 pounds for a data breach affecting employees and students. These were not data loss incidents in the Hollywood sense. They were failures to implement basic security controls.
Beyond fines, data breaches damage your reputation. Applicants see news of your breach. Future applicants are less likely to apply. Your staff loses confidence that you will handle their data responsibly. Your grantees question whether their financial reports are safe with you.
GDPR compliance is how you show applicants and grantees that you take their data seriously.
You must meet these core GDPR obligations when running a grant programme.
Lawful Basis and Transparency
You must have a lawful reason to collect personal data. Usually this is contract (the applicant gives you data as part of applying) or legitimate interest (you need the data to run your grant programme fairly). Tell applicants upfront why you collect their data, how you use it, and who has access. Your privacy notice should be clear, not hidden in legal jargon.
Data Minimisation
Only ask for data you actually need. If you do not use applicants' phone numbers, do not ask for them. If you do not require a personal bank account number, ask for the organisation's account instead. Every field you collect is data you must protect. Collect less, protect less.
Access Control and Staff Training
Not everyone on your team needs to see all applicant data. The finance officer needs bank details. The reviewer needs the project description. The support staff member does not need either. Use role based access so staff only see what their role requires. Train staff on data handling. Make clear what happens if someone shares data inappropriately.
Audit Trail and Accountability
You must show the ICO what happened to every piece of data you held. When was it accessed? Who accessed it? Was it deleted on schedule? These records prove you followed your policies. If you cannot show an audit trail, you cannot prove compliance.
Security and Encryption
Protect data in transit and at rest. Use HTTPS for your forms so data is encrypted as applicants send it. Use encryption for data stored in your systems. Use strong passwords. Keep software updated. These are not burdensome steps. They are table stakes for any organisation handling personal data.
You cannot keep applicant data forever. GDPR requires you to delete it when you no longer need it.
How Long to Keep Data
Your retention policy should be clear. Keep successful applicant data for the duration of the grant plus some reasonable period afterwards (usually three to seven years, depending on your legal or funder requirements). Delete unsuccessful applicant data sooner, unless you have a specific reason to keep it (for example, you may run the same grant next year and want to invite previous applicants).
Make your retention policy public. Applicants should know when you will delete their data. If you keep data for seven years for audit purposes, say that. If you delete unsuccessful applications after two years, say that. This transparency builds confidence.
Subject Access Requests
Applicants and grantees have the right to ask what personal data you hold about them. You must respond within 30 days, providing all their data in a readable format. You cannot charge a fee for the first request in a year.
Subject access requests are common and are not a problem. The problem is when you cannot respond quickly. If your data is scattered across spreadsheets, emails, and filing cabinets, you cannot meet the 30 day deadline. If your data is in a well designed system, you can search, filter, and export everything about a person in minutes.
Your grant management software is foundational to GDPR compliance. Choose badly and no policy will save you.
Questions to Ask Software Vendors
Where is data hosted? Who can access it? How often are backups made? What happens if the vendor goes out of business? What is your data processing agreement? Will you cooperate with a data breach investigation? Can you delete data on demand? Vendors should answer these clearly without forcing you to call a sales person.
Look for These Features
Role based access controls. Detailed audit trails. Automated data retention and deletion. Built in privacy by design, not added later. Data export in standard formats. Clear documentation of security measures. Certifications like ISO 27001 show the vendor takes security seriously.
For Public Sector Organisations
If you are a government or public body, check whether the software is on the UK government's G Cloud digital marketplace. Suppliers on G Cloud meet UK government security and data handling standards.
Flexigrant was built with UK GDPR compliance from the start. Not added as an afterthought. Role based access controls ensure staff only see the data relevant to their role. Every access, edit, and deletion is logged in the audit trail.
The platform supports configurable data retention policies. You set how long applicant and grantee records are kept and what happens when they expire. When a data subject access request arrives, you can locate and export all records for an individual from one place.
Flexigrant is cloud based and hosted securely. For public sector organisations, the platform is available through G Cloud, the UK government’s digital marketplace for cloud services.
See how Flexigrant handles data protection. Book a free demo.
What is a data processing agreement and do I need one?
A data processing agreement (DPA) is a contract between you and any vendor who processes personal data on your behalf. If your grant management software vendor stores applicant data, you need a DPA. The vendor should provide one. Read it carefully. It should spell out security measures, how long they keep data, and what happens if there is a breach.
Can I store grant data in Excel or Google Sheets?
Technically yes, but it is risky. Spreadsheets lack access controls. You cannot see who viewed or edited which cells. You cannot encrypt the file easily. You cannot enforce data retention policies automatically. You cannot respond to subject access requests efficiently. If you store grant data in spreadsheets, upgrade to proper software as soon as possible.
What should I do if an applicant asks me to delete their data before the grant ends?
You must balance their right to erasure against your legitimate need to keep data for audit and compliance. If the grant is active, explain that you must keep their data to manage the award. If the grant ended years ago, you should delete their data anyway under your retention policy. For unsuccessful applicants, delete their data promptly unless you have a specific reason to keep it.
Do I need cyber insurance for my grant data?
Cyber insurance is a sensible layer of protection, but it is not a substitute for good security practices. Insurance pays after a breach happens. Good security practices prevent the breach in the first place. Focus first on secure software, access controls, staff training, and regular backups. Insurance covers what you cannot prevent.
Information Commissioner’s Office: Guide to the UK GDPR
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/
UK Government: Data Protection Act 2018
https://www.legislation.gov.uk/ukpga/2018/12/contents/enacted
Charity Commission: Protecting Charity Information (CC8)
https://www.gov.uk/government/publications/internal-financial-controls-for-charities-cc8
National Cyber Security Centre: Small Organisation Guidance
https://www.ncsc.gov.uk/collection/small-business-guide