A.7.13 Equipment maintenance: requirements and evidence

What A.7.13 equipment maintenance asks organizations to prove

A.7.13 asks that equipment is maintained correctly so that information stays available, intact and confidential. An auditor who asks how equipment is kept working and who touches it is testing whether maintenance is planned, performed only by authorized people, supervised when outsiders are involved, and recorded well enough to reconstruct what was done. The control does not ask for a particular maintenance interval, a particular vendor or a particular tool. It asks the organization to decide its own maintenance rules for the equipment that holds or processes information, then to show those rules are followed.

Maintenance is a security risk because it gives people access that ordinary users do not have. A vendor technician on site, a remote support session that opens a tunnel into a server, or a repair that swaps a drive or resets firmware can change configurations, expose data on removed media or leave a device with weaker settings than before. The evidence auditors look for is a trail for each intervention: who performed it, what was changed, why it was needed, whether it was approved and whether the system was checked afterward. Confirm with your own operations team which equipment falls in scope, since servers, network devices, storage, backup appliances and endpoints each carry different maintenance paths.

The difficulty is usually fragmentation. Maintenance requests sit in one ticket queue, approvals in email, vendor visit details in a supplier portal and configuration changes in a separate change log, so no single record shows the full sequence. The control's 2013 predecessor, A.11.2.4 Equipment maintenance, covered similar ground, and ISO/IEC 27002:2022 traces A.7.13 back to it. NIST's crosswalk relates A.7.13 to MA-2 and MA-6 in SP 800-53, and ENISA's NIS2 mapping links it to change management, repairs and maintenance. NIST itself cautions that mapped controls are not always equivalent, so treat these mappings as starting points and confirm the wording against your own obligations. The ISO/IEC 27001:2022 entry on the IEC Webstore is the place to confirm the control's exact requirements.

Which equipment, maintainers and records are in scope

A.7.13 applies wherever equipment that holds or processes information is serviced, repaired or configured, whether by staff, vendors or field technicians. The cards below separate the equipment families and maintainer types that usually change the evidence an auditor expects, so the organization can decide scope before writing its maintenance procedure.

Data center and server hardware

Physical servers, storage arrays, backup appliances and chassis firmware are the classic maintenance targets. Decide whether hypervisor and firmware updates, drive replacements and memory swaps are logged as maintenance events with a named technician and a reason. Check whether hardware in colocation or leased space is covered by the provider's maintenance records or only by your own. Ask which record proves the work happened and when.

Network and security appliances

Firewalls, routers, switches and VPN concentrators hold configuration that controls information flows, so their maintenance is both hardware and change work. Decide whether firmware upgrades and rule changes follow the same approval path as A.8.32 Change management. Confirm that the configuration backup taken before each intervention is retained and that the vendor's support access is documented. Ask who can open a support session on a firewall and how that session is recorded.

Endpoints and mobile devices

Laptops, workstations and phones are maintained through repairs, reimaging, battery swaps and operating system updates, often by a service desk rather than a specialist. Decide whether ticketed repairs count as maintenance records and whether devices sent for repair are tracked from departure to return. Check whether any device with storage media also falls under A.7.10 handling rules, since a repaired drive can leave the premises. Ask how an endpoint returned from repair is verified before reconnection.

Vendor and field technician access

Equipment serviced by outside vendors or field technicians creates the most scoping questions. Decide whether remote vendor sessions into a device count as maintenance, and whether each session needs a named sponsor, a time window and a log of actions taken. Check how on-site technicians are escorted and identified, and whether their work is recorded before they leave the secure area. Confirm which contracts require the vendor to provide maintenance reports and retain them for the organization.

Cloud-hosted and provider-managed equipment

Equipment in a cloud provider's facilities is maintained by the provider, but the organization still needs evidence that its own configuration, instances and managed services are maintained correctly. Decide where the boundary sits in each contract and what the provider's maintenance reports cover. Check whether the provider's third-party assurance reports are obtained and reviewed, and whether the organization's own change records fill any gap. Confirm the scope in writing with the provider rather than assuming it.

How an assessor tests equipment maintenance

This table sets out five checks an assessor typically runs for A.7.13, what each one asks the organization to produce, and where the checks most often fail. Read each row as a test the organization should rehearse before an audit, since the evidence named in one row often supports the next.

Test approach	Evidence requested	Common findings
Compare the maintenance schedule against the asset register	Current maintenance schedule, asset register extract, and the owner or contract for each maintained device	Scheduled items that do not appear in the asset register, or servers and network devices with no defined maintenance interval
Sample completed maintenance tickets	Tickets or work orders for a selection of past repairs and servicing visits, with dates, device identifiers and closure notes	Tickets closed without a description of the work, or maintenance performed with no ticket at all
Check that maintainers are authorized and identified	Authorization list or approved vendor register, named technician records, and access grants for maintenance accounts	Shared or generic accounts used by vendors, or technicians working on equipment who are absent from the approved list
Verify supervision of outside personnel on site	Visitor or contractor logs, escort assignments, and the supervising employee's sign-off on the visit	Contractors working unaccompanied in server rooms, or escort records that do not match the visit times
Confirm that repair-related changes are recorded and reviewed	Change records linked to maintenance tickets, configuration backups taken before and after work, and reviewer approval	Firmware or configuration changes made during repair that were never logged or reviewed by a second person

Sequence to bring maintenance under control

This sequence turns scattered repair work into a controlled process: every piece of equipment has a known owner and location, maintenance follows a schedule, only approved people touch the equipment, and every action leaves a record that someone reviews. Each step produces a artifact an assessor can sample.

Build an asset inventory with owners and locations
Start by listing every device that holds or processes information, including servers, network gear, endpoints, printers, environmental controls and devices held by suppliers. For each item, record the serial number, location, business owner and the system it supports. Automated discovery tools can populate much of this, but a named owner must confirm each entry. The step is done when the inventory reconciles against procurement records and the asset owners have signed off their items.
Define the maintenance schedule per asset
For each inventory item, set the maintenance interval, the type of work (preventive, corrective, firmware or vendor-recommended service) and the maintenance window. Base intervals on the manufacturer's documentation and the criticality of the asset to availability. Record the schedule in the inventory or a maintenance calendar so the same source drives planning. The output is a schedule that an auditor can compare against actual maintenance records.
Approve the authorized maintainer list
Name the internal staff and the external companies permitted to maintain each class of equipment. For external maintainers, record the contracted scope, the named individuals where possible and the confidentiality terms that cover access to information on the equipment. Remove access for anyone who leaves the approved list. The output is a maintainer register, reviewed by the asset owner and the security function, that matches the access accounts actually granted.
Write the supervision rule for outside personnel
Define how visiting engineers and remote vendor sessions are handled. Specify who escorts on-site visitors, what they may access, whether storage media may be removed, and how remote sessions are authorized, time-limited, logged and recorded. Require that vendor sessions start from a ticket and are attended or monitored by an internal staff member. Confirm with each vendor that these terms are written into its contract or service agreement. The output is a short supervision standard and a signed acknowledgement from each maintainer.
Route every maintenance action through one ticket process
Require that each planned or unplanned maintenance action is opened as a ticket, assessed for risk, and approved through a change review before work begins, with a documented rollback approach for significant changes. Record the technician, the work performed, the time, the parts replaced and the verification result on closure. A helpdesk or IT service management tool such as GLPI can hold the tickets and change records, and an open-source helpdesk can handle requests from outside parties. Confirm that the tool's configuration matches your change approval rules. The output is a closed ticket for every maintenance event.
Set a recurring review of records against the schedule
At a cadence you set and document, compare closed maintenance tickets with the schedule and the inventory. Identify missed maintenance, repeated faults, unauthorized maintainers and remote sessions without a linked ticket. Assign each exception an owner and a due date, and feed recurring problems into the risk register and the management review. The output is a signed review record showing what was checked, what was found and what was corrected, which is the evidence an assessor most often samples.

Evidence that satisfies A.7.13 and how to keep it current

An assessor testing A.7.13 Equipment maintenance follows the trail from schedule to work performed to follow-up. Each artifact below answers one link in that trail, and each must be dated and attributable to a named person or system so it stands up when the auditor samples it.

Maintenance schedule

The schedule lists each in-scope asset, the maintenance interval set by the manufacturer or the organization's risk assessment, the responsible team and the next due date. It is the baseline an auditor compares against tickets to find missed work. Keep it current by exporting the schedule monthly, recording who approved any change to an interval, and retaining prior versions so an assessor can see when intervals changed. Confirm whether the schedule lives in your ITSM tool or a controlled document.

Authorized maintainers register

This register names each internal technician and approved external vendor allowed to service equipment, with the systems each may touch and the date of approval. Auditors check whether work was done by someone on the list. Review it at a fixed interval, remove leavers and expired vendor contracts, and sign off each review with a date and reviewer name. Record the approval date for every entry, not just the current roster.

Maintenance tickets with sign-off

Each maintenance job should be a ticket showing the asset, the fault or scheduled reason, the work performed, parts replaced, the technician's identity and a closing sign-off by someone other than the technician. Tickets are the primary evidence that maintenance happened as planned. Export closed tickets monthly and confirm that no ticket closed without a named approver. A ticket system such as GLPI can hold these records if its workflow is configured to require the closure fields.

Supervision logs for outside personnel

When a vendor engineer works on site or remotely, the log records arrival and departure times, the escort or remote session monitor, the systems accessed and the tasks completed. Without this log, an auditor cannot show that unauthorized parties were kept away from information during maintenance. Require the supervising staff member to countersign each entry, and retain logs with the related ticket so the two can be matched during sampling.

Change records for configuration-altering repairs

A repair that changes firmware, network settings, disk configuration or security settings must also go through change management. The change record shows the request, risk assessment, approval, implementation window and post-change verification. Auditors sample these to confirm that maintenance did not silently alter controls. Link each change record to its maintenance ticket and keep the rollback plan with it. Confirm the change process in your organization's procedure before you rely on it as evidence.

Periodic reviews of overdue items

A periodic review compares scheduled items against completed tickets and lists anything overdue, with the owner and the follow-up action taken. This shows the organization notices gaps rather than only recording work it did. Hold the review at a set interval, record the reviewer, the date and the decisions, and track each overdue item to closure. Wazuh inventory data or Zabbix host records can supply asset lists for the comparison, so confirm which fields your team trusts.

What meeting A.7.13 costs in money and effort

This table breaks the cost of meeting A.7.13 into its components, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to keep it down. Read it before requesting a quote so you can ask each provider to price the same components.

Cost component	One-time or recurring	What drives it	How to keep it down
Ticketing and maintenance tooling	Setup one-time, hosting and upkeep recurring	Number of sites, maintainers and change types tracked; whether a commercial helpdesk license is already owned	Self-hosted open-source ticketing such as GLPI removes license spend; confirm the hosting and upgrade effort with your own staff or partner
Engineering time for the asset inventory and maintenance schedule	Mostly one-time, with periodic refresh	Size and age of the estate; how much hardware and software data is collected automatically versus typed in by hand	Populate the inventory from agents such as Wazuh Syscollector or Zabbix host inventory, then review gaps rather than building the list from scratch
Staff time supervising outside maintenance personnel	Recurring, tied to each visit	Frequency of vendor visits, remote sessions and the number of people who must escort or observe them	Agree visit windows in advance, batch maintenance, and record supervision in the same ticket as the work
Vendor maintenance contracts	Recurring, set by the vendor	Service levels, coverage hours and equipment age; these affect schedule and availability rather than the control itself	Ask vendors to confirm their maintenance procedures and personnel checks in writing, and align contract windows with your maintenance schedule
Evidence upkeep	Recurring	Frequency of maintenance events, number of sites, and how many records must be retrieved for an assessment	Keep records in one system with consistent fields so sampling does not require manual reconstruction
External review or readiness assessment	Usually one-time per cycle, sometimes repeated before audits	Maturity of existing records, number of sites in scope and whether gaps were found in prior reviews	Run a readiness check on a sample of maintenance tickets before the audit to avoid rework
Auditor sampling effort	Recurring, once per certification cycle audit	Number of maintenance records the auditor samples and how quickly you can produce them with supporting detail	Fixed records format, linked evidence and a current equipment list reduce time spent on follow-up requests
Labor that open source does not remove	Recurring	Staff who configure, patch and review the tools, and staff who approve and check maintenance work	Assign named owners in the procedure and budget their time explicitly in any quote or internal plan

Which open-source tools produce or support maintenance evidence

A.7.13 is tested through records: schedules, who maintained what, and when. The tools below cover different parts of that trail, from ticketed maintenance work to the hardware inventory that tells you which equipment needs servicing. None of them proves that maintenance was done correctly on its own, so confirm each one fits your workflow before you rely on it as evidence.

GLPI for maintenance tickets and changes

GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. Recurrent tickets can represent scheduled preventive maintenance, and the change records can show approval before work started. Limit: it records what your team entered, so the auditor will still ask whether each ticket matches the physical work performed. Confirm that your maintenance process fits its ticket and change workflow, and review the GPL-3.0-or-later license terms before deployment. Ticket history is the core record.

Zammad for vendor communication

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. If maintenance vendors send service reports, scheduling emails or remote-access requests by email, Zammad can keep that correspondence attached to the relevant ticket. Limit: it stores communication, not proof that equipment was serviced, so it complements a maintenance log rather than replacing one. Confirm that your vendors' channels can be routed into it and review the AGPL-3.0-only license terms before deployment. Keep vendor correspondence with the ticket.

Wazuh Syscollector for hardware inventory

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint and stores them in the Wazuh indexer for inventory views and reports. Inventory snapshots show the OS and patch level a device was running, which helps you test whether maintenance and updates happened as recorded. Limit: it covers endpoints with agents installed, so network devices, appliances and other equipment without agents need a separate record. Confirm agent coverage and review the GPL-2.0-only license terms before deployment. Agent coverage determines the inventory.

Zabbix host inventory for responsibility

Zabbix host inventory stores details such as device type, serial number, location and responsible person, entered manually or populated automatically from agent items such as hardware, OS and installed package data. Recording a named responsible person and a location against each host gives an auditor a way to match maintenance records to a specific asset. Limit: automatic fields depend on agent data, and manually entered fields are only as current as the people who update them, so review them on a set schedule. Confirm that the fields you need are populated and review the AGPL-3.0-only license terms before deployment. Named owners make records traceable.

Who owns maintenance controls, who helps and who certifies

Your organization owns A.7.13. Your team decides which equipment needs planned maintenance, sets the maintenance schedule, decides who is authorized to perform maintenance and how outside personnel are supervised, and keeps the records that show the control operates. An auditor will ask your staff to explain these decisions and will test whether they were followed in practice, so the control cannot be delegated on paper alone.

Schedule ownership: Set maintenance intervals per asset class, based on vendor guidance and the criticality of the information the equipment supports.
Maintainer authorization: Keep a current list of internal and external people allowed to service equipment, with the approver for each.
Supervision rules: Define when an escort or observer is required for outside technicians and who records their presence.
Maintenance records: Log the date, the work performed, the person responsible, the replaced parts and any data handling step for each event.
Removal and return checks: Confirm that equipment leaving for repair is handled under your rules for storage media and that it is checked when it returns.

Before any audit, confirm that a named person owns each of these points and can show a recent sample of records.

Where maintenance controls usually fall short

Most A.7.13 findings come from gaps in records rather than from missing maintenance work itself. The cards below cover the places where schedules, authorizations, supervision and change records drift apart, and the step that closes each gap. Each fix produces evidence an auditor can sample.

No complete asset list

Equipment that is not in the inventory is never scheduled for maintenance, so it is never checked, patched or serviced. An assessor usually finds this by picking a device from the network or a site walk and asking for its maintenance history, which does not exist. Build the list from discovery data and reconcile it against purchase and lease records. Confirm that every maintainable device, including network gear, cameras and building systems that hold or carry information, has an owner and a maintenance interval. For inventory data, Wazuh's Syscollector can gather hardware and software details from endpoints, and Zabbix host inventory can store device type, serial number, location and responsible person.

Vendor technicians without named authorization

Maintenance staff from a vendor often arrive with a work order but no individual authorization tied to the equipment they touch. When an incident follows, nobody can say who had access to the device or why. The assessor's usual finding is a maintenance visit with no record of who attended or what was approved. Require a named technician, the equipment covered, the approved window and the sponsoring employee for every visit. Keep the authorization list with the maintenance schedule so the two can be compared during the audit.

Remote sessions without supervision records

Remote maintenance sessions give outside personnel direct access to systems that may hold confidential information, often through shared accounts or standing tunnels. Without a session record, the organization cannot show that anyone watched the work or that access ended when the job did. Assessors typically ask for logs of a recent remote session and find only a vendor portal entry. Require session approval, a named operator inside the organization who supervises the session, and recorded start and end times. Confirm that the remote access path is logged in the organization's own systems and not only in the vendor's portal.

Repairs without change records

A repair can change firmware, configuration or installed software, and that change can alter security settings without anyone noticing. If the repair bypasses the change process, the post-repair state is unknown and the maintenance record shows only that a visit took place. Assessors compare the device configuration before and after a repair and look for a linked change ticket. Route every repair that alters firmware or configuration through the change process, and record the version and configuration baseline before and after the work. GLPI's Assistance module supports tickets, problems and changes that follow ITIL practices.

Schedules never reviewed against completed work

Many organizations write a maintenance schedule once and never compare it with what was actually done. Overdue items accumulate, and the schedule describes an intention rather than a control that operates. An assessor will pick a scheduled item and check whether the completed work matches the planned date and scope. Set a recurring review that compares the schedule with completed tickets, records every overdue item with a reason and a new date, and signs off the result. Keep the review record as evidence that the control is monitored.

Records split across inboxes and portals

Maintenance evidence often sits in email threads, personal folders and each vendor's portal, so no single source answers an assessor's question. The organization may hold the right records but cannot retrieve them within a reasonable time, and gaps look like failures. Choose one system of record for maintenance tickets, store vendor reports there, and set retention rules for them. Zammad can bring communication from email and other channels into one ticket system, which helps when vendor correspondence is part of the record.

Questions buyers ask about A.7.13 cost, effort and outsourcing

How much effort does meeting A.7.13 equipment maintenance take?

The effort depends mainly on how many devices are in scope, how many different maintenance paths exist, and how much of the maintenance history is already written down. A small office with a handful of laptops and one managed service provider needs a short, clear procedure and a record of each visit. A data center with servers, storage arrays, cooling and power equipment, several maintenance contracts and remote vendor access needs a schedule for each asset class, approval steps for changes and a way to show what was done. Cost comes from two places: the time your staff spend defining the process and collecting records, and any external help you buy. Ask any quote to break the effort down by asset class, by site and by the number of maintenance providers involved.

Can a small team run A.7.13 in-house?

Yes, in many cases a small team can run A.7.13 in-house, provided the scope is limited and the process is simple. The control asks that equipment is maintained correctly, so the team needs a maintenance schedule, a list of who is allowed to perform maintenance, and records of what was done. A small team can keep these in a ticketing or inventory tool and review them at a regular interval. The harder part is consistency: someone must own the schedule, chase missed visits and keep records current when staff change. If no one has time for that role, the gap is usually ownership rather than tooling.

What does A.7.13 require from internal staff?

Three internal roles usually carry the control. Asset owners identify the equipment they are responsible for, state its maintenance needs and confirm when work is complete. An approver, often the IT manager or facilities lead, authorizes maintenance windows, outside visits and changes that could affect information availability or confidentiality. A process owner keeps the schedule, the list of authorized maintainers and the maintenance records in order, and reports gaps to management. In a small organization one person may hold two roles, but the approvals and records should still be traceable to named people. Document these roles in your Statement of Applicability and in the procedure itself so an assessor can see who does what.

Can an implementation partner build the A.7.13 workflow and evidence without signing off compliance?

Yes. An implementation partner can design the maintenance workflow, configure the ticketing and inventory tools, set up schedules and reporting, and prepare the records an assessor will ask to see. DeployOpen, for example, plans and implements self-hosted open-source platforms inside your own infrastructure and prepares systems, controls and evidence for assessments. It does not issue audit reports or certificates. Your organization still owns the control, approves the procedure, decides which maintainers are authorized and attests to its own practice. Only an independent certification body can certify your ISMS. Agree in writing which parts the partner delivers and which remain with your staff.

Will the auditor sample maintenance records, and how far back do they look?

An auditor usually samples records rather than reviewing every visit, and the sample is chosen to test whether the process works in practice. Expect them to pick a selection of assets and ask for the schedule, the approval for each maintenance event, evidence of the maintainer's authorization, and the record of what was done. The period covered depends on the audit plan and on how long your records have existed, so the control should be operating well before the assessment starts. Ask your certification body for its sampling approach and confirm the look-back period with them. Do not assume a fixed number of months or years without that confirmation.

How do we ask a partner for a fixed-scope quote for A.7.13?

Ask for a written, fixed-scope proposal that starts from the scope you define. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and it does not publish a price list, so the quote follows from that scope. Your request should list the sites, the asset classes in scope, the number of maintenance providers and whether remote vendor access is involved. Ask the partner to state which tools will be configured, what evidence each deliverable produces, what your staff must provide and how changes to scope are handled. Compare proposals on those items rather than on headline figures alone.

How DeployOpen prepares maintenance controls and evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so maintenance records, schedules and approvals for A.7.13 Equipment maintenance can come from the systems that actually run your environment. Your organization still owns the control, and an independent auditor or certification body is the only party that issues a certificate.

How we scope

Agree in writing which equipment, sites and platforms fall inside the A.7.13 Equipment maintenance scope.
Define who may authorize maintenance, who performs it and which outside maintainers need supervision.
Confirm the maintenance schedule, the records to keep and the tools that will hold them before work starts.

How we build

Deploy a helpdesk or service management platform to route maintenance requests, approvals and change tickets.
Configure asset inventory so each device has a recorded serial number, location and responsible person.
Set up logging of maintenance activity so completed work can be traced back to an approved request.

How we hand over

Document the maintenance procedure, roles and escalation paths in a form your Statement of Applicability can reference.
Provide sample records and exports that show schedules, approvals and completed maintenance for your auditor.
Train your staff on running the tools and keeping records so the control continues after the engagement ends.

How we support

Offer ongoing support, upgrades and testing of the maintenance tooling as a retainer if your organization wants it.
Review maintenance records periodically so gaps in schedules or supervision are caught before an audit.
Confirm with your auditor which evidence formats they accept for A.7.13 Equipment maintenance before finalizing the records.