How to Write GDPR-Compliant SOPs: What Every Data Controller Needs to Know

GDPR doesn't list a required set of SOPs the way PCI-DSS does, but the accountability principle in Article 5(2) is effectively a documentation mandate: you must be able to demonstrate compliance. That demonstration happens through written procedures. This guide covers which SOPs every data controller needs, how to structure them, and the documentation trap that catches teams who use cloud-based recorders to document data workflows.

Why GDPR Explicitly Requires Documented Procedures

Three GDPR articles create direct documentation obligations:

• →Article 5(2) — Accountability. The controller is responsible for, and must be able to demonstrate, compliance with the data protection principles. Written SOPs are your primary evidence of systematic compliance.
• →Article 30 — Records of Processing Activities (RoPA). Controllers must maintain written records of processing activities. The RoPA is not the same as an SOP — it's a register of what you do. The SOPs are the procedures that govern how you do it.
• →Article 32 — Security of processing. Requires "appropriate technical and organisational measures." The organisational measures are your written procedures: who has access, what they're allowed to do, and how incidents are handled.

Supervisory authorities during investigations will ask to see your written procedures. "We have a process for that" without documentation is not a satisfactory answer under GDPR.

The Six GDPR SOPs Every Controller Should Have

• →Data subject request handling. How your team receives, verifies identity for, and responds to access requests, erasure requests, portability requests, and objections. Include the 30-day response clock and escalation path if the request is complex.
• →Consent collection and withdrawal. Step-by-step workflow for how consent is obtained, recorded, and how withdrawal is processed. This SOP should cover every channel where consent is collected: web forms, in-app prompts, and phone.
• →Personal data breach notification. GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a breach (for breaches likely to result in risk to individuals — not all breaches trigger this obligation). This procedure needs to be fast and unambiguous. Who decides if it's a notifiable breach? Who drafts the notification? Who approves it?
• →Data retention and deletion schedules. What data is kept, how long, and who is responsible for deletion. This must be specific per data category — "we delete old data" is not a procedure.
• →Third-party processor onboarding. The workflow for evaluating a new vendor, executing a Data Processing Agreement (DPA), and adding them to the RoPA. Article 28 requires a DPA with every processor before they handle personal data.
• →Privacy by design review. A documented checklist for new product features or data processing activities. At what stage does the DPO or privacy team review? What questions are asked? What decisions require escalation?

The Data Minimization Trap in SOP Documentation

When you record a workflow to create an SOP, the recording tool may capture personal data in screenshots or step text. Consider a workflow for handling a customer data subject request: the screen may show the requestor's name, email address, and the data being accessed. If that recording is sent to a cloud server, you've just created a new personal data processing activity — one that probably isn't in your RoPA and definitely doesn't have a DPA with the recording vendor.

This is the irony of using a cloud-based screen recorder to document GDPR workflows: the act of documentation creates a GDPR compliance obligation. The recording becomes personal data. The cloud provider becomes a processor. A DPA is required before you can legally use the tool. Most teams don't realize this until an auditor asks about their documentation tooling.

How to Structure a GDPR SOP

A GDPR SOP has some specific fields beyond the standard procedure template:

A GDPR SOP reviewed annually and version-controlled is worth far more than a perfect document that is never updated. Supervisory authorities are more impressed by evidence of an active compliance program than by the sophistication of a single document.

Documenting GDPR Workflows Without Creating New Risks

The correct architecture for GDPR-compliant SOP documentation keeps all recording data on the device. When nothing is transmitted to a third-party server, no new processor relationship is created, no DPA is required for the recording tool, and no new entry needs to go into your RoPA for the documentation process itself.

Claudia stores all recordings in the browser's local IndexedDB, encrypted with AES-256-GCM. No workflow data — screenshots, step content, or exports — is transmitted to Claudia's servers. Explicit consent is collected before every recording session. Users can delete individual recordings or all data at once (right to erasure). URL query parameters containing tokens and API keys are automatically stripped on export.

Because no personal data from recordings reaches Claudia's infrastructure, no Data Processing Agreement with Claudia is required for the recording function — the data processor relationship for workflow data is designed to not exist, provided recordings remain local and are not transmitted externally.

This article is for informational purposes only and does not constitute legal advice. Consult your compliance team or legal counsel to evaluate how Claudia fits within your organization's specific regulatory obligations.

Related: How to Create HIPAA-Compliant SOPs  ·  CCPA SOP Compliance  ·  PCI-DSS SOP Requirements