What it means
Privacy runtime monitoring detects when deployed processing diverges from approved purpose, data scope, access, destination, retention, consent, or user-choice expectations.
Why it matters
Design-time review cannot see configuration drift, unexpected queries, new fields, silent recipients, stale preferences, or code paths that emerge in production.
Practical focus
- Instrument sensitive collection, access, use, transfer, export, model, preference, deletion, and policy-enforcement events.
- Define privacy-relevant baselines, rules, lineage checks, alerts, ownership, severity, investigation, and safe response actions.
- Protect monitoring data itself through minimization, access control, retention, aggregation, and purpose limits.
- Preserve this evidence: Retain monitored-event definitions, approved baselines, alert logic, investigations, false-positive analysis, incidents, corrective changes, and control tests.
- Exercise this failure scenario: A release begins sending a new attribute to an analytics endpoint, but no privacy signal detects the unapproved data flow until a complaint arrives.
Common mistakes
- Using the label Privacy Runtime Monitoring without defining scope, ownership, decision authority, and the exact data, systems, people, or process affected.
- Treating a policy, contract, diagram, dashboard, or tool demonstration as proof that Privacy Runtime Monitoring operates consistently in production.
- Closing work without retaining the evidence needed to reconstruct the decision and verify the intended control outcome.
- Testing only the normal path and never rehearsing the failure condition: A release begins sending a new attribute to an analytics endpoint, but no privacy signal detects the unapproved data flow until a complaint arrives.
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: