Office SDK
See the workflow
All storiesSecurity
SecurityGuide4 min read

GDPR for collaborative documents: copies, retention, and rights

Locate personal data in drafts, comments, exports, indexes, and backups before implementing retention or rights decisions.

Office SDK EditorialOffice SDK Editorial
077
GDPR for collaborative documents: copies, retention, and rights: Processing purpose, Data minimization, Processor chain, Retention rule.
Security / Office SDK

GDPR decisions for collaborative documents must cover personal data in content, comments, history, exports, and service records. Identify the processing purpose and responsible parties first. Then implement assessed retention and rights decisions across the copies that the real workflow creates.

Identify purpose and responsibility

Record why the organization processes personal data in the document workflow and the applicable lawful basis, with the privacy team's guidance. Identify controllers, processors, and any joint arrangements according to their actual roles. For a customer onboarding workspace, the document application, editing provider, and hosting operator may have different responsibilities. Contracts and processing records should reflect the deployed arrangement rather than a generic architecture slide. Also identify the people responsible for answering rights requests and reviewing new integrations. A team cannot reliably act on a request if document ownership exists only in an employee's memory.

Personal data can exist in content, collaboration, derived, and backup layers.
Figure 1. Use the layers to guide the search rather than promising universal deletion.

Reduce unnecessary exposure

Suppose a recruitment team collaborates on interview summaries. Evaluators need candidate information, but a broadly shared hiring plan may only need aggregate counts. Keep individual assessments in a restricted workspace and use anonymized or appropriately aggregated data where the purpose permits. Remember that removing names does not necessarily anonymize a record if other details identify the person. Review comments, tracked changes, embedded objects, and exported versions before wider circulation. A cleaned visible page can still contain personal information in a hidden worksheet or a retained revision accessible to other users.

Map suppliers and transfers

Document where processing occurs and which organizations can access the data, including remote support and subprocessors. Storage region alone does not describe all processing or international transfer questions. Review applicable transfer mechanisms and legal requirements with the responsible privacy specialists. Keep the supplier inventory connected to actual network routes, operational access, and backup locations. When a new AI summarization integration is proposed, evaluate its processing purpose, contractual role, retention behavior, and data destinations before activation. An optional plugin can materially change a previously reviewed document workflow even when the main editor remains in the same region.

Make retention operational

Define retention according to purpose and applicable obligations. For unsuccessful applicants, the agreed policy may specify a period, exceptions, and deletion triggers. Implement those rules across drafts, exports, search indexes, and caches, then document how backup expiry works. Handle erasure requests with the applicable exceptions and competing legal requirements assessed by the privacy owner. Avoid promising immediate physical removal from every backup if the architecture cannot provide it. A practical procedure records the request, locates affected information, determines required action, and verifies completion while preventing deleted data from silently returning during restoration.

Run a rights request with a location map

Start a rights request by identifying the person and scope through the approved verification process. The privacy owner determines the applicable response and any lawful exceptions; the technical team locates the data and carries out that decision. Keep these responsibilities distinguishable in the ticket.

  1. Search authoritative business records and document ownership indexes for the relevant identifiers.
  2. Inspect linked comments, revisions, attachments, and exported packages where the request applies.
  3. Record the assessed action for each location: provide, correct, restrict, erase, retain under an exception, or investigate further.
  4. Execute the actions with owners of the affected services and collect confirmation.
  5. Check that search results and restoration procedures do not reintroduce data that should remain removed from active systems.

For the recruitment example, a candidate name may appear in a summary document and a separate interview scoring sheet. Removing only the visible summary is not a complete search of that workflow. Equally, a backup policy may require a documented expiry and restricted use process rather than immediate selective editing. Explain the implementation accurately in the record. Keep the request log proportionate: it should track scope, decisions, locations, and completion, without becoming a permanent duplicate archive of all the personal data the team found.

The privacy decision is implemented and verified across identified locations.
Figure 2. Engineers implement the assessed decision; the log preserves that boundary.

Questions Decision notes closing a request

  • Identify the processing purpose, responsible owner, and applicable legal basis.
  • Locate personal data in content, comments, history, exports, and indexes.
  • Confirm supplier roles, access locations, and relevant transfer arrangements.
  • Apply the assessed retention or rights decision across active copies.
  • Verify backup handling and document any lawful exception to the request.

Further reading

Back to all stories

Keep reading.

All stories