In my work with higher education institutions and state/local agencies, one debate comes up more often than any other when it comes to building a security program that actually works:
Should we centralize security or allow departments and agencies to operate independently?
It’s rarely a black-and-white decision. But I’ve found that how an organization answers this question says a lot about how they manage risk, how they think about compliance, and whether they’re planning for today’s threats or yesterday’s structure.
What fragmentation feels like in practice
I’ve sat across the table from IT leaders who inherited decades of decentralized decision-making. One university we worked with had six separate identity providers across their campus’—none of which had consistent multi-factor authentication (MFA). Each group had autonomy, which seemed great until they needed to enforce a unified access policy. It's also common for there to be issues when there is a need to respond to an incident or prepare for an audit.
It’s a pattern I see often. Universities and state & local agencies weren’t built like Fortune 500 companies—they’re federated by design, operating more like coalitions than corporations. That gives them flexibility but also makes enterprise-wide visibility and control a major challenge.
When an environment is fragmented, governance often becomes reactive. Teams don’t know what assets exist outside their walls, have inconsistent logging across systems, and asset ownership is unknown. These inconsistencies can have a significant impact during a breach or cyber incident.
Centralized security isn’t just about control—it’s about consistency
In environments that choose to centralize their security operations, we usually see a few benefits show up quickly:
- Standardization of controls: This is huge. Whether you’re trying to apply GLBA requirements in a university setting or align to NIST standards in a state agency, having a central team to define and enforce controls creates efficiency and consistency.
- Faster incident response: With a single SOC or incident response playbook, you inherit greater efficiencies and don’t have to worry about silos and isolated infrastructure.
- Better audit posture: When you need to report to a federal agency, state auditor, or oversight board, having enterprise-wide control standards simplifies the process.
But I don’t want to pretend centralization solves everything. You can’t force control top-down and expect buy-in. If the culture isn’t ready or if it’s purely an IT-driven initiative, centralization can just shift friction elsewhere.
Decentralized models work—In the right situation
I’ve also seen decentralized models succeed when there’s strong communication and shared accountability. Some research departments move faster and innovate more because they aren’t constrained by centralized procurement or tooling. Local government agencies, too, often need flexibility to serve their unique communities.
But when things go wrong, that flexibility becomes fragmentation:
- Departments using separate security stacks with no integration
- Overlapping contracts with redundant tools
- Different interpretations of what’s “compliant” under the same regulation
- Delayed incident responses because no one knows their responsibilities
- And there is always the added cost of having multiple instances of the same application
Most importantly, these environments tend to underestimate third-party risk. When we run assessments, we often find vendors with privileged access who were onboarded without consistent background checks, contract language, or monitoring in place.
Compliance is a signal—Not the destination
A lot of organizations start this conversation because they’re seeking alignment and compliance. GLBA. CJIS. NIST 800-171. HIPAA. But the compliance mandate is often just the symptom of a deeper problem: lack of internal control.
For example, the new GLBA Safeguards Rule update requires continuous monitoring, documented incident response plans, and an appointed security lead. That’s not something you can fake with a policy PDF or a once-a-year tabletop. It takes structure.
And that’s where your operating model—centralized, decentralized, or hybrid—starts to either support or sabotage your compliance efforts.
What’s actually working: Hybrid, with guardrails
At NuHarbor, we’re seeing more institutions move toward governed hybrid models—and I think this is where the future is heading.
That means:
- Centralizing core back-office functions like threat detection, identity governance, and compliance reporting
- Allowing local execution of certain services and tooling, especially where autonomy is critical
- Providing shared services from a centralized team (like a security center of excellence), rather than forcing every department to build from scratch
One state university we work with adopted a federated GRC model: the security team provides a policy and control framework, and individual colleges map their systems to it with advisory support. It’s not perfect, but it’s far more sustainable than either extreme.
What I recommend as a starting point
If you’re unsure what model fits your organization, here’s where I suggest starting—not with a technical decision, but a leadership one:
- Assess governance readiness: Do you have the authority and relationships to centralize, or will that create resistance?
- Prioritize visibility: Regardless of your model, you need asset inventory, access control, and logging you can trust.
- Treat compliance as a byproduct: Aim for operational maturity, and compliance will follow—not the other way around.
- Define the "must-centralize" functions: Identity. Logging. Incident response. Those can’t be optional.
- Bring others into the process: Structure should never be imposed—it should be co-developed with the business and IT stakeholders who live in it.
- Ready to forgo ownership: The owners of each system must be prepared to give up some administrative power and trust the same level of standards will prevail.
Final thought
There’s no ideal model. But there is a right model for your maturity, risk tolerance, and culture.
What I’ve learned is this: Structure isn’t something you set and forget—it’s something you evolve as your organization grows. And it’s okay to be pragmatic. If you’re decentralized today, centralize where it counts. If you’re centralized but losing agility, push decision-making closer to the edge—just don’t lose visibility.
If you want to have this conversation in more detail, we’re always happy to dig in with you and your team. Let’s talk.
Don't miss another article. Subscribe to our blog now.
