Article 99: Entry into force and application

Article 99 sets the legal start date of the GDPR: it entered into force twenty days after publication in the Official Journal of the European Union ¹. To operationalize it, you must document your GDPR applicability assumptions and ensure every in-scope processing activity is governed by GDPR controls as the baseline compliance regime.

Key takeaways:

• Treat Article 99 as a governance requirement: prove you recognize GDPR as applicable law for in-scope EU/EEA personal data processing ¹.
• Operationalize via a role-and-scope register that ties controller/processor role decisions to systems, data, and third parties.
• Keep an “evidence packet” that shows the requirement is embedded in onboarding, change management, and risk acceptance workflows.

“Entry into force and application” sounds like pure legal housekeeping, but it becomes operational the moment a regulator, customer, or auditor asks a simple question: “Why do you believe GDPR applies to you, and where is that reflected in your controls?” Article 99 answers the first part by fixing GDPR’s legal start date and confirming it is a directly applicable EU Regulation once effective ¹.

For a Compliance Officer, CCO, or GRC lead, the practical work is not calculating dates. The practical work is making GDPR “real” inside your operating model: defining where you act as controller vs. processor, mapping which products and business units are in scope, ensuring third-party arrangements follow the same scoping logic, and retaining defensible evidence. This page gives you requirement-level implementation guidance for the article 99: entry into force and application requirement, with steps, artifacts, and audit-ready talking points.

Regulatory text

Excerpt (verbatim): “This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union.” ¹

What the operator must do with this text

Article 99 does not require you to perform a specific control activity on a schedule. Instead, it establishes the legal premise that GDPR became binding EU law as of its effective date ¹. Your operational obligation is to treat GDPR as the governing privacy baseline for any processing where GDPR applies, and to be able to demonstrate that your program’s scope and role decisions are anchored to that reality.

In practice, Article 99 becomes “testable” through governance evidence:

• You have a documented determination of whether GDPR applies to your processing contexts.
• You have a documented determination of what role you play (controller/processor) for each processing activity.
• You can show GDPR controls are embedded in the workflows where processing begins or changes (product intake, procurement, onboarding, system changes).

Plain-English interpretation (what this requirement means)

• GDPR has been in effect since shortly after it was published in the EU’s Official Journal ¹.
• You cannot treat GDPR as optional guidance. If you process personal data in a way that falls under GDPR’s scope, GDPR is the default rule set.
• The compliance “work product” is your scope, role, and applicability governance, plus evidence that day-to-day execution follows that governance.

Who it applies to (entity and operational context)

Article 99 is part of GDPR itself, so it is relevant to any organization evaluating GDPR applicability for:

• Controllers deciding purposes and means of processing.
• Processors processing personal data on behalf of a controller.
• Organizations with mixed roles across products, business units, and third parties.

Operational contexts where this requirement matters most:

• New product launches and new data uses (especially new categories of personal data or new regions).
• Third-party engagements where processing roles are ambiguous (common with SaaS platforms, analytics providers, managed service providers, and affiliates).
• M&A / integration where inherited systems and datasets may be in scope, but ownership and accountability are unclear.
• Customer and partner diligence where you must explain your GDPR posture and show governance artifacts.

What you actually need to do (step-by-step)

The goal is a repeatable governance mechanism that turns “GDPR is in force” into “GDPR is operational here.”

Step 1: Create an Article 99 applicability statement (one page)

Write a short internal statement that:

• Identifies GDPR as an applicable regulation for your in-scope processing ¹.
• States how your organization determines in-scope processing (by geography, establishment, data subject location, offering context, or other internal criteria you use).
• Names accountable owners (Legal for interpretation, Privacy for program, Security for technical controls, Procurement for third-party integration).

Keep it short. The value is in adoption and consistent use.

Step 2: Build and maintain a GDPR role-and-scope register

Create a register (sheet or GRC system) that ties each processing context to:

• Controller vs. processor role decision
• Business unit / product
• Data categories (customer, employee, prospect, end user)
• Systems involved (core app, data warehouse, support tools)
• Third parties involved (sub-processors, joint controllers, independent controllers as relevant)
• Link to your record of processing activity (if you keep one), DPIA/TRA decisions (if applicable), and contract addenda

This register is how you prevent “silent non-compliance,” where teams process data under the wrong role assumptions.

Step 3: Add “GDPR applicability + role check” to intake gates

Embed two questions into the workflows where processing starts or changes:

1. Does this initiative involve personal data in a way that might be in GDPR scope?
2. Are we acting as controller, processor, or both?

Common intake gates:

• Product change management
• New system onboarding
• Data sharing approvals
• Third-party onboarding and renewals
• Security architecture review

Make “no register entry, no go-live” a practical rule for higher-risk launches.

Step 4: Define a requirement-specific operating procedure (SOP)

Write an SOP that tells operators exactly what to do when:

• A new system is purchased
• A new dataset is introduced
• A third party is added
• A product expands to EU/EEA markets
• A customer asks for GDPR contract terms or evidence

Your SOP should specify:

• Required approvals (Privacy + Legal for role decisions; Security for control requirements)
• Required artifacts (register update, contract review outcomes, exception record)
• Decision time expectations (set internally; don’t over-engineer)

Step 5: Produce an auditable evidence packet on a recurring cadence

Because Article 99 is foundational, auditors test it indirectly by asking for “proof of GDPR governance.” Package evidence so it’s easy to produce:

• Current role-and-scope register export
• Recent samples of intake tickets showing role decision + scope decision
• Exceptions and risk acceptances, with remediation tracking
• Training/enablement artifacts for intake owners (product, procurement, engineering)

If you use Daydream, this is where it fits naturally: store the Article 99 applicability statement, map it to your scoped systems and third parties, and keep evidence packets attached to the requirement so diligence requests are not a scavenger hunt.

Required evidence and artifacts to retain

Minimum artifacts that hold up in real reviews:

• GDPR applicability memo/statement referencing Article 99 as the legal “in force” anchor ¹.
• Role-and-scope register with last updated date, owners, and change history.
• SOP / work instruction for role and scope determination.
• Intake workflow evidence (tickets, forms, approvals) showing the SOP is followed.
• Third-party due diligence records showing role alignment (controller/processor) and contract path based on that decision.
• Exception log documenting deviations and compensating controls.

Retention tip: keep evidence in a single “GDPR governance” folder structure by quarter or review cycle so you can respond fast.

Common exam/audit questions and hangups

Questions you should be ready to answer crisply:

• “How do you determine whether GDPR applies to a product or business unit?” Expect follow-ups on consistency and ownership.
• “Where do you document controller vs. processor role decisions?” Auditors want one system of record.
• “Show me two recent examples where a project updated the register before go-live.” Sampling is common.
• “How do third parties get classified, and how does that change your contracting path?” This is a frequent hangup because procurement often runs a parallel process.

Typical hangup: teams confuse “GDPR effective date” with “we’re compliant.” Article 99 does not certify compliance. It removes ambiguity that the regulation is active law ¹. Your evidence must show the program operates accordingly.

Frequent implementation mistakes and how to avoid them

1. Treating Article 99 as non-actionable legal boilerplate
   Fix: make it a governance control. Require an applicability statement and a scope register entry for in-scope processing.

2. No single owner for role decisions
   Fix: define a RACI. Legal interprets edge cases, Privacy owns the register, business owners supply processing detail, Procurement enforces third-party gates.

3. Role decisions made once and never revisited
   Fix: tie updates to trigger events (new region, new data categories, new third party, architectural changes).

4. Third-party sprawl outside the privacy program
   Fix: connect procurement intake to the same register and require contract path alignment to the role decision.

Enforcement context and risk implications

No specific public enforcement cases were provided for Article 99 in the source catalog. Practically, Article 99’s risk is indirect: if you cannot demonstrate that GDPR is treated as applicable law for in-scope processing, regulators and customers will question the credibility of your entire GDPR program. This shows up as control gaps across contracts, transparency, security measures, and rights handling, even though Article 99 itself is a short provision ¹.

Practical 30/60/90-day execution plan

Numeric day-based plans would require a sourced duration claim under the rules for this page, so use phased execution instead.

Immediate phase (stabilize scope and ownership)

• Draft and approve the Article 99 applicability statement ¹.
• Assign owners for role decisions and scope determinations.
• Inventory your intake gates (procurement, SDLC, data sharing) and pick one as the initial enforcement point.

Near-term phase (make it operational)

• Stand up the GDPR role-and-scope register and populate it with your highest-impact systems and third parties first.
• Publish the SOP and integrate it into one intake workflow (for example, procurement onboarding or product change review).
• Build an evidence packet template (what to store, where, and who updates it).

Ongoing phase (make it auditable and resilient)

• Expand register coverage to remaining systems, business units, and third parties.
• Add periodic reviews tied to your existing governance cadence (risk committee, vendor review cycle, product governance).
• Track exceptions and remediation to closure, and keep samples ready for audits and customer diligence.

Frequently Asked Questions

Does Article 99 require me to do anything beyond knowing the GDPR effective date?

Yes, operationally it requires you to treat GDPR as binding law for in-scope processing and be able to prove your program is scoped accordingly ¹. The proof is governance: role decisions, scope documentation, and embedded intake gates.

How do I “audit” compliance with Article 99 if it’s just an entry-into-force clause?

Audit it indirectly by testing your GDPR applicability determination and your role-and-scope register. If teams cannot show consistent scope and controller/processor decisions, your GDPR control environment is not reliably anchored to an applicable regulation ¹.

We’re a processor. Do we still need a role-and-scope register?

Yes. Many organizations are processors for some services and controllers for others, and the obligations differ by role. A register prevents accidental controller-like behavior under processor contracts and helps procurement and security apply the right control set.

What evidence should I provide in a customer diligence questionnaire tied to Article 99?

Provide your GDPR applicability statement, a sanitized excerpt of the role-and-scope register (systems and third parties), and a sample SOP-driven intake record showing review and approvals. Keep the underlying evidence packet available if the customer asks for deeper validation.

Who should approve controller vs. processor role decisions?

Privacy should own the workflow, Legal should approve edge cases and contracting implications, and the business/system owner must attest to the actual purposes and means. Write this into the SOP so approvals do not drift over time.

How does Daydream fit without turning this into a tool exercise?

Use Daydream as the system of record for the role-and-scope register, the SOP, and the evidence packet. The value is faster, more consistent production of audit artifacts tied to a specific requirement, rather than scattered documents across teams.

Footnotes

1. Regulation (EU) 2016/679, Article 99