How to Comply Gdpr

GDPR enforcement has produced about €7.1 billion in cumulative fines since 25 May 2018, with roughly €1.2 billion issued in 2025 alone, according to DLA Piper's January 2026 GDPR fines and data breach survey. For a small SaaS company or agency, the risk isn't only a fine. Poor data controls can stall enterprise deals, delay vendor approval, and make every customer security questionnaire painful.

The practical answer to how to comply with GDPR is to stop treating privacy as a policy-page exercise. Build an operating system that shows what data you hold, why you use it, where it goes, how long you keep it, and what happens when someone asks you to access or delete it. This guide focuses on the workflows that matter for lean teams, including OAuth tokens, AI content tools, shared workspaces, social publishing, processors, and cross-border transfers.

GDPR Compliance as an Operating System, Not a Form

GDPR compliance is a continuous risk program. Your team needs to identify processing, assess risk, implement controls, and keep evidence that those controls still work. A privacy notice supports that program, but it can't replace the inventory, approvals, contracts, deletion routines, and request handling behind it.

The enforcement record makes this operational view difficult to ignore. The CMS GDPR Enforcement Tracker recorded 2,685 fines with complete information by March 2026, or 3,062 cases when entries with partial data were included. The complete cases totaled about €6.11 billion, with an average of roughly €2.28 million per fine. The statutory maximum for the most serious violations is the higher of €20 million or 4% of global annual turnover, as explained in the GDPR text on administrative fines.

A small team doesn't get a smaller obligation because it has fewer employees. It does need a leaner operating model. Connect these eight moves into one loop:

1. Inventory the data.
2. Assign a lawful basis.
3. Capture and prove consent where required.
4. Assess high-risk processing with a DPIA.
5. Handle data subject requests through a tracked workflow.
6. Control processors and international transfers.
7. Set retention and deletion rules.
8. Document decisions, controls, and reviews.

Build the inventory before buying another tool

Start with a Records of Processing Activities, or RoPA. The ICO checklist for the right to be informed identifies the fields people need to understand, including the data collected, processing purpose, recipients, retention, transfers, and automated decision-making. Those same fields give your team a practical inventory structure.

Take a 12-person social media agency managing four client workspaces. Its first inventory should include:

The easy-to-miss data is usually in logs and previews, not the main database. An IP log generated during queue processing is still part of your data map. A screenshot captured during post preview rendering may contain a username, profile image, or client message.

Assign one spreadsheet owner. Refresh the register weekly while the stack is changing, then move to a defined review cadence once the flows stabilize. Each row should point to a system of record, such as the application database, cloud storage bucket, support platform, OAuth provider, or AI vendor. That link lets someone verify the entry instead of trusting an old description.

Practical rule: If your team can't name the system holding a data category, it hasn't finished the inventory.

PostSyncer stores workspace-scoped drafts, tokens, and audit logs, so map those rows before adding connectors or enabling new AI workflows. For a broader policy starting point, compare the inventory with this social media policy template. You can also review a public example of privacy disclosures in the SubmitMySaas legal page, but adapt the wording to your actual processing rather than copying it.

Choosing the Right Lawful Basis

Don't choose a lawful basis after processing has already started. Record the basis when you design the feature, and document why the alternatives don't fit.

The six bases are consent, contract, legal obligation, vital interests, public task, and legitimate interests. Small SaaS teams will usually work mainly with contract, legitimate interests, and consent. That doesn't make them interchangeable.

A scheduled post illustrates the distinction. Executing the user's instruction can fit contract necessity. Keeping a token to maintain that connection may fit legitimate interests after a documented balancing test. Using the resulting analytics to profile behavior across workspaces requires a separate analysis, and consent may be the appropriate basis. Repurposing drafts for model fine-tuning is not automatically covered by the original publishing contract.

Never switch bases quietly after launch. A post-hoc basis change can leave the privacy notice, consent record, retention rule, and user expectations out of alignment.

Designing Consent That Actually Holds Up

Consent should be a versioned event log, not a banner your team vaguely remembers deploying. The person must make a freely given, specific, informed, and unambiguous choice. Your records must prove what they chose and what the choice covered.

Use separate controls for separate purposes. Analytics, marketing email, and AI training shouldn't be bundled into one “accept all” action. Present the choice before the relevant data leaves the browser or enters a vendor workflow, and make refusal as usable as acceptance.

A durable consent record captures:

• Identity or account reference: Link the event to the person or workspace without collecting unnecessary identifiers.
• Purpose: State whether the choice covers analytics, marketing, AI training, or another defined use.
• Notice version: Preserve the exact privacy or consent text shown at the time.
• Timestamp and channel: Record when and where the choice occurred.
• Choice value: Store granted, refused, or withdrawn.
• Scope: Record the workspace, product area, cookie category, or communication channel covered.
• Withdrawal event: Keep the withdrawal date and stop downstream processing promptly.

Don't use pre-ticked boxes. Don't block legitimate access with a cookie wall that forces unrelated tracking. Don't hide withdrawal inside a maze of account settings. A preference center should be easy to find and should apply the change to every connected system that relies on the choice.

Consent also needs operational ownership. When your marketing platform, analytics tool, and AI provider each receive data, the consent event should be available to the systems that need to enforce it. If a person withdraws marketing consent, the suppression must reach the email tool, campaign queue, CRM segments, and any export used for targeting.

Consent is defensible only when the record shows both the choice and the context around it.

Running a Data Protection Impact Assessment

A DPIA is a product decision made before risky processing begins. It isn't paperwork completed after engineering has shipped the feature.

For higher-risk processing, GDPR Article 35 requires a DPIA before processing starts. The Article 35 requirements call for a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of risks to individuals, and the safeguards used to reduce those risks.

Systematic profiling and advanced technology are clear trigger questions. An AI auto-reply tool that classifies sentiment, generates responses from customer messages, or publishes across multiple brand workspaces deserves a formal screen. So does a scheduling feature that combines cross-client bulk publishing with LLM-generated captions.

Use a six-step decision record

A practical workflow follows the method described in Irish Data Protection Commission DPIA guidance_Oct19_0.pdf):

1. Confirm the trigger. Record why the feature may create high risk, including profiling, new technology, scale, sensitive content, or monitoring.
2. Define the project. Describe data sources, users, recipients, AI providers, channels, decisions, retention, and transfers.
3. Test necessity and proportionality. Explain why each field and processing step is needed, and identify a less intrusive alternative.
4. Identify risks. Consider unauthorized disclosure, incorrect generated content, unwanted publication, excessive access, and loss of user control.
5. Add mitigations. Use human approval, per-channel publishing limits, workspace isolation, prompt minimization, access controls, deletion routines, and vendor restrictions.
6. Rate residual risk and sign off. Record the remaining risk, decision owner, open actions, and launch conditions.

For the cross-client publishing feature, document whether one client's drafts can enter another client's prompt context. Record whether the LLM provider retains prompts. Define which users can approve generated content and whether auto-publishing is disabled by default. If the assessment concludes that residual risk is low after these controls, preserve the reasoning and evidence. “Low risk” is a conclusion, not a substitute for analysis.

Handling Data Subject Requests on Time

Small teams need a runbook, not an inbox search. Create one privacy alias, one intake form, and one tracker that assigns an owner and due date to every request. The relevant response window is one month, as summarized by GDPR requirements for data subject rights.

Your form should capture the requester's contact details, account or workspace, requested right, relevant product area, and preferred secure delivery method. Don't demand excessive proof. Ask for enough information to prevent disclosure to the wrong person, then record what you checked and why it was reasonable.

Search every system, not just the application

An access, erasure, portability, or objection request can touch more than the primary database. Search:

• Application data: Profiles, workspace membership, drafts, comments, tokens, and audit events.
• Support systems: Tickets, chat transcripts, attachments, and internal notes.
• Analytics stores: Event records, exports, dashboards, and identifiers used for joins.
• Backups: Snapshot retention, restoration procedures, and deletion limitations.
• Processors: Email services, cloud storage, AI APIs, social platforms, and customer relationship tools.
• Human-controlled files: Spreadsheets, downloaded reports, screenshots, and shared folders.

For erasure, distinguish data that can be deleted from information that must be retained under a legal obligation. For portability, ask whether the person wants JSON or CSV, then provide structured data through a secure channel. For an objection, stop the challenged processing while the team evaluates the request. Don't let a campaign queue or scheduled export continue because it was created before the objection.

Use a response like this:

We received your request and verified the account details needed to process it. We completed the following actions: [list access, corrections, deletions, restrictions, or exports]. We retained [specific categories] because [legal obligation or documented exception]. We didn't complete [specific action] because [reason], and you can contact [privacy contact] if you want us to review that decision.

Every vendor that touches personal data needs processor scrutiny. A defensible Data Processing Agreement should define documented instructions, processing scope, confidentiality, security measures, assistance with rights requests, breach notification, sub-processors, deletion or return at contract end, and audit support.

Negotiate three clauses first: processing scope, sub-processor approval or notice rights, and Standard Contractual Clauses for restricted transfers where applicable. Then check security certifications, breach notification timing, deletion guarantees, access controls, and support for rights requests. Review the processor list whenever you add a connector and during a scheduled governance review. For social scheduling stacks, verify whether the platform stores refresh tokens, retains published-content metadata, or sends data through AI sub-processors.

A useful visual reference for the operational side of storage and backups is this guide to backup and storage solutions.

The following video can help teams discuss the intake workflow internally:

Retention, Breach Response, and a 90-Day Rollout

Retention, breach readiness, and documentation belong together. A team can't demonstrate accountability if it doesn't know what should be deleted, who responds to an incident, or where the evidence lives.

Days 1 to 30

Create a deletion matrix tied to processing purposes. Include analytics events, CRM records, OAuth tokens, scheduled-post logs, support tickets, exports, and backups. For each category, record the owner, purpose, system, deletion trigger, exception, and evidence that deletion occurred.

Don't choose retention periods because a vendor's default is convenient. Start with the purpose, then keep only what the team can justify. Add an automated deletion job where possible, and give an owner responsibility for exceptions.

Days 31 to 60

Build the breach runbook before an incident. Define intake, severity triage, technical containment, processor escalation, evidence preservation, decision approval, and communications. Include the 72-hour supervisory-authority notification workflow described in Article 33 breach notification guidance, plus templates for the authority and affected individuals when notification is required.

The runbook should identify who can make the initial risk assessment, who contacts vendors, and who keeps the incident timeline. Run a tabletop exercise using a realistic scenario, such as an exposed OAuth token or an AI vendor receiving content from the wrong workspace.

Days 61 to 90

Close the evidence gaps. Finalize the RoPA, DPIA register, consent logs, processor list, training records, deletion evidence, breach decisions, and request tracker. Set a recurring review that brings product, engineering, security, marketing, and operations together.

Use this final checklist:

• Inventory: Every material processing flow has an owner and system reference.
• Lawful basis: Each purpose has a recorded basis and rationale.
• Consent: Choices are granular, versioned, retrievable, and withdrawable.
• Risk: High-risk features have DPIA decisions before launch.
• Processors: DPAs, sub-processors, transfers, and deletion terms are documented.
• Rights: Requests have owners, verification notes, searches, decisions, and secure responses.
• Retention: Deletion rules exist for primary systems, exports, and backups.
• Incidents: The team can triage, escalate, document, and notify.
• Evidence: A reviewer can reconstruct what happened without relying on one employee's memory.

GDPR FAQs for Small Teams and SaaS Operators

Does an AI caption generator need a separate lawful basis?

It depends on the purpose. Generating a caption as part of a requested publishing service may fit the basis documented for that feature. Using customer drafts, comments, or analytics to train a model is a separate purpose and needs its own analysis, notice, controls, and potentially consent. Record whether the provider retains prompts or outputs before enabling the integration.

Are OAuth scopes automatically acceptable because the user clicked connect?

No. Request only the permissions needed for the feature. If the product asks for access that exceeds the publishing, analytics, or inbox function the user selected, update the authorization flow and explain the purpose clearly. Store the granted scope and provide a revocation path.

Are aggregate engagement metrics personal data?

Aggregation doesn't automatically remove privacy risk. If a metric can be linked back to an identifiable account, workspace, employee, creator, or audience member, treat the underlying data as personal data until your team has documented a defensible anonymization approach. Keep raw identifiers out of dashboards that don't need them.

Does a one-person consultancy need a DPO?

Not automatically. The ICO governance guidance on accountability controls explains that DPO obligations depend on the organization's activities, including large-scale regular and systematic monitoring or large-scale processing of sensitive data. A small operator still needs clear privacy ownership even when a formal DPO isn't required.

Can a distributed US and EU team use the same SaaS stack?

Yes, but map every transfer and recipient. Identify where customer data is stored, which support staff can access it, which vendors process it, and what transfer mechanism supports the flow. A shared workspace doesn't remove the need for access controls, processor agreements, or a documented transfer assessment.

Can we scrape public social profiles for lead generation?

Public visibility isn't the same as unrestricted reuse. Define the purpose, assess the lawful basis, respect platform rules, provide required information where applicable, minimize collection, and set deletion controls. Don't assume a public profile makes every associated identifier fair game.

Do GDPR obligations override a platform's Terms of Service?

No. You need both a lawful data-processing design and a platform-compliant publishing workflow. A client's authorization to schedule content doesn't authorize actions that violate the social network's API rules, requested permissions, or restrictions on automated engagement.

For a practical tool-oriented review of consent, rights, inventory, and vendor workflows, see these GDPR compliance tools. The tool doesn't replace the decisions. Your team still needs to define purposes, assign owners, approve risky processing, and preserve evidence.

PostSyncer can centralize social scheduling, workspace management, OAuth connections, AI-assisted content creation, approvals, analytics, and comments workflows in one operational environment. Use PostSyncer to reduce disconnected data flows, then apply the inventory, lawful-basis, retention, processor, and rights-request controls described above.