Why JD Edwards Security Cleanup Projects Stall
June 29th, 2026
15 min read
This discussion explores why JD Edwards security cleanup projects often stall before completion and what organizations can do to successfully restart and sustain them. Brian Connor explains how issues such as role sprawl, unclear ownership, limited business involvement, inadequate planning, and weak governance create obstacles that prevent meaningful progress. The conversation emphasizes that security cleanup is not simply an IT initiative but a business risk management effort that requires collaboration between IT, business process owners, compliance teams, and internal audit.
Table of Contents
- Introduction: Why JD Edwards Security Cleanup Projects Stall
- Common Triggers and Root Causes of Security Cleanup Efforts
- Role Sprawl, Access Growth, and User Resistance
- Why Cleanup Projects Lose Momentum
- Ownership, Business Involvement, and Governance
- Restarting a Stalled Security Cleanup Project
- Reducing Risk Without Disrupting Operations
- Sustaining Security Improvements and Measuring Success
Introduction: Why JD Edwards Security Cleanup Projects Stall
Introduction: Why AI Agent ROI Matters in JD EdwardsWhy do so many JD Edwards security cleanup projects start strong and then stall before real progress is made? And how can teams reduce access risk without disrupting the business?
Today we're joined again by Brian Connor to unpack the common reasons JD security cleanup projects get stuck, from role complexity and unclear ownership to audit pressure and fear of removing the wrong access. By the end, you'll have a practical way to restart a stalled cleanup effort and keep it moving.
Welcome back tonight, your grandma's JD Edwards, the podcast for JD Edwards News modernizing, improving, and making smarter decisions about their ERP environments. I'm your host Nate Bush showed. And today, we're talking about a problem many JDE customers know well, security cleanup projects that never quite get finished.
These projects often start with urgency and audit, finding too much user access, roll sprawl, or concern over compliance risk. But once teams get into the details, momentum can fade fast. And that's because JD Security Cleanup is not just a technical project. It touches business processes, user productivity, compliance, change control and risk management.
And to help us break it down, today we are joined once again by Brian Connor, a recurring guest on the show and a trusted voice on JD Edwards Security.
Brian, welcome back. But for the listeners out there that may have not caught your previous episodes, could you give us a quick refresher on your background and kind of JD security work you help customers with?
Absolutely. Thanks for having me back, Nate. And I would say go look for those episodes. Go find them and download them and listen to them.
I've been working in JDE since 1995 and focused on security and compliance since 2009 exclusively.
What do I do? I help JDE customers identify, prioritize, remediate and monitor financial and operational risk.
Yeah, yeah. And you've been doing that for many years now. And we love having you on the show because it we really do talk deeply about JD Edwards security like we're doing today.
Common Triggers and Root Causes of Security Cleanup Efforts
Let's start with an easy one. What usually triggers a JDE security cleanup project?
Projects like this are usually driven by something that IT has noticed or found in the system. They start pulling on the thread and investigate and determine that there's a lot of work that's needed. So they scope out a project for the work that they found and could like a can admin easily remove access to quickly fix some of these issues?
Absolutely. Admin has access to do whatever they need to in the system. The bigger question is what's the impact of removing that access? Does it break a process or prevent an order from shipping? So it's it's it's easy to do, but understanding the impact to the business is not always easy and there is always a lot of questions when it comes to how does this actually impact my business.
Let's look specifically at like roll sprawl. What is roll sprawl and how does it happen in ajd Edwards environment?
Roll sprawl is when users have roles that are not part of their current job description or job duties. And it's very typical in most JDE instances.
What happens is access is granted to users based on copying the access from somebody else. So you have a a new joiner and you get a ticket that says copy access like Joe. So you get everything that Joe had access to.
When a user moves jobs, new roles are added and the old roles usually don't ever get removed. The person who moved is usually going to backfill and provide support for a period of time. But they never go back and say hey, I'm all done, you can take my old access away.
It just it stays there and they aggregate access over years and then they get copied to the next person.
It's that revolving door of one person leaves, but they don't have their access revoked.
And you're right, it could turn into eight people with the same access because they've had people move up in the company and they keep moving and moving and they just never revoke any of the access, which can get a little bit. It can be an issue. Let's just put it that way.
It's a pretty common issue.
That is true.
For the remaining sections, I'll keep this clean article-style format with no quotation marks, no timestamps, and the exact original wording preserved.
Role Sprawl, Access Growth, and User Resistance
So maybe some of these people, but maybe other people in the company, do they, do you see a lot of people resisting like a security cleanup?
There can be resistance.
Usually the resistance will come from the business side, and it usually is there because they've gotten burned before. Restoring access becomes complicated and tedious. In the meantime, they're unable to do some of their job. They have the pressure to get things done, but they can't because access has been removed.
So if the business doesn't have any input into the project, they don't trust that it's going to be done right.
Interesting. So there's a little bit of a trust barrier there. Or is it just because there's a lack of understanding?
I, I think it's a little bit of both. If they're not involved, they aren't sure what's being done, why it's being done. They feel like IT is focused on putting handcuffs on them, making their jobs more difficult when really it is something that's being done to remediate risk for the business.
But the stated goal should be to make sure the end users can do what they need to for their jobs. And often time that's not communicated.
Yeah. So maybe there is that resistance.
Right. And in the middle of a actual cleanup, the job is left unfinished. What's the real cost of leaving one of these cleanups unfinished?
Well, the original problem still exists, just in a partially resolved state. So you have some areas that have been may be fully cleaned up, maybe only partially cleaned up.
And when you leave something like this in an unfinished state, user trust is even further eroded because you've started down the road, you've asked him it for input and then you stop and nothing gets done with that input.
And that makes it harder to get buy in for any future initiatives.
And that kind of ties back to the previous answer of they've gotten burned before and there's a lack of trust that it's going to be done completely and correctly.
That's that's a great foundation because it really explains why these projects can feel overwhelmed from nearly the start.
It's not just a list of users and roles, it's business process, it's risk, compliance, and operations all tied together.
Why Cleanup Projects Lose Momentum
So now that we really understand what why JD Edwards Security Cleanup gets complicated, let's look at why these projects lose momentum once they're already over or under way.
So what are the biggest hidden blockers that cause JD Security Cleanup projects to lose momentum?
I think many of these projects are driven from an IT focus and are not clearly defined. The project, especially a security cleanup project is going to touch multiple areas of the business, all the functional areas. And those areas were not consulted in the project planning and implementation stage.
And there's usually not a plan for validating and testing changes to ensure there's no business disruption.
So really the, I think a couple of the biggest blockers are IT driven and not involving the business or compliance in the planning aspect of the project.
So would you say that those are the most often issues that arise that actually stall these clean up projects or are there more?
I think those are the the biggest issues. So not involving the business not being clearly defined and not having a a definitive outcome that is expected or deliverables that are expected coming out of the project.
It's driven by IT who noticed an issue, it says we need to fix this. And so they focus just on that area and don't involve everybody that needs to be or clearly think through and define what the expectations are for the work.
So maybe I think we'd combat this who should maybe own the JDE security cleanup project so that we don't see these issues arise.
I'm not going to make a lot of friends with my CNC technical people with this answer. However, I strongly believe that JDE security and any security related projects should be owned by the business.
They know what access is needed to get the work done. IT's job is to implement and provide the guardrails to make sure access is limited and appropriate along with internal audits, guidance related to compliance.
Yeah. So it's two teams working together to make sure that on one side that the project gets done, then on the other side make sure that it's getting done the right way.
By right, 100% yes.
See that's that will bring the trust with it. It'll allow some of these clean up processes and like it will allow everyone a part of it to understand what's going on and exactly what the benefits will be and how to get there and that at the end of the day, that's the best type of project it absolutely it's as clean cut as you can get.
So why do you why maybe do teams underestimate the business process knowledge required for something like this?
Well, typically projects are driven by IT and IT does not usually understand the intricacies of what the business needs to do or who needs access to specific functions.
Built in JDE control such as batch approvals or AP payee control and bank account masking are often not considered. And so they start trying to restrict access when there's other controls that already provide mitigation to some of the things that they're concerned about.
Ownership, Business Involvement, and Governance
OK, so maybe let's switch gears a little bit. How does a lack of data make cleanup projects stall?
Well, if you don't have the data necessary to make the appropriate decisions, decisions don't get made.
If you haven't involved the business resources from the start, at the point you need a decision now you're left trying to figure out who to involve while the project is just sitting there and then gathering the data that that person's going to ask for to be able to make that decision.
So you need to have that upfront and, and it's, as you've noticed, it's a recurring thing. You need to have the right business resources involved.
And maybe like when you're testing, do you see the lack of data kind of creating a bottleneck or are there maybe some other things that can come into it?
Testing typically as one of the pain points in any security project, what it comes down to is users aren't sure what to test and how to test.
Test scripts, if they exist, are frequently well out of date.
And then getting time away from the primary job responsibilities and functions, especially when the request comes in with a little notice, becomes a major concern.
And so a little bit earlier in this episode, we talked about the two teams working together. What happens when clean up is not followed by like a better governance between these two teams?
Well, you end up right back where you started.
It might take six months, it might take 18 months. But if you don't have the governance in place to control access going forward, you will end up back there.
So you need to have a solid plan with enforced policies to back it up to make sure that you don't revert back to the previous state.
And that's helpful because it gives our listeners a way to recognize the real blockers.
A stalled clean up project may look like a technical issue on the surface, but underneath it's usually an ownership prioritization or even a process issue.
Restarting a Stalled Security Cleanup Project
So let's say a team is listening right now and they're thinking, that's exactly where we are. We started this project, it got messy and now we're stuck. How would you say they should think about restarting?
I would go back to review and understand the original requirements. What did you set out to accomplish?
Once you have that information, again, good data involve the business and internal audit. Make sure all the parties have a say and understand what the business justification is.
You need to have a well defined scope. If it has been a long time since the original effort was started or it's been stalled for a long time, a new analysis will be needed to get the scope right.
And then you need to prioritize based on risk and business needs and availability.
So that was a lot of stuff. What would you say they should focus on for the 1st 30 days of one of these projects?
You need a project sponsor and named users that are able to make decisions on behalf of the business users.
A clear understanding of the project deliverables and the responsibilities of all the project members.
Defining timelines that are reasonable and take into account business cycles such as month end, close or seasonal business.
Often times I see projects that require or ask financial users to do heavy testing when they're supposed to be doing month end close, and that's never going to happen.
So you need to account for all of that in the planning stage.
Yeah, but we talk about that all the time. The planning stage is one of the most important stages of any project.
To have something clearly defined, understand the exact timeline, and also understanding that some things can go away. Not everything will be perfect in some of these cases, but if you do what you said earlier of having these two teams work together as much as they possibly can, you'll get to the other side.
Yes, it might take a little bit longer. Yes, it might be a little messy, but you'll get there and you'll know that your entire security side of JD Edwards is ready for the next step.
Absolutely.
So what should maybe these teams prioritize in terms of like what should they clean up first?
Excellent question. Because if you don't prioritize, you'll be all over the map.
I would focus on the highest business risk. To do this, you have to be able to quantify what those risks are based on what the project objectives are.
In some cases you also may be able be able to identify some quick win actions that demonstrate progress for all members of the project team and leadership and have minimal business impact.
So that low hanging fruit often times can provide a little bit of of motivation and incentive to show that yes, things are working and and we're improving things.
Yeah. And I mean, we've seen that through every project that we've ever done security wise and otherwise, start with a quick wins, start with something small because if you can show real value in that first thing you do or second thing you do, then the rest of the project will feel seamless because everyone will be bought in and it'll make it that much faster to complete some of these projects.
Absolutely.
Reducing Risk Without Disrupting Operations
So what is maybe the right way to involve business process owners to one of these cleanups?
Involve them from the very beginning, get their buy in for the goals of the project and get their assistance in reviewing and adjusting the goals and project outcome. They're the ones that have to live with what is put in place and still run the business. When users feel that they're being heard, they're much more likely to take ownership.
Something that I work on is using business terms. We need to meet the users where they are and let's not not try to dazzle with a bunch of technical terms that they don't understand. Use terminology that they understand, and you're going to get a whole lot better involvement from the business.
Yeah, Maybe Speaking of involvement, how can these teams reduce risk without disrupting their day-to-day operations?
That's usually one of the first questions that somebody who's sponsoring the project is going to ask. The best way that I have found is to implement a split table configuration for security and role relationships.
This allows you to complete segregation from your live system to be able to make changes, test and validate with 0 impact to the live system. Meaning you don't have to worry about if I take that access away from the the accounts payable team that is going to keep them from being able to pay your vendors. You've got split tables, split role relationships and there's zero risk to your day-to-day operations.
Yeah, and that makes a lot of sense. But maybe what role should change control play in all of that?
Change control is paramount. Everyone needs to understand the scope of the change, what is happening, who's affected. And not just that, but a rollback plan.
Things are going to happen. Somebody's going to say, yes, I'm good with this change. And then when it goes live, all of a sudden they forgot to consider something. And so you need to have a plan to be able to roll back that change so the business can continue to do business to function on that day-to-day basis.
And that's a really practical way to think about it. The goal is not to oil the ocean, so to speak, and fix everything overnight, right?
It's to restart with focus, prioritize the biggest risk and make progress without creating disruption. But once that cleanup work is done, the next challenge is keeping it from sliding backwards.
So let's talk about what happens after the project.
Sustaining Security Improvements and Measuring Success
How do JD Edwards teams prevent security cleanup from becoming a one time project that slowly falls apart again?
So as part of the project. So again, part of the planning is define new policies and procedures for managing security based on your stated outcomes from the project.
These should be implemented at the start of the project. This will help keep any new issues from appearing while you're cleaning up the old issues.
The team, especially IT, needs to be open to reviewing and adjusting the policy and procedures during this time to fine tune for what works and what doesn't. IT, Business audit are all going to find things that sounded great during the planning stage, but in practice maybe they need to tweak a little bit.
So be open to adjusting things as you discover them during the project.
Also have a plan to review the policies annually to make sure they're being followed and are still applicable.
So if we're talking about those changes, what would maybe like what should a sustainable GD security operating model include?
They should be well defined roles that the business understands. The roles are defined named in business language so that they understand if you have some random role names with access across a whole bunch of different areas, the business never really looks at that. They just check the box.
So roles that the business understands that they help define documented policies and procedures that cover both the 80% of the regular changes and what people tend to forget is the 20% or the one off changes or exceptions that also needs to be documented and thought of so that you have a policy and you don't just handle those exceptions or those firefighting scenarios however you see fit.
There needs to be rhyme and reason to everything you do, whether it's daily or firefighting.
And an annual review processed as you mentioned before to process the to validate the security setup has not regressed.
So in that annual review, would that be the time that companies are also reviewing like JD access or is that just for security as a whole?
It would include the JD access, so I would include in that.
User access reviews are typically done annually due to the effort involved. If you have roles and access the business truly understands, you should be able to do this biannually, which means you're reducing your risk because you're checking twice a year to make sure that you have the right access in place for your users.
Access for privileged users should be reviewed quarterly, so CNCS security people should be looked at quarterly.
Compliance issues, including for privileged users, should have a continual review process as issues here can result in fraud. So that needs to be a continuous review process.
And so here to your fee suites. We've been talking a lot about modernization. How does modernization make security cleanup even more important than maybe it is right now?
New tools and capabilities equal new ways of accessing and manipulating data in the system, whether it's the chat bots, AI agents, orchestrations, whatever it can be.
If you don't have a well defined security model with the accompanying policies, there's a real risk that new tools having elevated access and being outside the standard controls for review and compliance.
Thankfully, what I've seen, especially within the ERP sweeps, is security is part of the discussion from the very beginning. So it's not something that's bolted on at the end. It's considered from day one for everything we're doing, for all of our AI work.
So maybe we're looking towards the end of one of these projects, What metrics should companies be looking at to see if the cleanup is actually working?
When the project is completed, you should perform the same analysis as you did at the start of the project. Compare the results you're looking at, you know, apples to apples.
Analyze that you should see significant improvement across all areas that you were measuring. So this provides the data to demonstrate the progress.
Also, the usual bottlenecks and concerns have been eliminated. Reviews are completed on time and hopefully more frequently.
So when should a company look to bring in outside help for one of these security cleanups?
Wives typically engage with a consultant when internal resources are too busy with daily maintenance or other projects.
It's not usually that the internal Reese's don't have the ability to do the work, it's they don't have the time to do the work.
Having an outside consultant also brings a fresh perspective with a proven record of completing projects like the current one, which can help with perhaps projects that were previously solved and some of those business trust issues.
And there's a lot to unpack when you're looking to bring in outside help. But the main thing that you should understand is if it is going to make your business unstable with a lack of better terms, if it's not going to allow you to continue operations on a day-to-day basis because of everything that is going on, then yes, outside help makes sense.
Now if it's a slower time, yes, you can definitely do that in house as well. But it's about giving the right resources to where you truly need them and not stretching your people too thin.
I agree.
But if your JD security cleanup project has stalled, or if your team knows access has grown too complex over time, ARP Suites can help.
Our team works with JD customers to assess current access, identify risk, build a practical cleanup road map, and create an ongoing security process that protects the business without slowing it down.
Visit erpsuites.com today to connect with Brian Connor or one of our many other team members for JDE Security.
But that's our wrap on today's episode of Not Your Grandpa's JD Edwards.
The big take away is this JD Edwards security cleanup projects usually stall because they are treated like technical cleanup when they are really business risk.
Projects with right ownership, prioritization, testing, and governance teams can reduce risk without creating disruption.
Again, huge shout out to you, Brian, for joining us again today and sharing practical insights on how JD Edwards teams can get security cleanup projects moving.
If this episode was helpful, subscribe, leave a like and share it with someone on your IT finance, audit or even your operations team.
But until next time, keep modernizing, keep asking better questions, and remember, this is not your grandpa's JD efforts.
Video Strategist at ERP Suites
Topics:
-1.png?width=650&height=325&name=Blog%20Images%202_1%20(1)-1.png)
.png?width=960&height=540&name=Blog%20Images%20(72).png)
.png?width=960&height=540&name=Blog%20Images%20(62).png)
.png?width=960&height=540&name=Blog%20Images%20(49).png)
.png?width=960&height=540&name=Blog%20Images%20(9).png)
