A DPIA is not bureaucracy for its own sake. It is a structured risk assessment that helps organisations identify, evaluate, and mitigate privacy risks before they materialise — not after a data breach or supervisory authority investigation. Done properly, a DPIA improves the design of the system, reduces privacy risks, and demonstrates accountability under GDPR.

This article provides a practical template for ERP/CRM deployments. For broader compliance context, see Security and Compliance in Cloud ERP 2026.

When Is a DPIA Required?

Always Required (GDPR Article 35(3))

The regulation explicitly requires a DPIA for:

  1. Systematic and extensive evaluation of personal aspects based on automated processing, including profiling
  2. Processing of special categories of data on a large scale (Article 9: health, biometrics, racial origin, etc.)
  3. Systematic monitoring of a publicly accessible area on a large scale

Required Based on Risk Assessment (Article 35(1))

Likely required (check your supervisory authority’s list) for:

  • Employee monitoring systems — productivity tracking, location tracking, communication monitoring
  • Biometric time and attendance — fingerprint or facial recognition clocking
  • Large-scale HR systems — processing personal data of all employees including sensitive categories
  • CRM with profiling — behavioural analysis, propensity scoring, churn prediction based on personal data
  • Automated credit or risk scoring — decisions made solely or primarily by algorithms

When It Is Not Required

For ERP functions that do not process personal data or where risk is low:

  • Inventory management
  • Production planning without employee-level tracking
  • Financial reporting (aggregated, not personal)
  • Basic B2B CRM (company-level, not individual profiling)

If in doubt, conduct a preliminary assessment (screening) — 30 minutes to determine if a full DPIA is needed.

The 8-Step DPIA Process

Step 1: Describe the Processing

Document what you are doing:

  • Purpose — why is the data being processed? (e.g. “manage employee attendance and payroll”)
  • Data categories — what types of personal data are processed? (names, ID numbers, salary, health certificates, biometric data)
  • Data subjects — who are the individuals? (employees, contractors, job applicants)
  • Volume — how many individuals? How much data?
  • Duration — how long is data retained?
  • Legal basis — GDPR Article 6 basis (contract, legal obligation, consent, legitimate interests, vital interests, public task)
  • Recipients — who receives the data? (payroll processor, health insurer, tax authority, ERP vendor)

Step 2: Assess Necessity and Proportionality

For each element of the processing, ask:

  • Is this data necessary for the stated purpose?
  • Could the purpose be achieved with less data or less intrusive means?
  • Is the retention period proportionate to the purpose?
  • Is the legal basis appropriate for the purpose?

Document your answers. This step often reveals unnecessary data collection or excessive retention.

Step 3: Identify the Risks

List concrete risks to data subjects:

  • Unauthorised access — could data be accessed by someone without authorisation?
  • Data breach — what happens if the system is breached?
  • Unlawful use — could data be used for a purpose not disclosed to the individuals?
  • Discrimination — could automated processing lead to discriminatory outcomes?
  • Inaccuracy — what are the consequences of inaccurate data?
  • Loss of control — can individuals exercise their rights (access, erasure, correction)?

Rate each risk: likelihood × severity = risk level.

Step 4: Identify Existing Measures

Document existing technical and organisational measures that already address the identified risks:

  • Access controls (role-based, need-to-know)
  • Encryption at rest and in transit
  • Audit logging
  • Employee training
  • Contractual protections with processors (Data Processing Agreements)
  • Pseudonymisation or anonymisation where applicable
  • Data minimisation measures

Step 5: Assess Residual Risk

After accounting for existing measures, what residual risk remains? For each identified risk, determine if:

  • Risk is acceptable — existing measures are sufficient
  • Risk needs additional measures — specify what measures will be implemented
  • Risk is unacceptable — processing cannot proceed without fundamental redesign

Step 6: Consult the DPO (if applicable)

If your organisation has a DPO (Data Protection Officer — mandatory for public authorities, organisations doing large-scale systematic monitoring, and those processing special categories at scale), the DPO must be consulted during the DPIA process. The DPO’s advice must be documented and either followed or the reason for not following it recorded.

Step 7: Prior Consultation with Supervisory Authority (if residual risk is high)

If after Step 5, high residual risk remains that cannot be mitigated, GDPR Article 36 requires prior consultation with the supervisory authority before processing begins. The authority has 8 weeks to respond (extendable to 14 weeks for complex cases).

This is rare in practice — proper implementation of measures in Step 5 should reduce residual risk to acceptable levels for most ERP/CRM deployments.

Step 8: Document and Maintain

The DPIA must be:

  • Documented in writing
  • Signed off by the controller (CEO, DPO, or designated responsible person)
  • Kept on file and available to the supervisory authority on request
  • Reviewed and updated when processing changes significantly

Practical Example: HR Module with Biometric Time and Attendance

Processing description:

  • Purpose: manage employee attendance, calculate working hours for payroll
  • Data: employee name, employee ID, fingerprint template (biometric), timestamp of each clock-in/clock-out, location of terminal
  • Data subjects: ~150 employees
  • Retention: biometric template for duration of employment + 1 month; attendance records: 5 years (payroll legal requirement)
  • Legal basis: Article 6(1)(c) — legal obligation (working time law); Article 9(2)(b) — employment law necessity for biometric data
  • Recipients: payroll software provider, tax authority

Risk assessment:

RiskLikelihoodSeverityLevel
Biometric data breachLow (encrypted storage)High (cannot change fingerprints)Medium
Unauthorised access to attendance recordsLow (RBAC)MediumLow
Discrimination based on attendance patternsLowMediumLow
Employee profiling beyond stated purposeMediumHighHigh

Measures for high risk (employee profiling):

  • Access to attendance analytics restricted to HR Director and payroll staff only
  • Purpose limitation documented in DPA with payroll processor
  • Annual audit of who has accessed attendance analytics
  • Employees notified of data processing in employment contract

Residual risk: Medium — acceptable with documented measures.

Common Mistakes

Mistake 1: DPIA After Deployment

GDPR requires DPIA before processing begins. A retrospective DPIA for a system already in production is not GDPR-compliant. It also misses the point — the DPIA should inform the design decisions, not document them after the fact.

Mistake 2: Treating DPIA as a One-Off

A DPIA must be kept current. If you add a new HR module (e.g. performance management), expand CRM to new user groups, or change your cloud provider, the DPIA must be reviewed and updated.

Mistake 3: Not Involving the DPO

If you have a DPO, they must be involved from the start. Some organisations complete the DPIA and then send it to the DPO for sign-off — this is insufficient. The DPO should participate in identifying risks and measures, not just approve the final document.

Mistake 4: Vague Risk Assessment

A risk assessment that says “risk is low because we have security measures” without specifying which measures and how they mitigate which specific risks is not compliant. Be concrete.

Mistake 5: No Data Processing Agreement with ERP Vendor

The DPIA must cover all parties who process data on your behalf. If your ERP vendor processes personal data as a processor (not controller), you need a Data Processing Agreement (DPA) — and the DPIA must reference the contractual protections it provides.

Modulario and DPIA

Modulario supports clients’ DPIA obligations:

  • Data Processing Agreement — GDPR-compliant DPA provided as standard, covering all Modulario modules that process personal data
  • Sub-processor list — maintained and updated, clients notified of changes
  • Data location documentation — EU hosting confirmed, documented per module
  • DPIA assistance template — pre-filled DPIA template for standard Modulario HR, CRM, and payroll modules available to clients
  • Security documentation — ISO 27001 certification, encryption standards, access controls documented and available for DPIA reference
  • Audit log — read-only, exportable audit trail of all personal data access — supports DPIA measure implementation and verification

For broader compliance see Security and Compliance in Cloud ERP 2026 and the GDPR compliance checklist.

Frequently Asked Questions

When is a DPIA mandatory for ERP deployment? GDPR Article 35 requires a DPIA when processing is ‘likely to result in a high risk to the rights and freedoms of natural persons’. For ERP/CRM, a DPIA is practically always required when: (1) deploying HR modules processing employee personal data (salaries, performance evaluations, health data, location tracking), (2) CRM with large-scale profiling or behavioural analysis, (3) implementing biometric time and attendance (fingerprint, facial recognition), (4) automated decision-making with significant effects on individuals (automated credit scoring, automated candidate rejection). Your supervisory authority publishes a list of processing types always requiring DPIA — consult it before any new ERP module deployment.

How long does a DPIA take and how much does it cost? For a standard ERP module deployment, a DPIA takes 2-5 working days of a qualified person’s time (DPO, privacy lawyer, or trained internal resource). Cost for external DPO assistance: 500-2 €,000 depending on complexity. A DPIA is not a one-off document — it must be reviewed when the processing changes significantly (new module, new data categories, new purposes, change of processor). For a company with an internal DPO, budget 1-2 days per significant system change.

Does a DPIA replace the Record of Processing Activities (RoPA)? No — they are complementary. The RoPA (GDPR Article 30) is a register of ALL processing activities. The DPIA is a deeper risk assessment for HIGH-RISK processing only. Every processing activity should be in the RoPA; those that qualify as high-risk additionally need a DPIA. Both documents must be maintained and updated as processing changes.