The ERP Decision: Security's Seat Before the Implementation Starts

The ERP project kicks off in Q1. The implementation partner has a methodology, the steering committee has a charter, and security is not in either. It will arrive in month fourteen, when someone asks whether the new system can pass the customer audit, and the answer will be expensive.

ERP implementations concentrate every technology risk a company has into one project: all the data moves, every process changes, dozens of people get new access, and a vendor with its own incentives holds the pen. It is the highest-stakes technology event most companies ever run, and it is routinely the one where security has the least voice.

The fix costs almost nothing: a seat at the table from the first design workshop, and four questions that get asked at every stage gate.

TLDR

• ERP projects concentrate all your technology risk into one event.

• Security in month one is a conversation; in month fourteen it is a change order.

• Four gate questions: data classification, access design, vendor access, cutover rollback.

• The implementer's incentives are timeline and budget; someone must own the risk lens.

• Old-system retirement is part of the project, not an afterthought.

Why ERP projects attract the worst surprises

The pattern is so common it has a rhythm. The design phase optimizes for process fit and timeline. Access gets granted broadly because narrowing it is friction. Data migrates in bulk because sorting it is friction. The implementer's consultants get standing access because revoking and re-granting is friction.

Each choice is reasonable in the room where it is made. The compound interest arrives later: the audit finding, the departed consultant's still-active account, the decade of customer history sitting in a module nobody uses but everyone can read.

None of this requires malice or even incompetence. It requires only that nobody in the room was responsible for asking the awkward question.

The four gate questions

The security seat earns its keep with four questions, asked at every stage gate until they become habit.

What data is moving, and does all of it need to? Migration is the one chance to leave the rotting archive behind; everything you move, you protect forever. How will access be designed - by role, from the start - rather than granted ad hoc and rationalized later? What standing access does the implementer hold, on what does it expire, and who revokes it at go-live? And what is the rollback story if cutover weekend goes badly?

This fictional example shows the four answers from a well-run gate review. It is an illustration, not a prescription.

Gate question	Answer	Owner
Data moving	7 of 12 legacy modules; archive left read-only	Ops lead
Access design	14 roles defined pre-build	Implementer + HR
Vendor access	Named accounts, expire at go-live + 30 days	IT
Rollback	Old system frozen, not deleted, for 90 days	IT

The retirement nobody schedules

The ERP project's last chapter is the one that gets skipped: the old system lingers. It stays reachable 'just in case,' unpatched, unmonitored, holding a decade of history, still connected to the network the new system runs on.

The decommission belongs in the project plan with a date and an owner: what gets archived, where it goes read-only, when the old system actually goes dark. The checklist for retiring a system without leaving doors open was written for exactly this moment.

Companies that skip it discover the old system at the worst time - during an incident, when the forgotten server turns out to be the way in.

Getting the seat without a security team

No security department is not an obstacle; the seat needs a person, not a department. The operations lead, the IT manager, or an outside advisor can hold the four questions. What matters is that someone at every gate is measured on the risk lens rather than the timeline.

For the steering committee, the standing agenda item is one line: 'security questions - anything we are deferring?' Deferred knowingly is a decision. Never asked is an accident.

The capital-request discipline runs in parallel; the security questions that belong in every capital request were designed for exactly this kind of spend.

The related discussion of retiring a system without leaving doors open is worth your time alongside this one. The related discussion of security questions that belong in every capital request is worth your time alongside this one.

Frequently asked questions

Our implementer says security is built into their methodology. Is that enough?

Ask to see the gate artifacts: the access design document, the data migration scope, the consultant access register. Good methodologies produce these on request. If the answer is 'trust us,' you have learned what you needed to know.

When should security first appear in the project?

At software selection, before signature. The vendor's security posture, hosting model, and access architecture are selection criteria, and they are nearly impossible to renegotiate after the contract is signed.

What is the single most-skipped item?

Old-system retirement. Every ERP project plans the cutover; few plan the burial. Put the decommission date in the project charter on day one, or the old system will outlive the project manager.

A Defensible Next Step

If an ERP project is anywhere on your horizon, put the four gate questions in the charter now, while they cost nothing. Month-one questions are conversations; month-fourteen questions are change orders. Book a Decision-Clarity Call if you want the gate review designed.