A useful network AMC names the covered assets, preventive work, response and restoration clocks, spares and recovery evidence. “Comprehensive” by itself does not define these commitments.
This guide helps office owners, IT managers and facilities teams turn those decisions into a comparable maintenance scope. Start with the asset register, then agree what the provider does, what the owner funds and which outside dependencies remain.
For the initial estate assessment, see our office network audit guide. For installation sign-off, see network acceptance tests. This article focuses on ongoing maintenance scope and evidence.
What an AMC is, and what it is not
An Annual Maintenance Contract (AMC) is a fixed-term agreement under which a service provider maintains a defined set of equipment on defined terms. Three terms decide most of its value:
- Preventive maintenance is scheduled work done before a failure: inspections, health checks, backups and updates.
- Corrective maintenance is work done after a fault is reported.
- SLA (service level agreement) is the measurable commitment on response and restoration, for example "engineer response within X business hours".
Three related things are often mistaken for an AMC:
- Manufacturer warranty covers hardware defects for a fixed period under the manufacturer's terms. Its exact cover varies: onsite labour, configuration recovery and installed cabling are not automatically included. A cabling-system warranty can have separate conditions. Ask for the actual warranty document.
- Manufacturer support or subscription (firmware access, security signatures, advanced replacement) is bought from the manufacturer or its channel. An AMC provider can *manage* it but usually does not *include* it unless the contract says so.
- Project defect liability is the installer's obligation to fix workmanship faults for a stated period after handover. It is not a maintenance service.
Comprehensive vs non-comprehensive: the most expensive ambiguity
| Aspect | Non-comprehensive (labour-only) | Comprehensive (parts-inclusive) |
|---|---|---|
| Engineer visits and labour | Included | Included |
| Replacement of failed hardware | Chargeable | Included, often with exclusions |
| Provider's risk | Low | Higher, so pricing and exclusions reflect it |
| Typical exclusions | Consumables, new work | Misuse, power surges, liquid damage, end-of-life items, licences |
Neither model is automatically better. A comprehensive AMC on 7-year-old switches may exclude exactly the items likely to fail, as "end-of-life" or "no spares available". Ask for the exclusions list before comparing prices. *Do not compare a comprehensive quote with a labour-only quote on price alone.*
What a network AMC can cover
The sections below separate what *can* be covered. Whether it *should* be covered depends on your risk, estate size and budget.
Inventory and documentation
Maintenance cannot be measured against an asset list that does not exist. A sound AMC starts with a baseline that records:
- device make, model, serial number, firmware version, location and warranty or support end date;
- patch panel and outlet labelling, switch port maps, VLAN and IP plan;
- the rack layout and the ISP circuit details.
Keeping the baseline current is part of the work, not a one-off. Without it, "we maintained everything" cannot be checked.
Active equipment: switches, firewalls, WiFi


- Health checks cover CPU and memory trends, interface errors, PoE port status, fan and power-supply alarms, and logs.
- Configuration backup means a stored, dated copy of each device configuration, with protected storage, retention rules and a restoration method matched to the device model and software version. Test recovery on a compatible spare, isolated lab or supported platform; do not overwrite production configuration merely to demonstrate a backup. A downloaded file is not proof of recoverability. CIS v8.1 Safeguard 11.5 recommends quarterly or more frequent sampling of backup recovery for its applicable implementation groups. Source 2 Adopt a documented schedule appropriate to the estate.
- Firmware and software review. NIST describes patching as a cycle of identifying, prioritising, acquiring, installing and verifying updates, and recommends a defined strategy rather than ad hoc updates Source 1 For an office network, the contract should say who monitors vendor advisories, how urgency is judged, when changes are made, and who approves downtime. Keep a pre-change backup, check vendor upgrade prerequisites, verify services afterwards and record a usable rollback or recovery route. Do not leave serious advisories unreviewed until a routine half-year visit.
- Security hygiene: removing unused accounts, changing default credentials, reviewing firewall rules and guest-network separation. Detailed design is covered in the existing firewall and guest WiFi articles.
- WiFi review: channel and power review, client-density complaints, and rogue or failed access points. A new placement design or full RF survey is separate work unless specifically included. Review the actual clients and applications before proposing more APs; our WiFi placement guide covers that design decision.

Passive cabling
Structured cabling normally needs little routine maintenance. What an AMC can sensibly include:
- inspection of patch cords, patch panels, labelling and rack dressing;
- re-testing of reported outlets, and a sampled re-test against the original certification baseline *if* a baseline report exists;
- moves, adds and changes (MACs), with updated labels and records.
Re-testing needs equipment appropriate to the claim. A continuity tester cannot reproduce a certification report. If the original installation was certified, ask for the baseline results to be retained as the reference. If no certification exists, suitable certification testing can establish the current performance of the links actually tested; a basic continuity check cannot. Sampling cannot certify the remaining untested links or prove their historic condition. State category/standard limit, link type, adapters, calibration status and report format. Fluke explains why those choices matter. Source 3

Power and environment
- UPS battery condition and runtime check, using the selected manufacturer’s status/self-test and battery instructions. Record load and battery age; compare runtime with the agreed business target and model runtime data. UPS power capacity and runtime are different properties. Source 4 An actual battery-discharge test needs an approved window and recovery plan; no universal replacement interval is assumed.
- Rack temperature observation and airflow obstruction, such as obstructed intakes or unmanaged cable bundles. Correct blanking panels can support intended airflow; they are not automatically an obstruction. Follow the equipment/rack ventilation layout.
- Earthing and electrical work stay with a qualified electrician. A network AMC should not claim to cover them unless the provider is competent and authorised for that work.
Internet circuits and carriers
An AMC provider can monitor and *escalate* ISP faults but usually cannot *fix* the carrier's network. State this clearly. The valuable deliverables are fault logging, evidence of the outage and follow-up with the ISP. For dual-ISP setups, add a scheduled failover test to the preventive plan.
Related ELV systems
CCTV, access control, and fire and public-address systems are often bought under separate AMCs because the skills, spares and statutory aspects differ. Do not treat a network inspection as a fire-system maintenance visit. Name the required specialist scope, applicable installation requirements and responsible provider separately. If network AMC and ELV AMC are combined, write separate scope lines for each.
Preventive plan: a sample calendar
This illustrative calendar separates scheduled visits from event-driven security work. Frequencies are contract-planning choices unless a named framework or manufacturer specifies otherwise.
| Frequency | Activity | Evidence to retain |
|---|---|---|
| Ongoing / event-driven | Monitor agreed alerts and vendor advisories; triage serious issues within the defined support/emergency process | Alert/ticket and prioritisation record |
| Monthly (remote) | Log trends, backup completion, licence/support expiry watch | Monthly report and action list |
| Quarterly (on-site) | Physical inspection, patch-cord and rack check, UPS status, spares check, change-log review, sampled configuration recovery test | Signed visit sheet with photos |
| Half-yearly | Planned software review/change window, firewall-rule and user-account review; urgent fixes are not deferred to this date | Change plan and approval record |
| Annually | Full recovery/failover exercise, agreed cabling sample, documentation refresh; critical recovery checks can be more frequent | Test records, updated baseline |
| After any major change | Update inventory, diagrams and backups | Revised documents |
Corrective maintenance: write the response terms down
A useful SLA can be measured without guessing what the clock means. Define each of the following:
- Support window (e.g. business hours or extended hours) and which public holidays apply.
- Severity levels with examples.
- Response time, meaning when an engineer begins work, versus restoration target, meaning when service returns. These are different commitments. Many contracts promise only the first.
- Remote vs on-site handling, and whether travel time counts.
- Escalation path with named contacts.
- Spares policy: where spares are held, and who bears the cost of delay when a part must be ordered.
Define acknowledgement separately from engineer response, onsite arrival, temporary workaround and full restoration. A parts-inclusive price does not establish a restoration time unless compatible spares and deployment arrangements support it.
The diagram is a hypothetical timeline, not an APYS response promise. Acknowledgement takes 5 minutes, engineer work begins after 20 minutes, and service is restored after 70 minutes. Document the clock start, eligible support hours, timezone, evidence, exclusions and any agreed pause rules. Keep ISP/vendor dependency time visible rather than silently removing it from the record.
An *illustrative* severity table follows. Replace the values with figures agreed in your own contract.
| Severity | Example | Target to define in contract |
|---|---|---|
| 1: Business stopped | Firewall failure, all users offline | Response and restoration targets, 24×7 or business hours |
| 2: Major degradation | A department loses service, or one ISP fails while backup works; severity follows business impact | Response and restoration targets |
| 3: Minor | Single outlet/user/AP only where business impact is minor; a critical endpoint can justify a higher severity | Scheduled next-visit or defined timeframe |
| 4: Request | New VLAN, new user port | Scheduled change |
Worked example (hypothetical)
*This is an illustrative scoping exercise, not a measured result or an APYS project.*
Assumptions:
- A 60-person office with one firewall, one core switch, three 24-port PoE access switches, six WiFi APs and 85 installed cabled outlets. The six AP uplinks are included within the 85 outlets.
- Assume 60 access ports are active (54 other wired endpoints + 6 APs); remaining staff connectivity uses the wireless design. This is an arithmetic assumption, not a validated WiFi capacity plan. Three switches provide 72 access ports, leaving 12 before any other copper-port use; dedicated separate uplinks are assumed.
- One rack UPS and two ISP circuits for failover. Provider-owned ISP CPE is listed as a coordination dependency, not included replacement stock unless expressly contracted.
- The cabling was certified at installation and the baseline report is available.
- Business-hours operation.
Step 1: Asset register. 1 firewall + 1 core switch + 3 access switches + 6 APs = 11 network devices. Add 1 UPS = 12 powered assets, plus 85 passive outlets. Do not count the UPS twice. Record each asset’s scope separately.
Step 2: Preventive effort. Quarterly visits give four on-site visits per year. Monthly remote checks give 12 reports.
Step 3: Cabling sample. If the owner chooses a 10% annual sample of outlets, 85 × 0.10 = 8.5, rounded up to 9 outlets. Choose a documented mix of zones, route lengths, high-use positions and reported faults. Keep affected/problem links outside the sample cap when troubleshooting is in scope. Nine is the proposed routine sample, not certification of all 85 outlets. Preserve the original failed result and accepted retest where repairs occur. The 10% percentage is a planning choice, not a standard requirement.
Step 4: Cover decisions.
| Item | Decision to record |
|---|---|
| Switch failure | Labour only, or replacement included? Is a standby unit held on site? |
| Firewall subscription | Owner renews with the manufacturer or channel partner; AMC provider tracks the date |
| UPS batteries | Check included; replacement chargeable |
| ISP outage | Escalation included; carrier repair excluded |
| New cable runs | Chargeable project work, quoted separately |
Step 5: Request a quotation with this table filled in, and compare each vendor's *exclusions* line by line. Pricing is for suppliers to confirm.
Delivery and security considerations
An AMC provider will hold privileged access to your network. Include the following in the contract:
- named engineers, individual authorised accounts and least-privilege roles; remove access at contract end while retaining the required audit history;
- approved remote access with MFA, administrative MFA where supported, time-limited permissions where practical and useful session/action logs. CIS Control 6 supports managed access and revocation. Source 5 Avoid exposing device administration directly to the internet;
- change-control: no configuration change without a ticket and approval, and a rollback plan for significant changes;
- confidentiality terms, and a clear statement of who may keep configuration backups, where they are stored, how long they are retained and how they are handed back or disposed of. Configurations can contain sensitive secrets; protect exports and transfer access securely. CIS Control 15 addresses evaluation of providers handling sensitive platforms/data. Source 6
Reasonable maintenance windows and notice periods for downtime also belong in the document.
Common failure modes of AMCs
| Failure mode | Typical cause | Prevention |
|---|---|---|
| "Not covered" after a failure | Vague scope or buried exclusions | Itemised asset list with a covered/excluded column |
| Slow restoration despite a quick response | Response time defined, restoration not | Add restoration targets and a spares plan |
| Expired licence discovered during an incident | Nobody owns renewals | Expiry register and 60/30/7-day reminders, with an agreed owner |
| Backup cannot be restored | Backup never tested | Recovery tests on the agreed risk-based schedule, with evidence |
| Configuration drift | Changes made without records | Change log tied to tickets |
| Reports that say nothing | Generic "all OK" sheets | Reports with specific metrics, findings and open actions |
| Warranty replacement delayed | Serial number or purchase proof missing | Keep invoices and serial numbers in the register |
Troubleshooting sequence an AMC engineer should follow
The engineer should preserve useful evidence and isolate the affected layer before replacing equipment:
- Define the scope of impact. One user, one floor, one VLAN or everyone? Check what changed recently.
- Check power and physical state: device LEDs, UPS state, loose or damaged patch cords.
- Check the link: port status, speed/duplex negotiation, error counters, PoE state if relevant.
- Check addressing and services: DHCP, DNS, gateway reachability.
- Check upstream: firewall status, ISP link, failover state.
- Review logs and recent changes, and use an approved rollback where the evidence points to a recent change and a known safe recovery path exists. Correlation alone is not proof; record the result of the controlled check.
- Replace or bypass equipment when diagnosis supports it, with approval and safe configuration recovery. For a suspected power fault or failed device, immediate isolation/substitution may be justified; do not force every incident through a rigid sequence. Record removed/installed serial numbers.
- Verify service with the user, then close the ticket with evidence, confirmed cause where known, action and follow-up. Mark an unknown cause honestly and keep further investigation open when needed.
Acceptance tests at handover and at each review
Define evidence before the contract starts. At baseline handover, and again at each annual review, you should be able to verify:
| What to check | How | Evidence to retain | Judge by |
|---|---|---|---|
| Inventory accuracy | Walk the rack and compare it with the register | Marked-up register | No unlisted or missing devices |
| Config backup | Restore a backup to a test or spare device | Restore log | Device works as expected |
| Remote monitoring | Trigger a harmless alarm, such as a disconnected test port | Alert record | Alert received by the right people |
| Failover | Planned disconnect of the primary ISP, with notice | Time-stamped test sheet | Agreed applications recover within the project target; record transition and failback behaviour, including sessions that drop |
| UPS | Controlled runtime or status check per manufacturer guidance | UPS report | Status passes selected-model guidance; measured runtime at recorded load meets the agreed service target |
| Cabling sample | Re-test selected outlets with suitable equipment | Test files compared with baseline | Results per the test limit specified in the project |
| Documentation | Compare diagrams to the live network | Updated diagrams | Diagrams match reality |
Set measurable pass criteria in the contract, such as the named cabling test limit, required applications after failover and runtime at a stated load. Interpret PASS* through tester guidance: Fluke treats it as a standards-compliant pass within measurement uncertainty; stricter treatment must be agreed beforehand. Source 3 No universal numerical pass limits or actual measurements are claimed here.
Handover and contract checklist
Before signing
- Itemised asset list with make, model, serial, location and covered/excluded status
- Comprehensive or labour-only stated for each asset class
- Support hours, severity definitions, response *and* restoration targets
- Spares arrangement, and who pays for expedited parts
- Preventive visit schedule and report format
- Remote-access method, credential policy and confidentiality terms
- Renewal ownership for licences and manufacturer support
- Exclusions list in plain language
- Charges for out-of-scope work and emergency visits
- Termination terms, and handback of documentation and credentials
At each quarterly review
- Signed visit report with photos
- Open tickets reviewed and aged
- Change log matches configuration
- Backup date confirmed
- Licence and support expiry dates reviewed
- Recommendations recorded, with an owner and date
Worked SLA clock: business hours versus elapsed outage
Assume a contract covers Monday–Friday, 09:00–18:00 in the named site timezone, with no holidays or agreed clock pauses in this example. A valid ticket arrives Friday at 16:30; an engineer starts work Monday at 10:00. The eligible response clock and the elapsed time are different:
| Clock component | Calculation | Result |
|---|---|---|
| Friday eligible time | 16:30–18:00 | 1.5 hours |
| Monday eligible time | 09:00–10:00 | 1 hour |
| Engineer-response clock | 1.5 + 1 | 2.5 support hours |
| Total elapsed wait | Friday 16:30–Monday 10:00 | 65.5 hours |
If the agreed response target were four support hours, that hypothetical response meets the target. It still leaves a 65.5-hour wait, and says nothing about when service was restored. An automated acknowledgement is not an engineer starting diagnosis. Do not present this example as an APYS SLA or infer that a business-critical office should buy business-hours cover.
Keep dependency time visible
Capture ticket validation, acknowledgement, engineer start, onsite arrival if needed, workaround, usable-service restoration and final closure as separate timestamps. For a claimed pause, record its start/end, reason, contractual basis and approver; preserve the unadjusted elapsed duration alongside the eligible SLA duration. Waiting for the owner’s purchase approval, an ISP repair or a replacement part should remain visible even where the contract permits a pause.
Define a closure record the client can check
Retain affected asset and service, symptom, evidence, confirmed cause or “cause not established”, change/approval reference, serial numbers for replacements, tested user workflow, recovery confirmation, pending actions and owner. A temporary workaround may restore service while a root-cause investigation remains open. Distinguish those states and record recurrence under the agreed reopen/incident-linking rule rather than silently counting each symptom as an unrelated resolved ticket.
Correct the preventive report when evidence is missing: “backup downloaded” is different from “recovery demonstrated on an isolated compatible platform”. Use the recovery schedule above and the adopted framework requirements; do not let an annual exercise replace more frequent checks already promised in the contract.
Frequently asked questions
Is network AMC the same as desktop IT support?
Not necessarily. Desktop software, user devices and printers may sit in a different contract. Name the asset classes and the boundary between network diagnosis and end-device support, including who owns incidents that cross both.
Can a new provider maintain equipment it did not install?
Yes, if its capabilities and support rights fit the equipment. Start with an audit, record existing defects, confirm access and licensing, and agree the cost of correcting the baseline. Do not hide pre-existing faults inside an “all covered” promise.
Does comprehensive cover remove the need for a spare?
No. Paying for a replacement and restoring service quickly are different decisions. Specify compatible standby stock, where it is held, firmware/configuration readiness, ownership and replenishment after use.
What happens when a switch or firewall reaches end of support?
Identify it before signing or renewal. Confirm spare availability, supported firmware and the agreed replacement path; any temporary continued maintenance should document the limitations. An AMC cannot create manufacturer updates or replacement stock that no longer exist.
Sources and Further Reading
- NIST SP 800-40 Rev. 4: Enterprise Patch Management Planning
- CIS v8.1 Control 11: Data Recovery
- Fluke Networks: Top 10 Cable Testing Mistakes
- Schneider Electric: UPS Buying Guide
- CIS v8.1 Control 6: Access Control Management
- CIS Control 15: Service Provider Management
Reviewed 28 October 2026. NIST/CIS recommendations are engineering and security guidance, not automatic legal requirements for every Indian office. Model instructions, adopted framework requirements and the signed service scope govern the actual work. Counts and timelines are hypothetical; no APYS SLA, current price or real installation result is claimed.
Talk to APYS Projects
APYS Projects provides structured LAN cabling, WiFi, firewall, switching and server rack services from Wagholi, Pune. APYS Projects serves projects across India. Share your device list, current support/licence dates, floor plan, recurring faults and required support hours for a network maintenance-scope enquiry. Email Purchase@apysprojects.com, call +91 9921490342, or send your requirements.