GDPR monitoring after launch: what to check, how often, and why

GDPR gives you no certificate to pass, so there is nothing to coast on afterwards. Article 5(2) makes you responsible for demonstrating compliance at any time. In practice that means a small, repeating set of checks on records, processors, rights requests, breaches and security, each leaving dated evidence behind.

Why does GDPR need monitoring at all?

Most privacy programs decay the same way. A team writes a record of processing, signs processor agreements and publishes a notice. Twelve months later a new analytics tool, a new sub-processor and two product features have changed the facts, and the paperwork describes a company that no longer exists.

Regulators and customers do not ask whether you did the work once. They ask whether the records match reality today. Article 5(2) calls this accountability: you are responsible for compliance and must be able to show it. Article 32(1)(d) adds a specific hook for security, a process for regularly testing and evaluating the effectiveness of your technical and organisational measures.

What should you check, and how often?

Think in three speeds: continuous, quarterly, annual.

Continuous (automated where you can)

• New systems, SaaS tools and data stores that touch personal data. If procurement or engineering can add one without a privacy check, your Article 30 record is already stale.
• Security signals tied to personal data: vulnerable dependencies in services that process it, public storage, unreviewed admin access.
• Breach intake. Article 33 gives a controller 72 hours, where feasible, from becoming aware to notify the supervisory authority, so the clock is short and the intake channel must always work.

Quarterly

• Rights requests: count them, check each was answered inside the one month limit in Article 12(3) (extendable by two further months with notice), and look for patterns that point to a broken process.
• Processor list: compare what finance pays for against your processor register. Differences are unregistered processors.
• Access to systems holding personal data: remove leavers and role changes.

Annual

• Re-read the Article 30 record end to end with each system owner.
• Re-check the lawful basis and retention period for each purpose.
• Review each processor against the Article 28 terms, including its audit and breach notice commitments.
• Run a breach tabletop. Time how long it takes to decide whether a scenario is notifiable.
• Revisit any data protection impact assessment where the processing changed.

What evidence proves the monitoring happened?

Keep one dated artefact per check. A spreadsheet export with a reviewer name and a date beats a paragraph saying "reviewed". Useful items:

• The Article 30 record with a change log showing who edited what and when.
• Quarterly rights request log with receipt date, response date and outcome.
• Processor register with agreement date, sub-processor list version and last review date.
• Breach and near miss register. Article 33(5) requires you to document every personal data breach, including ones you decide not to notify, with the facts, effects and remedial action.
• Security test results and the tickets that closed the findings.
• Meeting notes where the privacy lead and engineering agreed changes.

Which mistakes show up most?

• Monitoring the policy, not the system. The privacy notice is current but the product ships a new tracker nobody told you about.
• No owner. Quarterly checks without a named person become annual checks, then none.
• Treating near misses as nothing. If you do not log them you cannot show why you did not notify.
• Forgetting processors' own changes. A vendor adds a sub-processor and you learn about it from a customer.
• Evidence in people's heads. When the privacy lead leaves, the program leaves with them.

Fines are a reason to care, not a plan. Article 83 sets ceilings of up to 10 million euros or 2 percent of worldwide annual turnover for some infringements and up to 20 million euros or 4 percent for others. The practical goal is to have the answer ready before anyone asks.

What to do

1. Name an owner for each recurring check and put the dates in a shared calendar.
2. Add a privacy check to the way new tools and features are approved, so the record updates at the moment of change.
3. Build a one page monthly view: open rights requests, breach register changes, processor changes, open security findings touching personal data.
4. Run the quarterly checks above and save the exports with dates.
5. Schedule the annual record review and breach tabletop now.
6. Store everything in one folder structure by year and control so an authority or customer can be answered in a day.

Quick check

How Safeguard helps automate this

Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. For a monitoring program that means evidence is collected from connected systems and code rather than by screenshot, and the checks keep running between reviews. The technical side is grounded in your real code and dependencies: scans, SBOMs and reachability show which vulnerable packages sit in services that handle personal data. If you choose, Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you decide which categories run automatically and at what approval level. Safeguard helps prepare and keep evidence ready. It does not make you compliant, and your regulator or auditor decides that. Book a call to see it.

Sources

• GDPR Article 5, principles
• GDPR Article 12, transparent communication
• GDPR Article 28, processor
• GDPR Article 30, records of processing
• GDPR Article 32, security of processing
• GDPR Article 33, breach notification
• GDPR Article 83, fines

These pages are an unofficial but complete copy of the Regulation text. The official text is on EUR-Lex.

Last reviewed: 18 October 2026.