Gdpr Assessment Questions And Answers

So You Need To Do A GDPR Data Protection Assessment. Here's How It Actually Works.

I deal with this kind of work regularly, and the biggest problem I see is that people treat a GDPR assessment like filling out a form. It isn't. A proper assessment is more like investigating a company's data habits under a microscope, and the difference matters a lot when you're trying to get compliant without spending six months and thousands of euros.

The approach I use starts with the questions. Before any documentation, before any forms, I map out exactly what the organization does with personal data. Where does it come in, where does it go, and who has access to it at every step. That mapping exercise usually takes my team about two to three hours for a small company, and three to five days for anything mid-market with multiple systems and third-party integrations. Here is a breakdown of the most important question categories and the kind of answers you should actually be aiming for, not just the surface-level compliance checkboxes that auditors see a hundred times a day. Question 1: What categories of personal data do you process?

Adequate answer: A full list covering names, contact details, employment data, financial information, health data if applicable, and any special category data under Article 9. Many organizations stop at names and emails and completely miss that their analytics tools, HR systems, or customer support software are handling IP addresses, device identifiers, and behavioral profiles. Those count as personal data under GDPR. Question 2: What is your lawful basis for each processing activity? Adequate answer: Each processing activity maps to a specific lawful basis from Article 6. Consent, contractual necessity, legal obligation, vital interests, public task, or legitimate interests. Legitimate interests require a balancing test and documented reasoning. I have seen companies claim consent everywhere because it is the easiest basis to write down, even when the processing clearly falls under contractual necessity. That creates unnecessary obligations around consent withdrawal and record-keeping.

Question 3: Do you transfer personal data outside the EEA? Adequate answer: An honest inventory of every cross-border transfer, including cloud providers, subsidiaries, and any third-party processors located outside the European Economic Area. If you use Google Analytics, AWS, or Stripe and they process data in the United States, that is a transfer. Post-Schrems II, Standard Contractual Clauses alone are no longer sufficient. You need a Transfer Impact Assessment for each destination country and documented evidence that local surveillance laws do not undermine the protections. Question 4: How long do you retain personal data?

Adequate answer: Specific retention periods tied to each category of data and each processing purpose, with a documented basis for those periods. Two years for marketing consent records. Seven years for employment tax data. Indefinite retention for CCTV footage is rarely justified and a common audit finding. I once had a client whose retention policy stated "as long as legally required" for everything. That got flagged immediately and required a complete rewrite. Question 5: What data subject rights procedures do you have in place? Adequate answer: Documented processes for handling access requests, rectification, erasure, restriction, portability, and objection. Each procedure needs a target response time, escalation paths, and verification steps to prevent unauthorized disclosure. The one-month deadline under Article 12 is strict. Organizations that handle one request a month usually manage, but those receiving ten in a single week without automation tend to miss deadlines and face regulatory complaints.

Question 6: Who are your processors and sub-processors?

p>Adequate answer: A complete register of every processor with a valid Article 28 data processing agreement in place, including any sub-processors and the contractual safeguards used. Most companies list their direct vendors but completely miss sub-processors hidden in their software stack. A CRM system often has dozens of sub-processors for hosting, analytics, and support. You need visibility into all of them.

Question 7: Have you conducted a Data Protection Impact Assessment for high-risk processing? Adequate answer: DPIAs for any processing that is likely to result in a high risk to individuals, including systematic monitoring, large-scale special category data processing, and automated decision-making. A DPIA is not optional when profiling customers for credit decisions or deploying workplace surveillance systems. I recommend starting the DPIA early in the project lifecycle rather than treating it as a retroactive compliance exercise. Retrofitting a DPIA after a system is already live usually reveals that the risk mitigation measures were never actually implemented.

Common Pitfalls That Slow Assessments Down

The most frequent problem I encounter is incomplete records of processing activities. Companies maintain a privacy policy but have no internal ROPA that matches what is actually happening across departments. Marketing operates a mailing list with its own database. Sales uses a different CRM. Finance has payroll data on a separate server. None of these are connected in the official records. Reconciling that gap typically adds one to two weeks to an assessment timeline for a company with twenty-five employees and four systems. Another issue is vague consent mechanisms. Pre-ticked boxes, bundled consent for multiple purposes, and unclear withdrawal procedures are all non-compliant. I reviewed a SaaS company's sign-up flow last year where a single checkbox covered privacy policy acceptance, newsletter subscription, and marketing data sharing. That needed to be split into three distinct consents with separate opt-out paths, and the change took about a day to implement. Data minimization is the hardest principle to enforce in practice. Every department has a "we might need this later" attitude toward data collection. I found a retail client storing full payment card details for three years after purchase because the IT manager was uncomfortable with deleting anything. They were not PCI-DSS compliant either. The fix involved a secure deletion process and a policy limiting card data to forty-eight hours post-transaction. That reduced their compliance scope significantly.

What A Proper Workflow Looks Like In Practice

Step one is scoping. Identify every business unit, system, and data flow. This takes one to three days depending on organizational complexity. Step two is data mapping. Interview process owners and trace personal data through each system. Document sources, processing purposes, retention periods, and recipients. This is the most time-consuming phase and usually requires two to four weeks. Step three is gap analysis. Compare current practices against GDPR requirements for each area: lawful basis, data subject rights, breach notification procedures, international transfers, and accountability measures. Identify deficiencies and prioritize them by risk level. Step four is remediation. Fix the critical gaps first, such as missing DPAs with processors and absent breach response plans. Address medium-priority items like incomplete retention schedules and unclear consent flows. Low-priority items like minor documentation updates can run in parallel. Step five is validation. Test that procedures actually work. Submit a mock data subject access request. Simulate a data breach and measure response time. Verify that a consent withdrawal propagates across all systems within the required timeframe. This testing phase usually takes three to seven business days.

Step six is documentation and ongoing monitoring. Update your ROPA, privacy notices, DPIA records, and breach response documentation. Set a review cadence of at least annually or whenever there is a material change to processing activities. Regulatory expectations and enforcement priorities shift, so annual reviews are the bare minimum rather than something generous.

When A Self-Assessment Falls Apart

Some organizations attempt a purely internal GDPR assessment and realize halfway through that they lack the technical knowledge to evaluate their data flows accurately. This happens frequently with companies that acquired other businesses and inherited legacy systems nobody understands. I encountered this with a client who had merged three companies over four years and could not produce an accurate inventory of data processing activities across any of the legacy systems. The assessment became impossible until they engaged a third party with experience in legacy data migration audits. Another scenario where self-assessment fails is when the organization operates in multiple jurisdictions simultaneously. A UK company serving EU customers post-Brexit needs to comply with both GDPR and UK GDPR. The requirements are nearly identical but not perfectly aligned. Differences around international transfer mechanisms and the role of the Information Commissioner's Office versus the ICO require separate tracking. Mixing the two frameworks into a single assessment document creates confusion and compliance gaps. If you are small enough that a full assessment seems disproportionate, consider whether a micro-enterprise exemption applies. Organizations with fewer than twenty-five employees are exempt from maintaining records of processing activities unless they engage in high-risk processing on a regular basis. That exemption does not remove your GDPR obligations entirely. It only reduces documentation requirements. Many small business owners misunderstand this and assume they are exempt from everything, which is incorrect.

The bottom line is that a GDPR assessment is not a document you complete and file away. It is a working investigation into how your organization handles personal data, and the quality of the output depends entirely on how thoroughly you examine the actual practices rather than the stated policies.