What IT Infrastructure Does a 100-Person Business Need?

Why is headcount an incomplete starting point?

One hundred employees can describe very different organisations. A professional services firm may depend on laptops and collaboration software, while a manufacturer also needs production systems, scanners, specialist workstations and equipment interfaces. A business with several shifts may have fewer devices than people, whereas a design agency may need multiple high-performance devices per specialist.

Start with the work the infrastructure must support. Identify critical activities, operating hours, locations, remote working patterns and the consequences of losing access. Record external dependencies such as customer portals, payment systems and specialist suppliers. This creates a design brief that is more useful than a shopping list based on employee numbers.

Separate current demand from a realistic growth scenario. Plan for the next office, acquisition or application change without purchasing unused capacity simply because growth is possible. Make assumptions visible so the design can be revised. The right architecture should explain how the organisation operates today and how its most likely changes will be accommodated.

What should the core infrastructure plan contain?

Create a concise architecture record showing identity, devices, connectivity, applications, data, security controls and recovery dependencies. Include who owns each service, where it runs and which suppliers are involved. The record should be understandable enough for a business sponsor to discuss consequences, while linking to the technical detail engineers need.

For each critical service, describe normal operation and the response to interruption. Identify which elements are shared across the business and which are local to a site or department. A single internet circuit, administrator account or undocumented server can become a business dependency even when most applications are cloud hosted.

Use infrastructure management services to maintain this as a living operational record. Review it when material changes occur, not only at renewal time. A plan that accurately reflects dependencies makes support, security reviews and investment decisions easier; a diagram of equipment alone will miss the people and processes required to keep the service working.

Keep a named deputy for important ownership roles so maintenance and recovery decisions can still be made when the usual contact is unavailable.

How should we manage identities and access?

Give every person an appropriate individual identity and define how access changes when they join, move role or leave. Map roles to the applications and data they need, with separate treatment for privileged administration. Shared accounts make accountability and leaver management harder, so challenge them and document any unavoidable exception.

Use strong authentication and device-aware access policies appropriate to the environment. Provide a controlled way to recover access when someone loses a device or authentication method. Test that recovery route before an urgent situation occurs, and ensure it cannot be used casually to bypass the normal controls.

For organisations using Microsoft services, Microsoft 365 support should connect identity administration with licensing, device management and collaboration settings. Access reviews need business input: an administrator can report membership, but the department owner should confirm whether the access is still justified. Record approval and removal so permissions remain connected to actual responsibilities.

What devices should different employee roles receive?

Define a small number of device profiles based on workload and working conditions. Office staff, mobile employees, technical specialists and shared operational roles may need different specifications. Include the applications, peripherals, accessibility needs and support arrangements associated with each profile. A standard model is useful only if it can perform the intended work reliably.

Plan procurement, secure configuration, deployment, updates, repair and retirement as one lifecycle. Record ownership, warranty and management status. Maintain a proportionate spare-device arrangement for roles where waiting for a repair would interrupt critical work. Decide how data and access are protected if equipment is lost or returned.

Avoid choosing devices only by their purchase price. Consider support effort, useful life, compatibility and the cost of downtime. Test specialist requirements before a large order, particularly where software, printing, graphics or connected equipment is involved. For shared devices, define sign-in and data-handling practices so convenience does not leave one employee working under another person's identity.

How much network and internet capacity do we need?

Size connectivity around simultaneous activity and the applications in use. Video meetings, large design files, cloud backups and hosted telephony create different demands. Employee count is only one input. Measure existing traffic where possible and include realistic peaks, rather than relying on the advertised speed of a circuit or wireless access point.

Design office networks around coverage, capacity and separation of different types of equipment. Staff devices, guest access and operational systems may require distinct access rules. A wireless survey and a clear cabling plan can prevent expensive assumptions about where access points should be installed. Meeting rooms and shared spaces deserve particular attention because concentrated use changes demand.

Consider a backup internet route where the business impact justifies it, and test failover with real applications. A second connection is not effective resilience if it shares an unrecognised point of failure or staff do not know how to use it. Record who monitors connectivity, who contacts the carrier and how employees are informed during disruption.

For example, an office might work acceptably during ordinary use but struggle when a training session puts many employees into simultaneous video meetings. Test that expected peak before signing off connectivity and wireless coverage. Record the number of active devices, the applications in use and the location of affected users. If the problem appears only in one room, investigate local capacity and coverage before assuming the whole internet service needs an upgrade. This keeps the response connected to observed demand.

Should a 100-person business use cloud services or local servers?

Choose the hosting model for each workload rather than treating cloud or local infrastructure as a universal answer. Consider application support, performance, access from multiple locations, data handling, recovery needs and the skills available to operate it. A legacy operational application may need a different design from email or document collaboration.

Cloud services can reduce responsibility for some physical equipment, but the business still needs to manage identities, configuration, access and data. Local systems require an explicit plan for maintenance, environmental protection and replacement. Hybrid arrangements add integration and dependency questions that should be documented rather than left between suppliers.

Discuss these trade-offs through managed cloud services. Ask for a workload-level rationale and a cost model that includes operation and recovery. The useful comparison is the service the business receives over time. A monthly hosting bill and a hardware purchase cannot be compared fairly without their associated management, support and resilience obligations.

How should applications and business data fit together?

Maintain an application register with a business owner, technical owner, supplier, renewal date and data purpose. Identify the authoritative source for customers, employees, products and financial information. At this size, uncontrolled duplication can become a larger operational problem than insufficient computing capacity.

Map important information flows between applications. Record whether data moves automatically, through a managed file exchange or by manual entry. Define what happens when a connection fails and who checks for missing or duplicate records. A working integration needs support and exception handling as well as an initial technical connection.

Use system integration services when handovers become fragile. If finance and operations need a shared transaction platform, assess whether Business Central fits the actual processes. Application decisions should be based on operational requirements and data ownership, with infrastructure supporting them. Buying capacity will not resolve disagreement about which record is correct.

What security controls should be part of the design?

Build security into the operating model: managed assets, appropriate access, secure configuration, updates, protection for endpoints and a route for detecting and responding to suspicious activity. Apply controls consistently across office, remote and shared devices. An exception should have an owner and a review date, particularly when a specialist system cannot follow the normal update process.

The NCSC 10 Steps to Cyber Security offers a useful structure for discussing organisational security. Translate the relevant principles into responsibilities and evidence rather than treating a checklist as the finished design.

Agree how managed security services and ordinary IT support coordinate. A monitoring alert must reach someone who can assess it and take action. Review gaps through a scoped cybersecurity audit where appropriate. The objective is a set of controls that can be operated and demonstrated, with management understanding any remaining risk.

What backup and recovery arrangements are necessary?

Start with the business activities you must recover and the maximum tolerable interruption for each. Identify which data must be restored and how much recent work the organisation could afford to recreate. These decisions guide recovery design; they should not be guessed by a supplier from the size of the business.

Include cloud application data, local systems, configuration and the credentials or procedures needed to rebuild services. Synchronisation is useful for everyday access but should not be assumed to provide the recovery history or separation your risk assessment requires. Understand what your application supplier protects and what remains your responsibility.

Test recovery with representative services and record the outcome. Confirm that restored information is usable by the business, that dependencies can be brought back in the right sequence and that authorised people can access the recovery arrangements during an incident. A successful backup notification demonstrates a job completed; it does not demonstrate the organisation can resume its critical work.

How should remote and multi-site working be supported?

Design access around the person, device and task rather than assuming everyone sits on the office network. Remote staff need reliable authentication, managed equipment and a clear route to support. Determine whether particular applications require a controlled connection or different performance arrangements outside the office.

For multiple sites, agree which standards are common and where local differences are necessary. Document network equipment, connectivity, physical access and any site-specific operational systems. Keep essential information available to support staff without depending on a single local employee who may be absent when an incident occurs.

Test the experience from representative locations, including a busy office and a home connection. Consider joining, equipment replacement, password recovery and leaver access as well as everyday use. A design that works for established employees can still fail during transitions. Clarify when on-site attendance is needed and how it will be arranged, particularly for failures that cannot be resolved remotely.

What support model should a 100-person business choose?

Decide who owns service coordination, technical administration, security response and longer-term planning. The right model may be internal, outsourced or a combination. Headcount alone does not determine whether you need a full internal team; application complexity, operating hours and business criticality also matter.

With managed IT support, define the scope carefully. Identify supported users, devices, applications and locations, then describe exclusions and escalation routes. Agree the difference between responding to a ticket and restoring a service. Specialist application suppliers should have clear responsibilities rather than becoming a gap between contracts.

Keep a named business owner for the relationship. Review recurring issues, changes, capacity and risks as well as incident performance. If internal staff and an external provider share responsibilities, maintain a simple responsibility record and test important handovers. The business should be able to identify who is acting at every stage of an interruption without mediating a debate between suppliers.

What monitoring and documentation should we expect?

Monitor the services and conditions that matter to business operation. Device health, storage pressure, failed backups and network availability are useful signals, but each alert needs a defined response. Too many unowned alerts can hide the event that requires attention. Tune thresholds using experience rather than accepting every default notification indefinitely.

Keep an inventory, dependency map, configuration records, supplier contacts and recovery instructions. Store sensitive administration information securely and restrict access appropriately. Ensure the organisation retains access to essential records when a supplier or employee changes. Documentation should help another authorised person operate the service, not merely show that a project once took place.

Review the quality of these records during real changes and incidents. If an engineer cannot identify the owner of an application or the last known configuration, correct the record as part of the work. This turns documentation into an operational habit. Periodically confirm that the documented arrangement still matches the environment, particularly after office moves, acquisitions and application replacements.

How do we budget without buying too much infrastructure?

Separate recurring service costs, project work, equipment replacement and contingency for known risks. Include licences, connectivity, security, backup, application support and staff time. Make assumptions about user roles, growth and retention visible so the budget can be updated without rebuilding the entire plan.

Distinguish necessary capacity from optional improvement. A reliability gap affecting a critical process may justify earlier spending than a refresh based only on equipment age. Conversely, postponing replacement can create avoidable support effort and compatibility problems. Use condition, supportability and business consequence to set priorities.

Connect investment to a wider digital transformation roadmap. If a workflow change is suitable, assess Power Platform automation before buying more resources to sustain manual work. Ask suppliers to explain how the design scales and which future changes would trigger additional cost. A useful budget supports decisions, with room for justified changes and no assumption that every possible expansion must be purchased today.

What should the business test before accepting its new infrastructure?

Acceptance should demonstrate that representative employees can complete real business activities, not merely that equipment responds to a technical check. Include account creation, remote access, printing, document sharing and specialist applications. Test with ordinary permissions so the results reflect the employee experience rather than an administrator's broader access.

Also test a small set of agreed failure situations. Confirm how an internet interruption is handled, how a replacement device is prepared and how a critical service is recovered. Keep the exercise proportionate and controlled, with appropriate approval for any test that could interrupt live work.

Record outcomes, defects and owners, then agree which issues must be resolved before handover. Ensure staff know how to obtain support and that the support team has accepted the documentation. A service that functions during installation but cannot be operated confidently afterwards is not ready for a clean transition into business use.

How should we turn the plan into a practical rollout?

Begin with discovery and confirm the business priorities, existing risks and dependencies. Address urgent exposure while developing the target design. Assign owners to decisions about identity, applications, recovery and support. A staged plan should specify what must be true before the next step begins.

Pilot representative changes with users from different roles. Test normal work, exceptions and recovery, then provide guidance before wider deployment. Schedule changes around trading constraints and retain a realistic fallback where possible. A technically completed rollout is only useful when staff can perform the intended tasks and support teams understand the new environment.

Finish each stage with accepted documentation, ownership and evidence of operation. Review the design after a meaningful period of use and update assumptions using actual performance and support experience. The end result should be a manageable platform for the organisation's work, with clear responsibilities and an affordable route to change as the business grows beyond its current size.