When we start working with a new client, one of the first things we do is look at how their technology is set up. Almost every time, we find settings and configurations that nobody at the organization can explain. Some were put in place years ago by someone who has since left. Others came from a previous IT provider, or were added as a quick fix that was only supposed to be temporary.
This is very common.
Most organizations didn't build their technology environment from scratch; they inherited it from the people and providers who came before them. Everything keeps working day to day, but over time it becomes harder to answer basic questions, such as who can access your systems from where, and why.
How Things Get This Way
These environments usually become complex gradually. Every setting in your environment was probably added for a good reason at the time. An executive needed access to email while traveling, so an exception was made. After a security scare, a new rule went in. A new IT provider came on board and configured things the way they prefer, right on top of what the previous provider had done.
The problem is that nobody goes back to revisit those decisions. The people who made them move on, the documentation (if there was any) doesn't explain the reasoning, and the exception that was supposed to last a week is still there three years later.
Your IT staff or MSP is busy keeping things running and closing tickets, which is exactly what they should be doing. What's missing is someone whose job is to step back and ask whether the whole thing still makes sense for the organization.
Figure Out What You Have First
When we step into an environment like this, our first priority is to understand it: what's there, what it's supposed to be doing, and what it's actually doing. From there, we translate our findings into something leadership can act on.
A recent project is a good example. During a regular Microsoft 365 review for one of our clients, which coincided with a change in IT providers, we took a close look at their Conditional Access policies. Conditional Access policies are the rules in Microsoft 365 that control who can sign in, from where, on which devices, and how they have to verify their identity. In effect, they're the front door to your email, files, and everything else.
On paper, the client looked well protected. Once we dug in, however, we found that several policies weren't doing what their names suggested. Among the issues:
- Two policies looked like protections, but so many people had been excluded from them over the years that they were protecting almost no one.
- Exceptions had been handed out one person at a time, with no central list of who was exempt from what (or why).
- Some rules still referred to the client's previous IT provider, along with test groups nobody was using anymore.
- Older sign-in methods that get around modern protections were still allowed, and accounts with broad administrative access, the ones with access to everything, didn't have any extra safeguards.
- The policy names didn't tell you what the policies did. Reviewing them took some detective work, and handing them off to someone new would have been very difficult.
Each of these made sense to someone at some point. Taken together, they show what happens when no one is looking at the whole picture.
Fix It or Start Over?
Once you understand what you have, you face a choice: clean up what's there or start fresh. In many organizations, the decision can fall to the IT staff or MSP. We believe the decision belongs with leadership, even when leadership chooses to rely on an outside expert's recommendation. The choice has organizational consequences, so leadership should understand the tradeoffs: cost, disruption, risk, and how easy each option will be to maintain. Technical teams or outside experts can make recommendations, but leadership should be part of the decision.
This client asked us to make the call, and starting over was the clear choice. Patching the old policies would have meant keeping exceptions nobody could justify and working around names that obscured what the policies actually did.
Decide What "Right" Looks Like
Before anyone built a single new policy, we documented what the policies needed to accomplish. After a few brief conversations, the client asked us to recommend a direction. We worked out who needed access to what, from which devices and locations, and what level of verification made sense for different types of accounts. We also went through every existing exception. If one stayed, there had to be a clear reason for it.
The result was written up as a set of requirements that we sent to the team doing the build and reviewed with them before any work started. The technical work follows from those requirements, and because everything is documented, the client has a clear record of what their policies are supposed to do and why, without having to get into the weeds themselves.
In our view, this is the most important part of the entire process.
Everyone Has a Role
With the requirements complete, the build began. This arrangement worked well because everyone involved had a clear role. The technical team handled the configuration, while we provided direction, reviewed the work against the requirements, and kept leadership informed. That left the client free to focus on running the organization.
We also took a measured approach to the rollout. For an initial period, the new policies ran in a monitoring mode that recorded what they would have done without actually blocking anyone. This let us see exactly who would be affected, address problems before they disrupted anyone's work, and give staff advance notice of any changes. Once we were satisfied with the results, the policies were switched on.
What You Get Out of It
The immediate result of a project like this is a cleaner, more secure environment. The bigger benefit, in our view, is clarity. Leadership knows what the policies do and why, exceptions are documented and intentional, and whoever manages the environment next won't have to play detective.
This approach applies well beyond sign-in policies.
SharePoint and file permissions, device settings, firewall rules, and even vendor relationships all accumulate the same way over time. The same process works for each of them: figure out what you have, decide whether to fix it or start over, define what you want, and then make the changes carefully.
If you're wondering whether your organization could benefit from this kind of attention, consider a few questions:
- Can anyone explain, in plain English, what each of our security policies is supposed to do?
- Do we know who is exempt from our security controls, and why?
- When was the last time anyone looked at settings left behind by a previous provider or employee?
- Who is responsible for the overall direction of our technology, as opposed to just keeping it running?
If a few of these questions gave you pause, it may be worth taking a closer look at how your current technology settings were chosen, who owns them, and whether they still fit. Inherited decisions are common. Understanding them is the first step toward deciding what to keep, change, or replace.
