Privacy in ERP Systems: Behavioral Models of Developers and Consultants

Applications like Enterprise Resource Planning (ERP) systems have become an indispensable part of the corporate digital infrastructure. These systems store sensitive data about customers, suppliers, and employees, and thus companies have to process these data in accordance with applicable regulations like the GDPR (the EU General Data Protection Regulation). This can be challenging due to a variety of reasons. For example, prior research has shown that developers sometimes lack knowledge about privacy. In this work, we focus on privacy in ERP systems in the context of an international consultancy firm. We investigate the privacy awareness regarding privacy-by-design and data minimization of two important populations: developers of ERP systems and managers and consultants responsible for services related to ERP systems. Applying thematic analysis, we elicit privacy behavioral models of these two populations using Fogg’s Behavioral Model (FBM) framework. Our findings provide a means to stimulate more adequate privacy-related behaviors for developers and consultants.

💡 Research Summary

This paper investigates privacy‑related behaviors of two key stakeholder groups—ERP developers and consultants/managers—within a multinational consulting firm in the Netherlands. Recognizing that ERP systems process large volumes of personal data, the authors focus on two GDPR‑mandated principles: data minimization and privacy‑by‑design (PbD). Using semi‑structured interviews with 16 participants (7 developers, 9 consultants/managers), the study applies Braun and Clarke’s five‑phase thematic analysis to generate a codebook, which is then mapped onto BJ Fogg’s Behavior Model (FBM) comprising Motivation, Ability, and Trigger.

Key findings reveal that motivation is a mix of external pressures (legal sanctions, client expectations) and internal drivers (professional identity, ethical responsibility). However, many developers mistakenly assume that ERP platforms are “privacy‑by‑default,” weakening intrinsic motivation. Ability gaps are evident: developers lack concrete technical skills for implementing data‑minimization techniques (e.g., field‑level masking), while consultants struggle with inadequate client data‑governance, leading to manual, error‑prone access‑control processes.

Triggers identified include regulatory audits (short‑term prompts), explicit client demands or breach incidents (strong prompts), and internal process changes such as the rollout of new ERP modules or automated data‑labeling tools (sustained prompts). The study also highlights divergent perspectives: developers focus on technical implementation, whereas consultants emphasize organizational and procedural responsibilities, suggesting distinct FBM pathways for each group.

Practical implications propose tailored interventions: for developers, provision of concrete design patterns, automated testing tools, and PbD checklists; for consultants, client‑focused privacy training, contractual privacy clauses, and stage‑gate privacy reviews. At the organizational level, firms should collaborate with ERP vendors to secure explicit privacy certifications and institutionalize regular audits and training to reinforce motivation and triggers.

Limitations include a single‑company, single‑country sample and reliance on self‑reported data, which may introduce social desirability bias. Future work should expand to multiple firms and countries, and employ quantitative surveys to validate the FBM‑based behavioral model.

Overall, the paper contributes a nuanced, behavior‑theoretic understanding of privacy practices in ERP contexts and offers actionable strategies to enhance GDPR compliance among developers and consultants.