Decide whether a product, vendor, workflow, or data flow is inside GDPR scope before assigning notices, records, contracts, security controls, transfer safeguards, or data-subject rights work.
Use the test to record personal-data facts, controller and processor roles, EU establishment, EU targeting or monitoring, special-category and child-data flags, transfer branches, vendor dependencies, and evidence.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this GDPR applicability test when a team launches a product, changes telemetry, adds a vendor, opens an EU market, imports customer lists, processes employee or applicant data, or moves data outside the EEA. The result should be a short evidence record that says whether GDPR applies to the specific processing activity and which follow-up branches are triggered.
Start with Article 2 and Article 4. GDPR scope begins with processing of personal data by automated means, or non-automated personal data that forms or is intended to form part of a filing system. If the data cannot relate to an identified or identifiable natural person, record why the GDPR test stops at this step.
Do not treat the system name as the unit of analysis. Test each processing activity separately: collection, storage, enrichment, support access, analytics, disclosure to a vendor, model evaluation, deletion, and transfer can have different facts.
After confirming personal data, decide who determines the purposes and essential means of each processing activity. The EDPB describes controller, joint controller, and processor as functional roles, so contract labels are evidence but not the whole answer.
A product team can be a controller for its own analytics, a processor for customer-hosted data, and a separate controller for billing or security logs. Keep those role decisions separate, because each branch drives different Article 28 contracts, Article 30 records, notices, security obligations, and rights handling.
Use Article 3 as a separate territorial-scope test. GDPR can apply where processing is in the context of an EU establishment, even if processing occurs outside the Union. It can also apply to non-EU controllers or processors when processing relates to offering goods or services to people in the Union or monitoring their behaviour in the Union.
Record facts that show the link to the Union. For establishment, capture stable EU arrangements and how the processing is connected to those activities. For targeting, capture EU-facing offers such as language, currency, delivery, sales, signup, or service availability. For monitoring, capture tracking, profiling, behavioural analytics, location monitoring, health or lifestyle app telemetry, or similar observation of people in the Union.
If GDPR applies, add risk and governance flags before routing the work. Special-category data, criminal-offence data, child consent in information-society services, large-scale processing, systematic monitoring, and high-risk processing can change the controls, review depth, and evidence needed.
The applicability record should not decide every downstream obligation. It should make the branching visible so privacy, product, security, procurement, support, HR, and data-governance owners know which workstream starts next.
When personal data leaves the EEA or is made accessible from a third country, test Chapter V before approving the workflow. Article 44 makes transfer conditions apply to onward transfers as well, so the test should follow hosted data, support access, subprocessors, analytics pipelines, backups, and group-company access.
Use a transfer branch that starts with adequacy, then appropriate safeguards such as Commission standard contractual clauses, and then any Article 49 derogation only when the GDPR conditions are actually met. Do not treat a vendor's certificate, security questionnaire, or generic DPA as a substitute for the transfer mechanism and evidence.
The output of the test should be compact enough to review but specific enough to prove the decision later. Save the facts, not just the conclusion. If the answer is outside GDPR scope, the record should still show the personal-data, role, and territorial-scope facts that made the team stop.
Reopen the test when the product changes data categories, adds profiling or monitoring, enters an EU market, changes vendors, adds support access from a new country, changes controller or processor roles, launches a child-facing service, or begins a new transfer path.
Yes. A non-EU controller or processor can be in scope for a processing activity that relates to offering goods or services to people in the Union or monitoring their behaviour in the Union. Record the targeting or monitoring facts and check the Article 27 representative branch.
No. The contract is evidence, but the role test is factual. Decide who determines the purposes and essential means of the specific processing activity, then align the Article 28 contract, records, transfer evidence, and vendor controls with that role.
Keep the personal-data inventory, processing activity, role analysis, Article 3 territorial-scope facts, special-category and child-data flags, vendor and transfer branches, cited source URLs, owner approval, and reassessment trigger.
Sorena can convert this GDPR applicability test into cited intake questions, owner assignments, vendor and transfer branches, evidence requests, and reassessment triggers for privacy, security, product, procurement, support, HR, and legal teams.
Ask source-linked questions about GDPR material scope, territorial scope, role classification, transfer branches, and evidence using the cited sources on this page.
Review your GDPR applicability workflow, vendor branches, transfer evidence, and source gaps with Sorena.
"actual roles of the parties"
"rather than a person"
"adequacy decisions"
"pre-approved by the European Commission"
"records of processing activities"