ERP Project Cybersecurity: 8 Risks to Control from Selection to Go-Live

An ERP project mobilises, over 12 to 18 months, a dozen external contributors with broad access to your most sensitive data. Income statements shared during an RFP process, production database dumps copied into test environments, consultant VPN connections active 24/7 without individual session logging: the project phase opens an attack surface that most production security policies simply do not cover.

This article focuses exclusively on security risks specific to the project period (from vendor selection through the end of the hypercare phase), as distinct from the security risks of a live ERP system, which we cover in our ERP cybersecurity guide.

Why the ERP Project Is a Unique Vulnerability Window

A live ERP system, in mature organisations, is governed by access policies, regular access reviews, and monitoring tools. The project phase inverts this logic: it multiplies temporary access grants, often issued under time pressure, without systematic review or expiry dates.

Three factors amplify the risk:

1. External contractors access data directly: system integrators, software vendors, and consultants need access to environments — sometimes to databases directly — to configure, test, and migrate. This structural access differs fundamentally from a maintenance contractor who only intervenes during incidents.

2. Environments multiply: user acceptance testing (UAT), pre-production, training, sandbox. Each environment is a potential entry point, usually less monitored than production.

3. NIS2 extends your responsibility to suppliers: Directive (EU) 2022/2555, transposed across EU member states, requires important and essential entities to manage the cybersecurity risks of their digital supply chain (Article 21, NIS2 Directive). An external ERP integrator falls squarely within this scope.

Selection Phase: Risks 1 and 2

Risk 1: Sharing Sensitive Data in the RFP and Demo Process

To write a realistic requirements document and evaluate demos, project teams routinely share data representative of their operations with candidate vendors and integrators: chart of accounts, supplier lists, order volumes, sometimes a customer file extract.

This data circulates by email or through unencrypted file-sharing platforms, reaching multiple vendors who will not win the contract and have no contractual security obligations at this stage.

What to do:

• Classify data shared in the RFP (public, internal, confidential) and restrict confidential data to shortlisted vendors only.
• Require a signed NDA before sharing any data, even volume statistics.
• Prepare realistic synthetic datasets for demonstration phases: identical formats to real data, representative volumes, but containing no actual personal or commercial data.
• For demos run on a vendor’s own tenant, verify the data retention policy for demo environments.

Risk 2: Insufficient Security Clauses in the Integrator Contract

The contract with an ERP integrator typically covers timelines, methodology, and deliverables. Security clauses are often absent or limited to a generic reference to “confidentiality.”

Yet as soon as the integrator accesses personal data (employees, customers, suppliers), the GDPR mandates a Data Processing Agreement (DPA) under Article 28 of the regulation. This DPA must specify the nature of processing, security obligations, incident notification procedures, and the obligation to destroy data at the end of the engagement.

What to do:

• Include a GDPR Art. 28-compliant DPA in every ERP integration contract.
• Define remote access conditions explicitly in the contract: authorised protocols (VPN with MFA, no direct RDP), permitted hours, logging requirements.
• Add an incident notification clause within 24 hours (aligned with NIS2 timelines).
• Include an audit clause allowing the organisation to verify the contractor’s security practices during and after the project.
• Mandate verifiable data destruction after project completion.

Installation and Configuration Phase: Risks 3 and 4

Risk 3: Uncontrolled VPN/Remote Access by Integrator Teams

In common practice, integrator consultants receive permanent VPN access for the full duration of the project, with no time restrictions, from any workstation. Connections are logged at the network level but rarely correlated to individual identities.

This model creates several problems: a consultant who leaves the integrator firm may retain access if the account is not disabled. A compromised workstation at the vendor’s office opens a direct path into your environment. And without individual session logging, any forensic investigation becomes nearly impossible.

ENISA and NIST guidelines on third-party access both recommend restricting external access to the hours actually required and mandating multi-factor authentication for all remote access (NIST SP 800-35; ENISA supply chain security guidelines).

What to do:

• Restrict VPN access windows to declared working hours (e.g. Monday–Friday, 8 AM–7 PM) with automatic deactivation outside those windows.
• Require multi-factor authentication for all remote access to the information system.
• Log sessions individually (named user identity, timestamp, actions performed) and retain logs for at least 12 months.
• Run a monthly review of active accounts and disable any account whose consultant is no longer on the project.

Risk 4: Shared “Super-Admin” Project Accounts Used by Multiple Consultants

To simplify initial configuration, project teams often create one or two shared administration accounts for all consultants on the integrator team. These accounts carry broad rights across the entire system.

This sharing violates the principle of accountability: if an incident occurs — an incorrect configuration change, a data exfiltration, a malicious script deployment — it becomes impossible to identify which individual was connected. It also violates NIS2 recommendations on identity management.

What to do:

• Create individual, named accounts for every consultant, even for temporary access.
• Apply the principle of least privilege: each consultant accesses only the modules and data required for their specific role.
• Document a project access matrix (who accesses what, at which phase, with what permission level).
• For sensitive administrative operations (production configuration changes), implement a two-person authorisation control.

User Acceptance Testing (UAT) Phase: Risks 5 and 6

Risk 5: Using Live Production Data in the UAT Environment

This is the most common and least visible risk. To make UAT realistic, project teams regularly copy a production database dump into the test environment: customer data, payroll records, company registration numbers, personal contact details.

This practice is a direct GDPR violation: personal data cannot be used outside the context for which consent was collected, and test environments typically lack the same security controls as production (broader access, less rigorous logging, less frequent backups).

Data protection authorities consistently remind organisations that personal data must be protected throughout its entire processing lifecycle, including transfer phases, and that temporary files containing personal data must be destroyed once their purpose is fulfilled.

What to do:

• Define a test data anonymisation policy at project launch, before any data is copied.
• Use anonymisation tools or synthetic data generation solutions (several open-source options exist for common databases).
• If using real data is deemed essential for specific test scenarios, submit the case to the DPO and document the decision along with compensating controls.
• Apply the same access controls to the UAT environment as to production if it contains personal data.

Risk 6: Test Environments Not Decommissioned After Go-Live

UAT, training, and pre-production environments created during the project often remain active for months after go-live, with no formal decommissioning procedure. These environments retain old access accounts (including those of consultants), test data sourced from production, and relaxed security configurations.

These forgotten environments are prime targets: they are less monitored, contain sensitive data, and often connect to the same databases or close replicas of production.

What to do:

• Include a temporary environment decommissioning procedure in the go-live plan.
• Set an automatic expiry date for every non-production environment created during the project.
• Document an inventory of all active environments and include it in project close-out deliverables.
• Ensure test environments do not share production databases — even read-only — after go-live.

Data Migration Phase: Risk 7

Risk 7: Personal Data Exposed During Migration Scripts and ETL Files

The migration phase generates large volumes of intermediate files: extractions from the legacy system, transformation files (CSV, Excel, JSON), and loading scripts for the new ERP. These files systematically contain personal data (customers, employees, suppliers) and circulate between internal teams and the integrator.

The channels used are often poorly secured: email, unencrypted file sharing, FTP without TLS. These files accumulate on workstations and servers with no planned destruction procedure.

What to do:

• Inventory all migration files containing personal data and classify them.
• Use encrypted transfer protocols exclusively (SFTP, HTTPS, S3 bucket with server-side encryption) for transmitting these files.
• Encrypt files at rest whenever they contain personal data.
• Define a verifiable destruction procedure: after successful load validation, all intermediate files must be securely deleted and the destruction documented.
• Map the complete data flow: who holds what, on which medium, since when.

Our ERP data migration methodology guide covers the technical details of this flow in depth.

Go-Live and Hypercare Phase: Risk 8

Risk 8: Consultant Access Not Revoked After the Warranty Period

After go-live, a hypercare period of one to three months keeps integrator teams engaged to stabilise the system. At the end of this period, access must be revoked. In practice, it often remains active due to lack of a formalised procedure.

ENISA and NCSC guidance recommends revoking third-party access within five business days of the end of an engagement. These dormant accounts with elevated privileges represent a persistent vulnerability: the contractor may have changed staff, the workstations involved are no longer under active monitoring, and external audits regularly surface residual access grants with permissions that should have been closed months earlier.

What to do:

• Schedule access revocation in the project plan, with a target date and a named owner.
• Conduct a full account audit 30 days after go-live.
• Set up an automatic alert for contractor accounts inactive for more than 30 days.
• Maintain a revocation log (who, when, authorised by whom) for at least 12 months.

CISO Checklist: 20 Control Points Before Final Acceptance

Before signing off on final project acceptance, verify these 20 points with the integrator:

Access Governance

1. All contractor accounts are individual and named (no shared accounts).
2. The project access matrix is documented and up to date.
3. VPN/remote access is protected by MFA.
4. Time-restricted access windows were enforced (verify against logs).
5. Accounts of consultants who left the project mid-engagement were disabled promptly.

Data

6. The UAT environment never used non-anonymised personal data (or a DPO-documented exception with compensating controls is in place).
7. All migration files containing personal data were destroyed after successful load validation.
8. A GDPR Art. 28-compliant DPA is signed with the integrator.

Environments

9. An inventory of all temporary environments created during the project is available.
10. All non-production environments no longer required for operations have a scheduled decommissioning date.
11. Test environments no longer contain real personal data.
12. Test databases have been decoupled from production.

Traceability

13. Contractor access logs cover the full project duration and are stored for at least 12 months.
14. Sensitive administrative actions (configuration changes) are individually traceable.
15. A contractor access register (who, rights, period) was maintained throughout the project.

Contractual and NIS2

16. The integrator contract includes a 24-hour incident notification clause.
17. The data destruction clause has been executed and documented.
18. The contractor has provided security certifications or evidence of practices (ISO 27001, ENISA self-assessment, SOC 2, etc.).
19. The integrator’s sub-contractor chain (software vendor, cloud hosting) has been documented and accepted.
20. A revocation plan for remaining consultant access is scheduled with a date and a named owner.

Embedding Project Security into Your ERP Governance from Day One

ERP project security cannot be improvised at the finish line. It is built from the selection phase — in the requirements document, in contracts, in the access grants made in the first weeks of the project.

The CISO must be involved from project kick-off, not simply called in to sign off on a penetration test in pre-production. Their scope during the project covers contractor access governance, test data protection, migration procedure validation, and oversight of the revocation plan.

NIS2 provides an additional lever: if your organisation qualifies as an important or essential entity, third-party risks are an explicit control point during audits. Documenting your project practices against the 8 risks described above constitutes solid initial evidence for a NIS2 auditor.

To go further, see our NIS2 ERP evidence checklist for cybersecurity audits and our zero trust and ERP access management guide, which cover system security in the operational phase.