How UK GDPR and ICO rules shape productivity software retention

What to take away

How the ICO's storage limitation principle applies to productivity software

The ICO's storage limitation principle says personal data must not be kept longer than needed for the purpose it was collected for. That applies to your productivity software just as it applies to a CRM or payroll system.

A project board, a shared drive, a chat channel and a task list all hold names, email addresses, comments and file metadata. Each of those is personal data when it identifies a living person.

The ICO's Data protection principles - guidance and resources | ICO sets out how storage limitation works alongside purpose limitation and data minimisation. You need a reason for each record, and a point at which it goes.

The ICO also expects you to be able to justify why a period was chosen. "We keep everything forever" is not a justification.

Most UK operations teams do not set out to hoard data. It accumulates. A contractor leaves, their account is disabled, and their files stay in a shared workspace. A support ticket closes, but the thread remains searchable. A spreadsheet of event attendees is copied into a planning folder and forgotten.

Storage limitation periods are the practical answer. They are the fixed or event-based points at which a category of data is deleted, anonymised or reviewed. For productivity software, periods are usually set by data category rather than by tool. A recruitment pipeline, an HR case file, a client project and a marketing list all need different periods.

The ICO does not publish one universal table of retention periods for business software. It publishes principles, and expects controllers to derive periods from law, contract, operational need and risk. Some periods come from statute, such as tax records. Others come from limitation periods for contract claims.

Concrete examples: HMRC requires self-employed people to keep records for at least 5 years after the 31 January submission deadline, and limited companies for 6 years from the end of the financial year. The Limitation Act 1980 sets a 6-year limitation period for most contract claims. ACAS guidance suggests keeping employment records for 6 years after employment ends.

Productivity software makes this harder because data is copied easily. A document shared into three workspaces exists in three places. A chat message quoting a customer email creates a second copy. Your retention schedule has to account for copies, or deletion will be incomplete.

A useful test is to ask what would happen if the data stayed for another five years. If the answer is "nothing bad, but nothing good either", the period is probably too long. If the answer is "we could not defend it", the period is too long and the risk is live.

Under the UK GDPR, storage limitation is not a one-off project. It is a continuing duty. The ICO can ask for evidence of how periods were set and how deletion is enforced.

For a wider view of how these duties map onto day-to-day tools, see Data protection for productivity software.

Data minimisation duties under UK GDPR and the Data Protection Act 2018

Data minimisation says you collect only what you need for a stated purpose. In productivity software, minimisation is mostly about fields, not files. A task form that asks for a home address when a work email would do is collecting too much. A timesheet that records location when only hours are needed is collecting too much.

The ICO's UK GDPR guidance and resources explain that minimisation, storage limitation and accuracy work together. If you do not need a field, do not create it. If you create it, you must secure it, keep it accurate and delete it on time. Every extra field adds to the retention burden.

Minimisation also applies to analytics. Many productivity tools log user activity by default: who opened what, when, from which device. That telemetry can be personal data. If you do not need per-user activity reports, turn them off or set them to aggregate. If you do need them, document why and set a short retention period.

The Data Protection Act 2018 sits alongside the UK GDPR. It provides exemptions and supplements, including rules for law enforcement processing and some immigration purposes. For most operations teams, the practical effect is that the UK GDPR duties apply in full, and the Act supplies the framework for the ICO's powers and enforcement.

Minimisation is not the same as collecting nothing. You need enough data to run the business, pay people, meet tax duties and defend claims. The test is necessity and proportionality, not abstinence.

A simple audit works. List every field, attachment type and log in each tool. For each one, write the purpose and the retention period. If you cannot write a purpose in one sentence, the field should go.

That audit is also the groundwork for a retention schedule. Once you know what you hold and why, you can decide how long to keep it.

Building a retention schedule inside UK operations software

A retention schedule is a table of data categories, purposes, periods and actions. It is not a policy statement. It names the data, the period and what happens at the end: deletion, anonymisation or transfer to an archive.

Start with categories that exist in your tools. The table below is a retention schedule example for a UK operations team using common productivity software.

Periods in that table are examples, not ICO mandates. You must set your own, and record why. The ICO expects the reasoning to exist.

Build the schedule in the tool, not beside it: configure retention labels, auto-delete rules or workspace expiry by category, and test that they fire.

Use numbered steps for a first pass:

A checklist helps before go-live:

For the wider UK rule set that touches monitoring, security and records, see UK rules for business productivity software.

Controller and processor roles: what a vendor contract must settle

The ICO's Controllers and processors | ICO defines a controller as the organisation that decides why and how personal data is processed. A processor acts on the controller's instructions. Most UK operations teams are controllers for the data they put into productivity software. The supplier is usually a processor, but not always.

A supplier can be a controller for some processing. Billing data, account administration and product analytics may be processed for the supplier's own purposes. That makes the supplier a controller for those parts, and you cannot contract that away. The contract must separate the two roles.

Those clauses matter for retention because deletion at the end of contract is often the weakest link. If the contract is silent, data may sit in backups for years. Push for a stated deletion period after termination, and a certificate or report confirming it.

Sub-processors are the other weak link. A supplier may host on a third-party cloud, use a support tool, or route email through another provider. Each sub-processor needs to be listed, and changes should require notice. Without that, your retention schedule stops at your supplier's edge.

Data residency and location clauses belong here too. If the contract does not name the storage regions, you cannot verify transfers. Ask for the regions, the sub-processor list and the mechanism used for any transfer outside the UK.

For how these clauses sit alongside liability, service levels and exit, see Reading a productivity software contract.

Subject access requests, erasure and individual rights in practice

The ICO's Subject access requests (also known as SARs or right of access) | ICO explains that individuals can ask for a copy of their personal data, and you must respond without undue delay and within one month.

That month can be extended by two further months for complex requests, but the clock starts when the request arrives, not when you find it.

Productivity software must support that duty. You need search across documents, chat, email, tickets and comments. You need export in a common format. You need to identify third-party data and redact it. If your tools cannot search chat or comments, you will miss data and the response will be incomplete.

Erasure is the harder duty. Individuals can ask for deletion where there is no overriding reason to keep the data. Your retention schedule is the defence: if a period is still running for a valid purpose, you can refuse that part. If the period has expired, the data should already be gone.

Other rights follow the same pattern. Rectification needs editable records and an audit trail. Restriction needs a way to flag a record as frozen. Portability needs structured export. Objection needs a way to suppress processing for a person while keeping the record for legal reasons.

Test your tooling before a request arrives. Run a search for a test name across every module. Time how long it takes to assemble a response. Most teams find chat and comments are the gap.

Identity verification matters too. You can ask for reasonable evidence of identity, but you cannot demand excessive proof. Keep the verification record short-lived, and do not store copies of passports in a shared drive just in case.

International transfers and EU-hosted productivity tools

Many productivity tools are hosted in the EU, the US or further afield. A transfer outside the UK needs a lawful mechanism. The UK adequacy regulations cover the EEA, so EU-hosted tools are generally straightforward, but the supplier's own sub-processors may sit elsewhere.

The UK International Data Transfer Agreement and the UK Addendum to the EU Standard Contractual Clauses are the usual mechanisms for transfers to countries without adequacy. The supplier normally provides the signed addendum. You need to check it names the right exporter, importer and data categories.

A transfer risk assessment is expected for higher-risk transfers. It looks at the destination's laws, the data types, the volume and the safeguards. For routine HR or project data in a mainstream tool, the assessment is usually short, but it should exist and be dated.

EU-hosted tools also raise a practical point. If the supplier's EU entity contracts with you, your counterparty may be an EU company. That affects governing law, tax treatment and where you serve notices. Check which entity signs.

Data residency options are now common. Some vendors let you pin storage to a UK or EU region. That can simplify the transfer analysis, but it does not remove the need for a contract and a record. It also does not cover support access from other countries.

Review transfers annually and when the supplier changes sub-processors. A transfer that was fine last year may not be fine after a change of hosting provider.

Accountability, DPIAs and the data protection fee

Accountability means you can show how you comply, not just claim it. For productivity software, that means records of processing, a retention schedule, contract documents and evidence that controls work. The ICO expects these to be available on request.

A data protection impact assessment is required for processing likely to result in high risk. Monitoring employees through productivity tools is a common trigger. If you track activity, location or output, run a DPIA before you switch the feature on.

A DPIA should describe the processing, assess necessity and proportionality, identify risks and record mitigations. It is not a one-off form. Review it when the tool or the purpose changes.

Most UK controllers must pay the data protection fee to the ICO. The fee is tiered by size and turnover. Tier 1 is £52 for micro organisations (turnover up to £632,000 or no more than 10 staff). Tier 2 is £78 for small and medium organisations (turnover up to £36 million or no more than 250 staff).

Tier 3 is £3,763 for large organisations (turnover over £36 million and more than 250 staff). Direct debit reduces each fee by £5. Exemptions include processing only for staff administration, advertising, marketing and public relations, or accounts and records, and not-for-profit organisations.

Check the ICO's fee pages for current tiers before you assume you are exempt.

Appointing a data protection officer is mandatory only in some cases, such as large-scale monitoring or special category data. Many operations teams instead name a responsible lead. Either way, someone must own the schedule, the contracts and the request process.

Training is part of accountability. Staff who create workspaces and share files need to know what the retention labels mean. A schedule nobody understands will not be followed. If you are assessing suppliers against these duties, vendor due diligence should cover retention, deletion and transfer evidence.

Breach reporting within 72 hours and the Data (Use and Access) Act 2025

A personal data breach must be reported to the ICO within 72 hours of you becoming aware of it, where it risks people's rights and freedoms. You must also tell affected individuals without undue delay where the risk is high.

Productivity software is a common source of breaches: a mis-shared folder, a compromised account, a forwarding rule that leaks email.

The Data (Use and Access) Act 2025 | ICO sets out the reforms, which affect how some rules are applied and how the ICO operates. Operations teams should track commencement dates, because not every provision starts at once.

The Act received Royal Assent on 19 June 2025. The government has said most provisions commence on 19 August 2025, with the remainder on dates set by the Secretary of State.

Named provisions include the recognised legitimate interests list, reforms to automated decision-making, a new complaints procedure, a reasonable and proportionate search standard for subject access requests, and higher fines under PECR. The Act does not remove the core duties: lawfulness, minimisation, storage limitation and security still apply. Retention schedules remain necessary.

Prepare a breach playbook before you need it. Name the person who decides whether to report. Keep a log of incidents, including near misses. Record the time you became aware, because the 72 hours runs from then.

Check your supplier's breach clause. The processor must notify you without undue delay after becoming aware of a breach. That notification is what starts your clock in practice, so the contract should state a short window, such as 24 hours.

Finally, keep the schedule and the playbook together. A breach often reveals data you should no longer have held. If the retention rules worked, the exposure is smaller.

Common questions