A couple of years ago, a piece in the Wall Street Journal declared “It’s Time to Get Rid of the IT Department”. The author argued the classic IT department was a relic, a holdover from a slower era. It was a good provocation. It was also wrong in an interesting way.
Structurally, IT hasn’t changed much. The boxes on the org chart still say CIO, infrastructure, security, support. What changed is everything inside those boxes. The job used to be keeping the servers in the back room alive. Now the same team is responsible for laptops in living rooms, phones in airports, and SaaS accounts nobody told them about.
That gap is what this guide is about. Most IT org charts describe a building that’s half-empty. They tell you who reports to whom, but not whether the structure can actually see and control the endpoints it no longer physically touches. A reporting line is easy to draw. Coverage of a distributed fleet is the hard part, and it’s the part that gets tested during an audit or an incident.
So here’s what we’ll cover: what an IT department does today, what the org chart looks like at different company sizes, the four structures teams use, how to pick one for your size, the roles you need, and the one responsibility that’s easy to leave unowned. Whether you’re a one-person IT team trying to justify a second hire or a director defending a restructure to finance, the goal is the same: a structure that matches reality, not just headcount. Let’s get into it.
What is an IT department?
An IT department is the team responsible for running, securing, and supporting all of a company’s technology: networks, hardware, software, data, and the people who use it. At its simplest, it makes sure systems work, stay secure, and don’t quietly fall apart.
That’s the textbook version. The operational version is broader. The role of IT isn’t just about fixing what’s broken; it’s about building and maintaining the infrastructure that keeps a company’s information flowing. From managing networks and databases to enforcing encryption and patching, the department touches almost every workflow in the business.
In short, IT departments are business enablers. They make sure employees have the tools and support they need to work productively, while protecting the organization from a growing set of digital threats. When IT works, nobody notices. When it doesn’t, everybody does.
Quick win: Write a one-sentence mission for your IT function and pin it where the team can see it. If it reads “we fix things,” you’re describing a help desk. If it reads “we run and protect the systems the business depends on,” you’re describing a department. The framing changes what you budget for.
Why do we need an IT department?
For a long time, “IT” meant the person you called when the printer died. That role still exists, but it’s a sliver of the job now. Far from just fixing broken computers or troubleshooting network issues, IT teams are now deeply involved in ensuring the flow of information, safeguarding data, and maintaining the systems that keep the business efficient. Typically working under the Operations umbrella, they manage everything from information security and infrastructure to programming and technical support.
Here’s where the real shift shows up. The reason a company needs a deliberate IT structure today isn’t complexity for its own sake; it’s that the perimeter dissolved. Ten years ago, “the network” was the office, and security was largely a matter of guarding the door. Now your assets are scattered across home Wi-Fi, coffee shops, and personal phones. IT owns devices it can’t physically see, on networks it doesn’t control, holding data that’s still the company’s legal responsibility.
That’s exactly why endpoint management stopped being a sub-task and became a core function. A company needs an IT department because someone has to be accountable for that distributed surface: knowing what devices exist, whether they’re encrypted, when they last checked in, and how fast you can lock or wipe one that goes missing. No structure means no accountability, and no accountability is where breaches and failed audits live.
Quick win: Ask one question in your next team sync: if a laptop goes missing this afternoon, how long until we know, and how long until we can wipe it? If the answer is “it depends,” you’ve found the gap your org chart is supposed to close.
IT department org chart: what it looks like by company size
There’s no single IT org chart, and copying a Fortune 500 diagram into a 40-person company is a common, expensive mistake. The shape that works depends almost entirely on size. Here’s how the progression typically looks.
- Under 25 people: one IT generalist, often backed by an MSP. A single person handles support, devices, accounts, and basic security; specialized or after-hours work is outsourced.
- 25 to 250 people: an IT Manager leading two to five specialists. Roles split into support (help desk), infrastructure and networks, and a security owner. Endpoint and device management becomes a named responsibility, not a side duty.
- 250+ people: a CIO or IT Director setting strategy, with separate leads for infrastructure, security (often a CISO), operations and sysadmin, support tiers (L1 to L3), and data administration.
The pattern is consistent: responsibilities don’t appear when you grow, they separate. The one-person team already does security, support, and device management; growth just means handing each to a dedicated owner. The trap is letting a responsibility stay implicit. “Everyone watches the devices” reliably means nobody does.
Take a real progression. Jerome is the sole IT person at a 60-person company. He’s buried in tickets and wants to hire, but the CFO wants the plan first. The honest first-three-hires order, for most companies that size, is: a help desk or support hire first (it frees the most of Jerome’s hours), then a security and systems owner who also takes endpoint management, then an infrastructure or network specialist as the environment grows. Notice device management lands on hire two, not hire five. It’s a coverage gap that compounds the longer it stays unowned.
Quick win: Draw your real org chart, then mark every box that’s actually one person wearing three hats. Those overlaps are where your structure looks bigger than it is. They’re also the most useful slide you’ll ever show a CFO.
Common IT department structures
Each IT department structure is built differently to suit the needs of the organization. Whether the company prioritizes specialization, flexibility, or cost-effectiveness, the right structure helps manage responsibilities and maintain business continuity. Let’s explore how these structures are organized and what roles typically fit within them.
1. Functional Structure: Clear Specialization with a Defined Hierarchy
The functional structure is based on specialization, grouping team members according to their expertise and responsibilities. Each function within IT (e.g., network management, cybersecurity, technical support) operates in its own team, led by a manager or senior IT administrator. This structure is hierarchical and centralized, ensuring that every role has a clear place within the organizational chart. Best for mid-to-large organizations with stable, well-defined needs that benefit from deep specialization.
Organizational Chart:
- Top Level: Chief Information Officer (CIO) or IT Director oversees the entire department.
- Second Level: Department heads or IT managers who are responsible for specific functions (e.g., Network Manager, Security Manager, Help Desk Manager).
- Third Level: IT specialists or technicians within each function (e.g., network engineers, security analysts, help desk technicians).
Roles and Elements:
- CIO or IT Director: Sets the overall IT strategy and ensures that each functional team aligns with business goals.
- IT Managers: Lead specific functions, coordinating teams and resources.
- Specialized Teams: Dedicated groups focusing on network management, security, software development, infrastructure, or user support.
How It’s Built:
- Team Segmentation: Each area of expertise (networks, security, etc.) operates separately under a manager, reporting to the CIO.
- Top-Down Communication: Decision-making flows from the top, with each function receiving direction from IT leadership.
Example: In a functional structure, the network management team might include a Network Manager, network administrators, and technicians responsible for maintaining connectivity and server integrity.
2. Independent Service Line Structure: Autonomy and Flexibility Across Teams
In the independent service line structure, each IT service line functions almost like an independent department, with its own governance and leadership. This structure is more decentralized, allowing different teams to operate autonomously based on their specific responsibilities. Best for organizations where different business units need IT to move at different speeds.
Organizational Chart:
- Top Level: CIO or IT Director overseeing the broader IT strategy.
- Second Level: Independent service line leaders, such as a Cybersecurity Lead, Infrastructure Lead, and Software Development Lead, who each manage their respective teams.
- Third Level: Service-specific teams, with specialized roles in each independent line (e.g., cybersecurity analysts in the Cybersecurity service line, cloud architects in the Infrastructure service line).
Roles and Elements:
- Service Line Leaders: Heads of each IT service line who have full decision-making power within their team.
- Autonomous Teams: Each service line operates independently, managing resources, decisions, and projects without needing constant approval from higher management.
- Decentralized Management: Unlike the functional structure, service lines make their own decisions, promoting faster problem-solving and more flexibility.
How It’s Built:
- Independent Governance: Each service line has control over its operations and budgets, while still aligning with the overall IT strategy.
- Cross-Departmental Collaboration: Teams collaborate directly with other business units to support specific functions, making this structure more responsive to business needs.
Example: A company using an independent service line structure might have a Cybersecurity service line that works directly with the legal department to ensure compliance, while the Infrastructure service line works independently with vendors to maintain cloud systems.
3. Leveraged Structure: Combining Internal Teams with External Expertise
The leveraged structure blends internal IT teams with external service providers to fill gaps in expertise or resources. Internal teams manage core IT functions, while external providers (such as managed service providers or MSPs) take on specialized tasks, such as cybersecurity monitoring or cloud infrastructure management. Best for growing companies that need specialized capacity without hiring full-time for it. When an outside provider runs part of your fleet, make sure one accurate device inventory still spans both sides; choosing between an MSP and an MSSP changes who owns what, but not your need to see all of it.
Organizational Chart:
- Top Level: CIO or IT Director who oversees both internal IT operations and manages the relationships with external providers.
- Second Level: Internal IT managers leading core functions (e.g., Network Manager, Help Desk Manager), alongside service-level managers responsible for managing external providers.
- External Providers: Managed service providers responsible for specific outsourced tasks, such as cybersecurity, cloud services, or advanced technical support.
Roles and Elements:
- Internal IT Managers: Lead in-house teams responsible for essential day-to-day functions.
- Service-Level Managers: Oversee the performance of external providers, ensuring SLAs are met.
- External Specialists: Experts from third-party providers who handle complex or resource-intensive tasks.
How It’s Built:
- Core Internal Teams: Internal IT staff focus on business-critical tasks, like supporting users or maintaining internal networks.
- Outsourced Expertise: External providers take on specialized roles such as cloud management, 24/7 security monitoring, or disaster recovery, ensuring the company doesn’t need to hire full-time staff for these functions.
Example: A mid-sized company might use a leveraged structure by maintaining an internal help desk team while outsourcing cybersecurity to an MSP that offers constant monitoring and threat protection.
4. Hybrid Structure: Full Integration of External and Internal Teams
The hybrid structure goes beyond the leveraged model by fully integrating external providers into the organization’s IT operations. External vendors manage entire IT service lines as if they were part of the internal team, working collaboratively to meet business goals. Best for organizations that rely heavily on external expertise but need it operating as one team, not a vendor at arm’s length.
Organizational Chart:
- Top Level: CIO or IT Director who integrates external teams into the company’s strategic IT planning.
- Second Level: A mix of internal IT managers and external service line leaders, depending on the structure of the hybrid model.
- Third Level: Both internal IT staff and external specialists work together under the same service lines (e.g., cloud service specialists from an external provider collaborating with internal infrastructure engineers).
Roles and Elements:
- Integrated Teams: External providers are no longer just third-party vendors; they are an integral part of the company’s IT operations, often working on-site or fully integrated into the company’s processes.
- Internal Managers: Oversee collaboration between external and internal teams, ensuring seamless cooperation and that all IT services align with business objectives.
- External Service Leaders: Lead outsourced IT lines (e.g., cloud infrastructure or security) while working in tandem with the in-house IT leadership.
How It’s Built:
- Collaboration at Every Level: External providers become a core part of the organization, attending meetings, following company protocols, and aligning with the business’s IT strategy.
- Ownership of IT Lines: External providers take full ownership of certain service lines, while internal teams manage other areas. This integration ensures expertise in critical areas without overburdening internal resources.
Example: A financial services company might use a hybrid structure, keeping an in-house team for day-to-day IT operations while outsourcing all cloud services and cybersecurity to external providers, who are embedded within the company’s processes.
Two more worth naming briefly: matrix structures, where people report to both a function lead and a project lead (common in larger orgs running lots of cross-functional work), and flat structures, with minimal hierarchy (common in startups where everyone does a bit of everything). Most real departments are some blend of these models, not a textbook example of one.
Quick win: Name your structure out loud in one sentence (“we’re functional internally with a leveraged after-hours desk”). If you can’t, your model is probably accidental, and accidental structures are where shadow IT and unowned devices accumulate.
How to choose the right structure for your size
Picking a structure isn’t about which diagram looks cleanest. It’s about matching the model to four real constraints. Run your situation through these before you redraw anything.
- Headcount and growth rate. Under 25 people, don’t over-engineer; a generalist plus an MSP beats a five-box chart you can’t staff. Scaling fast? Build for where you’ll be in 18 months, not today.
- OS and device mix. A Windows-only office is simpler to structure than a Windows, macOS, and mobile fleet with BYOD. The more mixed your endpoints, the more you need a named device owner regardless of size.
- How remote your people are. A fully in-office team can lean on physical controls. A distributed or hybrid workforce pushes device management and security higher up the priority list, because the perimeter you’re protecting is now wherever someone opens a laptop.
- Compliance load. HIPAA, FERPA, GDPR, ISO 27001, or Chile’s Ley 21.719 each demand evidence: who has access, which devices are encrypted, how incidents are handled. The heavier the load, the more governance needs to be its own function, not a side duty.
Here’s where the choice gets tested. Jim, an IT Director, has to defend a restructure to finance. The CFO’s question is fair: why add headcount? The answer that lands isn’t “we’re busy.” It’s mapping the structure to risk coverage. Jim shows that the current chart claims to “cover security,” but no named role owns endpoint visibility, which means that during an audit, nobody can produce an encryption-status report or a device inventory on demand. The restructure isn’t about more people; it’s about closing a coverage gap that’s already a compliance liability. That framing turns an org chart into a risk conversation, which is the one finance actually responds to.
If you’re feeling the strain of an outgrown model, the symptoms are concrete: tickets routed by tribal knowledge, no clear owner for new device setup, and security work that only happens when something breaks. Those are the same signs you’ve outgrown basic device management, and they usually show up before the headcount problem does.
Quick win: Score yourself on the four questions above, then look at your current structure. If your remote percentage and OS mix are high but no single role owns devices, that’s your next hire or your next contract clause, whichever comes first.
The IT department’s responsibilities
As we discussed earlier, the IT department handles way more than your malware-infested computer. Besides maintaining standards in critical areas and assuring business continuity, IT staff is the engine & transmission driving the efficiency of any organization that requires technology (nowadays, most of them). This includes managing hardware and software systems, investigating and resolving technical issues, and providing technical support to users.
The IT department’s responsibilities can be summarized in three broad groups, plus a fourth that most org charts quietly drop.
Architecture
No computing device in an organization exists on its own. Networks, endpoints, and servers: all of them subsist on a complex mesh of layers, hardware, and protocols. That mesh is usually a blueprint (or a set of blueprints) that IT architecture is tasked to design.
Usually, a “strong” architecture is defined as a cohesive structure governing all areas of tech, from planning to acquiring, and finally to building and implementing systems.
IT professionals responsible for architecture exist all across the spectrum. Domain architects, for example, are experts in designing infrastructure, applications, and information exchange; while security architects develop protective barriers (physical or otherwise) so the entire organization can be shielded from malicious actors.
Governance
The enterprise world, like our society, needs rules & goals to maintain its sustenance and boundaries. Without a set of rules, there would be no control and no accountability. And with no control, issues would immediately arise. That’s where governance comes in. The main purpose behind IT governance is to establish processes that manage IT resources transparently and efficiently, to help the entire organization to achieve its goals collectively.
IT governance can be broken into five domains, defined by the IT Governance Institute (a division of ISACA):
- Value delivery: To categorize and demonstrate the value of the IT department, often foreshadowed by not being directly aligned with the business goals. The lack of value delivery causes a “black hole” effect, where IT costs are perceived as lost.
- Strategic alignment: To support the business through IT and how the department objectives are aligned with the organization.
- Performance management: To track implementation, resource usage & service delivery, and maximize budget.
- Resource management: To optimize and monitor critical IT infrastructure (through asset management, for example) and to deal with third-party providers.
- Risk management: To assure operations continuity and information integrity through risk mitigation.
Functionality
Of course, the most common way in which we look at IT is in its functional responsibilities. IT support, help desk, network administration… the list goes on. From crimping an RJ45 connector into a cable to massive provisioning of devices, the scenarios that IT departments face almost always are operational in nature. Managing specific aspects of IT security, including network security and data security, is also a crucial part of their responsibilities.
Endpoint visibility and device lifecycle
There’s a fourth responsibility the classic chart tends to forget, and it has grown from a sub-task into something worth naming on its own. Someone has to own the full life of every device: enrollment, configuration, encryption status, where it is, when it last checked in, and how it’s wiped or retired at the end. In a distributed company, this is the function that actually protects data, because the data lives on endpoints, not in the server room.
Consider the failure case. A nurse leaves a work laptop in a cab. The architecture is sound, the governance policy says “all devices encrypted,” and support is responsive. But nobody owns the live device inventory, so when the question comes (was that laptop encrypted, and can we wipe it?) the honest answer is “we think so.” Under HIPAA or Ley 21.719, “we think so” is the difference between a non-event and a reportable breach. The structure had a security box. It didn’t have an endpoint owner.
The evidence an auditor wants here is specific: an encryption-status log, a last-seen timestamp, and a remote wipe record. Platforms that provide always-on device visibility and remote actions exist precisely so a named role can produce that evidence in minutes instead of guessing. Prey fits this slot in mixed-OS, distributed fleets where operational simplicity matters more than enterprise overhead.
Quick win: Run a device inventory export this week and check two columns: encryption status and last check-in. Any device showing “unknown” encryption or silent for 30+ days is a blind spot your governance policy claims doesn’t exist.
IT department roles
The majority of roles inside a typical in-house IT department are defined by the size/scope of the organization, the priority when fulfilling the responsibilities mentioned above, and the frameworks adopted.
Nevertheless, there are roles that are broadly accepted as important or relevant to have in your organizational structure. One such role is the project manager, who oversees IT projects, ensures alignment with business objectives, and manages IT-related tasks and teams within the organization. This is especially true if following a functional model that requires a structured approach to fulfill operations and business functions.
CIO: Chief Information Officer
The CIO is the business leader behind and above the IT department, with the primary objective of translating business objectives and key stakeholder needs, sometimes across the organization, to the IT strategy. Consequently, the CIO is in charge of managing all organization-facing technology.
As a C-level manager, a CIO has several executive responsibilities, such as (among many others):
- Leading the IT team, in-house or external (through an MSP)
- Choosing information technology frameworks to apply and leverage, and create & implement IT policies
- Setting appropriate controls and budgets for all processes (infrastructure, cybersecurity, operations)
- Defining and overseeing accountability for all tech-related processes
- Overview of the recruitment for the IT department
The CIO should not be confused with the CTO (Chief Technology Officer), a similar C-level executive that usually deals with customer-facing technology.
IT Director and IT Manager
Below the CIO (or in place of one, at mid-size companies) sits the person who runs the department day to day: people, budget, priorities, and execution. In many organizations this is the senior-most IT role, with no separate CIO at all. The distinction matters when you’re hiring or restructuring, because the two roles solve different problems; the difference between a CIO and an IT Director is strategy versus operational ownership.
Operations: the role of Sysadmin
Operations is a broad term that includes various positions that provide the functional responsibilities of the IT team. Most of these responsibilities include technical support, troubleshooting, installation & provisioning, and a ton of network tasks around all OSI layers.
Commonly called system administrators (or Sysadmin, for short), the professionals who deal with these issues are problem solvers in nature. Experts in multitasking, sysadmins must be proficient in computer science as well as other skills: hardware, software, networks (physical and virtual), databases, web, and even security.
Their level of specialization depends on the complexity of the system itself; small organizations may need a Jack-of-all-trades to deal with the day-to-day, while the enterprise world usually has teams of sysadmins dedicated to all areas. Nevertheless, one thing is certain: almost all organizations require a sysadmin, in-house or otherwise.
Infrastructure
The infrastructure team is responsible for maintaining and managing the technology infrastructure (the hardware, software, and network that supports the delivery of services) of an organization. For that reason, the infrastructure roles are usually the most committed to the business goals, especially in organizations that produce or sell technology products; therefore, an infrastructure team can have goals set by the CIO and the CTO.
The main role of this team is to ensure that the systems supporting that tech is reliable, secure, and scalable. As such, infrastructure engineers are experts in installing and configuring servers, storage systems, network devices, and other technology components, as well as maintaining and updating existing systems.
Infosec
The information security (Infosec) team protects an organization’s information assets and systems from unauthorized access, disruption, disclosure, or destruction at all costs. This involves implementing and maintaining a comprehensive set of IT security measures and controls to ensure the confidentiality, integrity, and availability of information. Infosec engineers, whether it’s networks or device security, are the bouncers of this party; they know very well who can come in, and usually who needs to be stopped or kicked out.
Infosec is a broad field with close ties to security, therefore the team can be managed by other C-level executives as well, which may or may not be dependent on the CIO: the CSO (Chief Security Officer) & CISO (Chief Information Security Officer).
The Infosec team is tasked with conducting security assessments and audits, implementing and managing cybersecurity software, performing risk assessments, developing security policies and procedures, and responding to incidents.
Help desk and support
The front line, usually organized in tiers. L1 handles common requests and password resets, L2 takes the harder issues, and L3 covers deep technical problems that need specialist knowledge. For most employees, the help desk is their entire experience of IT, which makes it the team whose responsiveness shapes how the rest of the business sees you.
Network, database, and security analysts
As organizations grow, specialist roles separate out from the generalist sysadmin: network administrators who design and maintain connectivity, database administrators (DBAs) who manage data storage, integrity, and backups, and information security analysts who handle the hands-on monitoring and investigation the security strategy depends on. In a small team, one person covers several of these. In a large one, each has dedicated headcount.
The roster matters less than one question that cuts across all of it: does a named person own each responsibility, especially the device layer? It’s common to see a chart with a CISO and three analysts while the device inventory quietly belongs to the one sysadmin who started maintaining it two years ago because no one else claimed it. When she’s on PTO, nobody can say which laptops are encrypted. That’s not a staffing problem; it’s a structural one. A role exists on paper, but the work falls through the cracks between boxes.
Quick win: Take your role list and write one name next to each responsibility, including “owns the device inventory and remote wipe.” If any line reads “shared” or “TBD,” that’s the responsibility most likely to be missing when you actually need it.
Frequently asked questions about IT department structure
What is the structure of an IT department?
An IT department is usually structured around a leadership layer (a CIO or IT Director), functional teams (infrastructure, security, operations, and support), and specialists within each. Smaller companies collapse these into one or two generalists; larger ones split them into dedicated roles. The four most common models are functional, independent service line, leveraged, and hybrid.
How do you organize an IT department?
Start with your constraints: headcount, the mix of operating systems and devices, how remote your workforce is, and your compliance obligations. Match the structure to those, not to a template. A small, in-office, single-OS team needs a generalist or an MSP; a large, distributed, mixed-OS team needs dedicated owners for infrastructure, security, support, and device management.
How is a small IT department structured?
In companies under about 25 people, IT is often one generalist who handles support, accounts, devices, and basic security, backed by an MSP for specialized or after-hours work. The priority isn’t a deep hierarchy; it’s making sure core responsibilities (especially device inventory, encryption, and access control) have a clear owner even when that owner is a single person.
What are the main roles in an IT department?
Common roles include the CIO (strategy), IT Director or Manager (execution), CISO or security lead (risk and incident response), sysadmin and operations, network and infrastructure admins, database administrators, security analysts, and help desk support across L1 to L3 tiers. In small teams one person covers several of these; in large teams each has dedicated staff.
What does an IT department do?
An IT department runs and protects a company’s technology: it maintains networks and infrastructure, manages devices and software, enforces security and compliance controls, and supports employees day to day. In modern, distributed companies, a growing part of the job is endpoint visibility: knowing what devices exist, whether they’re secure, and how to act on them remotely.
What’s the difference between an IT department and a help desk?
A help desk is one function within IT, focused on responding to user requests and incidents across L1 to L3 tiers. The IT department is the broader team that also owns infrastructure, security, governance, and device lifecycle. Treating IT as only a help desk is the framing that leaves strategy, security, and endpoint management unowned.
Takeaways
The IT department isn’t disappearing, despite the occasional headline. It’s absorbing more surface area than its org chart admits. The structure on paper still says CIO, infrastructure, security, support, and that’s fine. The question that actually predicts whether the structure works is the one the chart doesn’t show: can it see and control the endpoints it no longer physically touches?
That’s the thread through every decision here. The four structures are different ways to distribute that responsibility. The size-based charts are about when each piece gets its own owner. The roles only matter if each one, especially the device layer, has a name attached. Boxes and reporting lines are the easy part. Coverage of a distributed fleet is the part that gets tested.
So the practical move isn’t a redesign. It’s an audit of three things: visibility (do you have an accurate, current inventory of every device?), control (can you act on a device remotely when it matters?), and evidence (can you prove encryption, location, and response when an auditor asks?). Put a named owner on those three, and the rest of the org chart mostly takes care of itself. Skip them, and the cleanest diagram in the world won’t survive the first missing laptop.
