Privacy-preserving process mining

What is privacy-preserving process mining?

Privacy-preserving process mining is process analysis done with safeguards that limit how much it can reveal about individuals, cases and sensitive business behaviour. The aim is to still learn how a process runs while keeping that exposure in check.

Process logs are riskier than they look. The sequence of steps, the timing, the role involved and a rare variant can together make a case recognisable, so stripping out a name or a customer number does not make a trace anonymous.

The approach combines data minimisation, access control, limits on what the output can show and, where it fits, dedicated privacy techniques. No single trick covers it; the protection comes from stacking several.

What can leak

A trace can identify an employee, patient or customer through timestamps, location, a rare activity and a handful of attributes. On their own each of these looks harmless; combined they act as quasi-identifiers that narrow the field to one person.

It is not only the raw data. Organisational mining can expose how staff work and collaborate. A discovered process model can give away internal controls, volumes or commercial relationships. Even dashboards can single out a small group when a user keeps combining filters until only a few cases remain.

Start with minimisation

The cheapest protection is collecting less. Define the question, then use only the events, attributes, time span and level of detail it needs. Replace exact timestamps with a day or a week when order and throughput time still hold up. Analyse at team level when individual resources are not required.

Keep the raw data in a stricter zone and hand analysts a derived dataset instead. Less data lowers both the privacy risk and the chance of misreading the results.

Techniques, and their limits

Each of the common techniques helps with something and leaves something open.

• Pseudonymisation. Direct identifiers are swapped for codes, with a protected mapping so authorised users can still trace back when they must. Consistent codes keep traces analysable but raise linkability, and someone with context can still spot a rare pattern. Under GDPR, pseudonymised personal data is usually still personal data.

• Aggregation and generalisation. Show counts and performance per variant, team or period instead of individual traces, or replace detail with a broader category such as a job group instead of a named person. A k-anonymity style rule can require that any combination is shared by at least a set number of cases, though it does not stop every attack.

• Differential privacy. Calibrated randomisation is added so that the presence of any one individual barely changes the output. A privacy budget caps how much repeated queries can reveal, so small groups and heavy re-analysis cost accuracy or use up the budget.

• Secure computation and federation. Techniques such as secure multi-party computation, or bringing the calculation to the data instead of pooling it, let parties compute shared results without handing over raw input. They cut central collection but do not automatically solve output leakage or governance.

Privacy of models and visualisations

The output needs protecting too, not just the input. A directly-follows graph with an edge that occurred exactly once can point at a single unique case. A resource graph can make a small team identifiable.

Apply minimum counts, suppression and rounding, and control export functions as tightly as the dashboard itself. Watch for differencing attacks, where two almost identical filters together let someone infer information about one group that neither filter shows on its own.

Keeping the analysis honest

Every safeguard changes the data or the output, so measure which questions you can still answer reliably. Generalisation can preserve the order of steps while weakening timing analysis. Suppressing rare traces can remove the very compliance incidents you were looking for. Report those limits rather than presenting a privacy-friendly result as more precise than the treated data allows.

What to watch out for with privacy-preserving process mining

Technical privacy is not the whole of compliance. Record the purpose, the legal basis, transparency, retention, individual rights and any processors involved. Use access reviews, logging, secure workspaces and output checks, and train analysts to recognise re-identification risk.

Run a Data Protection Impact Assessment where it is needed, and involve privacy and employee representatives in line with the context. Review again whenever a new data source, attribute or analysis feature is added, because a dataset that was safe on its own can become sensitive once it is linked to something else.