Managed IT vs break-fix for small business

The real difference is what happens between failures

A break-fix arrangement begins when something stops working, which means nothing in it is aimed at the weeks when things are fine. A managed arrangement is the inverse: most of its value is delivered in the uneventful periods, through patching, monitoring, backup verification, onboarding and lifecycle work. That inversion is not a preference, and the published baselines treat it as a minimum. The Center for Internet Security's Implementation Group 1 — the first of the three groups in the CIS Critical Security Controls — consists of 56 safeguards, which CIS frames as essential cyber hygiene and an emerging minimum standard of information security for all enterprises rather than an advanced target. NIST's Cybersecurity Framework 2.0, released on 26 February 2024, organises its core around six functions: Identify, Protect, Detect, Respond, Recover and the newly added Govern. NIST's patch-management guidance, SP 800-40 Revision 4, treats patching as an enterprise process with owners and a cadence rather than an occasional task. Every one of those documents assumes work that happens whether or not something has broken, which is exactly the work a per-incident arrangement has no mechanism to perform.

• Break-fix bills for events; managed support bills for operating the estate.
• CIS Implementation Group 1: 56 safeguards, framed as essential cyber hygiene.
• NIST CSF 2.0 (February 2024) adds a Govern function to the original five.
• Ask what the provider does in a month with no failures at all.

Modelling the comparison honestly

Start with the frequency of recent failures rather than an assumption about what might happen. Count how many incidents affected staff in the last twelve months, how long each lasted, how many people were affected and what they could not do. Then attach the business's own value to an hour of that disruption — lost transactions, idle staff, missed deadlines, or simply the hours your own team spent firefighting — and add the reactive invoices from the same period. The arithmetic is worth doing even roughly: eight incidents over a year, three business hours each, with nine people unable to work while they last, is a little over two hundred person-hours of stopped work, before anyone counts the hours your own staff spent diagnosing. That is the denominator the managed proposal should be tested against, and the ratio of prevented incidents to total incidents is the number to argue about. Two further inputs belong in the total. The first is the support position of what you run, because a system that has passed its vendor support date cannot be patched at all: Microsoft's release-health page records that Windows 10 Enterprise LTSB 2016 reached its end of updates on 13 October 2026 and that Windows Server 2016 reaches its own on 12 January 2027. Those dates arrive whether or not anyone is maintaining the estate — for an estate still running the 2016 LTSB release the first of them has already arrived — and an estate that reaches them without a migration plan turns a planned refresh into an emergency purchase. The second is the equipment that failed early because maintenance was deferred, which brings forward replacement that age alone did not require.

• Incident count and duration over the last twelve months.
• Who was affected and what work stopped.
• The business's own value for an hour of that disruption.
• Assets already past, or approaching, their published vendor support date.

What managed support includes, and what it excludes

Managed support is not one product, and the phrase covers arrangements that differ enormously in what they take responsibility for. The core of most agreements is patching and updating, endpoint monitoring and management, backup operation with some level of restore testing, service desk cover during stated hours, and vendor coordination when a third party has to be involved. Commonly excluded are project work with a defined end, hardware replacement, line-of-business applications the provider does not support, and anything outside the agreed hours. The exclusions matter more than the inclusions, because they are where the disagreement happens later. The discipline that exposes them is to write your obligations in one column — a patch cadence, a restore that has actually been tested, an access review after a member of staff leaves, an asset register that is current — and ask which named service meets each line. Where a line has no service against it, the obligation has stayed with you. Restore testing deserves its own line, because a backup that has never been restored is an assumption rather than a control: the question to ask is when a restore was last performed, on what, and how long it took from decision to working system.

• Patching, monitoring, endpoint management and backup operation.
• Onboarding and offboarding of staff, which break-fix rarely covers.
• Vendor coordination with carriers, software and hardware suppliers.
• Written exclusions: projects, hardware, applications, out-of-hours work.

Where break-fix genuinely wins

Break-fix can be the rational choice, and pretending otherwise does not help anyone. It suits a small estate with stable, well-understood equipment, a business that has genuine internal capability and only needs escalation, or an organisation whose systems are deliberately simple and whose tolerance for disruption is high. What makes those cases work is that somebody internal owns the periods between incidents — somebody is still patching, still checking backups and still managing the replacement cycle — and those are the three duties a comparable managed arrangement takes over. Break-fix stops being rational when nobody owns that work, because failures then compound rather than being contained, and because the support dates on the equipment do not wait for a decision. The common way the condition quietly fails is staffing: the internal owner leaves, nobody inherits the patching and backup routine as a named duty, and the arrangement keeps its appearance while losing its substance.

• Small, stable estates with low dependency on IT availability.
• Businesses with real internal capability and clear escalation needs.
• Deliberately simple environments with high disruption tolerance.
• The condition: somebody internal still owns prevention.

The obligations that decide it for regulated businesses

For a large share of businesses this stops being a preference, because the rules they already fall under describe continuing duties rather than certificates held once. The FTC's Safeguards Rule at 16 CFR Part 314 covers financial institutions within the Commission's jurisdiction, and its notification provision at 16 CFR 314.4(j) requires notice to the FTC as soon as possible and no later than thirty days after discovery of a notification event — a duty that took effect on 13 May 2024 and that assumes somebody was watching. The HIPAA Security Rule's contingency plan standard at 45 CFR 164.308(a)(7) requires backup, disaster recovery and emergency-mode operation procedures, and a business associate agreement obliges the vendor to apply appropriate safeguards and to report any use or disclosure the agreement does not permit. PCI DSS v4.0 applies to any business that stores, processes or transmits cardholder data, and the requirements it had marked as future-dated became mandatory on 31 March 2025 rather than remaining best practice. Defence suppliers carry the basic safeguarding duties in FAR 52.204-21 for covered contractor information systems, with NIST SP 800-171 as the baseline for controlled unclassified information. None of those is a badge on a website; each is work that recurs, and each needs a named person performing it between the events that would otherwise be the only time anyone looks.

• FTC Safeguards Rule: notice to the Commission within thirty days of discovery.
• HIPAA contingency planning at 45 CFR 164.308(a)(7), reinforced by the business associate agreement.
• PCI DSS v4.0 applies wherever cardholder data is stored, processed or transmitted.
• Defence work adds FAR 52.204-21 and the NIST SP 800-171 baseline.

What to gather before asking for pricing

Bring the facts that make the two models comparable: the number of users, endpoints, servers and sites, the age of the equipment and how much of it is past its vendor support date, the incident history for the past year with durations, the business systems that must keep running, any application the provider could not realistically support, and the hours during which support is genuinely needed. Add the compliance regimes the business is subject to, because those determine which duties cannot be left to a reactive arrangement, and add the internal capability you intend to keep, because that determines where the boundary between internal and provider responsibility should sit.

• Counts of users, endpoints, servers and sites.
• Asset age, warranty position and vendor support dates.
• Twelve months of incident history, with duration and impact.
• The obligations you carry, and the internal capability you intend to retain.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions