Control Definition
The organization must maintain equipment correctly so that the availability, integrity, and confidentiality of the information it processes and stores are preserved — in practice, servicing at supplier-recommended intervals, allowing only authorized personnel to perform repairs, keeping records of all work, and protecting stored information whenever equipment is serviced on or off site.
Control Objective
To prevent the loss, damage, or compromise of information — and the interruption of operations — that result from equipment failing or being serviced insecurely.
What This Really Means
Two different risks share this one control, and most organizations manage only the first. Risk one is the obvious one: unmaintained equipment fails. Dead UPS batteries, clogged server-room cooling, worn drives — an availability problem whose cure is a service schedule. Risk two is the one that gets missed: maintenance itself is a security event. A third-party technician with hands on your hardware, a server leaving the building with disks full of production data, a vendor loaner joining your network while your device is in the shop — every maintenance interaction moves equipment, people, or data across your trust boundary.
On the first risk, the control asks for a maintenance program: know which equipment needs servicing (start from the asset register), at what intervals (supplier recommendations are the reference point, alongside warranty and insurer terms), and performed by whom — authorized internal staff or approved vendors only. Every piece of work gets recorded: suspected faults, actual faults, preventive servicing, corrective repairs. That log is both your audit evidence and your early-warning system for equipment that should be replaced rather than repaired again.
On the second risk, the discipline is about custody. Before equipment leaves site for repair, its stored information is removed, sanitized, or protected — full-disk encryption plus a vendor contract with confidentiality obligations is the common pattern. On-site technicians are verified against a scheduled work order, signed in, escorted in secure areas, and their work is logged. Loaner devices are treated as untrusted hardware until imaged and enrolled. And anything that was serviced gets checked before returning to service: no tampering, configuration intact, functioning correctly.
Cloud changes the shape of this control without removing it. Physical maintenance of data-center hardware belongs to the provider, and your evidence is the contract plus their certifications. Your offices, endpoint fleet, network gear, UPS, and meeting-room equipment remain yours. Auditors treat two things as the heart of A.7.13: the maintenance log for resilience-critical equipment, and the leaves-site flow — show the service history of your UPS, and show exactly what happened the last time a device with storage went out for repair.
Why It Matters
Maintenance failures masquerade as IT incidents. The UPS that died during a power cut had batteries that were never tested; the storage array that cooked itself sat behind a cooling unit whose filters were never changed. Outage post-mortems routinely trace back to a service schedule that did not exist — and at that point the warranty and insurance questions begin, because unauthorized or absent servicing voids support contracts and gives insurers grounds to contest a claim.
The quieter problem is that the repair channel is a data-leak path that bypasses everything. The drive inside a returned server, the disk in a photocopier at end of lease, the technician working alone in the server room — these flows rarely appear on anyone's data-flow diagram, which is exactly why they leak. An organization that encrypts laptops and locks its racks but ships readable disks to an unvetted repair vendor has simply chosen a slower way to lose the same data.
Failure here typically shows up as:
- •Preventable outages – dead UPS batteries, failed cooling, and worn components take systems down in ways a service schedule would have caught
- •Data leaving with the device – equipment sent for repair with storage intact hands your information to whoever services it next
- •Unsupervised technician access – maintenance engineers get deeper physical access than almost any visitor; unverified and unescorted, that access is unmanaged
- •Tampering on return – equipment serviced off site can come back altered, and without a return-to-service check nobody would notice
- •Void warranties and denied claims – unauthorized servicing voids support agreements and gives insurers a reason to dispute a loss
Regional Compliance Context
India. The repair channel deserves explicit treatment in Indian operations, where out-of-warranty devices commonly go to local third-party repair shops rather than manufacturer service centers. If a device holding personal data leaks through that channel, it is a personal data breach under the DPDP Act 2023 — notifiable to the Data Protection Board and affected data principals — and a qualifying incident on India-connected systems falls within CERT-In's 6-hour reporting window. Fleet-wide disk encryption plus a mandatory remove-or-sanitize step before any device leaves site converts most of that exposure into routine paperwork. RBI-regulated entities should also expect scrutiny of vendor access arrangements for equipment servicing under their outsourcing and IT governance obligations.
Implementation Guidance
Build the Maintenance Inventory from the Asset Register
Identify everything that needs maintenance, working from the A.5.9 asset inventory: servers and storage, network equipment, UPS and generators, server-room cooling, fire suppression, printers and multifunction devices, and the endpoint fleet. Record per asset class the supplier-recommended service interval, warranty and support terms, and any insurer-imposed requirements. Assign an owner per category — the seam between IT and facilities is where assets fall through.
Schedule Preventive Maintenance and Track Completion
Turn the inventory into a calendar: UPS battery tests, generator runs, cooling service, filter changes, firmware-level servicing where applicable. Run it from a CMMS or recurring tickets in the IT service desk — the tool matters less than the completion record. Review the schedule annually and whenever equipment changes.
Authorize Who May Service What
Define which internal roles and which vendors are authorized to maintain each equipment class, and route repairs only through them. Keep an approved-maintainer list, and put confidentiality and information-handling clauses into every maintenance contract (this is where A.5.20 does the legal work). Unauthorized repair is both a security exposure and a warranty problem.
Supervise On-Site Maintenance Visits
Verify technicians against a scheduled work order before granting access, sign them in as visitors, escort them in secure areas (A.7.6 conduct rules apply), and restrict access to the equipment under service. Log the visit: who came, when, which equipment, what was done. Brief reception and facilities staff — the unannounced "engineer" is a classic social-engineering pretext.
Protect Data Before Equipment Leaves Site
Make the service desk the gate: no device with storage leaves for repair until a recorded decision is made — remove the storage, sanitize it, or rely on verified full-disk encryption plus a vendor contract carrying confidentiality and handling obligations. Record the decision on the repair ticket. Treat incoming loaner devices as untrusted: reimage or enroll them before use, sanitize them before return.
Keep Maintenance Records as a Living Log
Record all suspected and actual faults and all preventive and corrective work, whoever performs it — internal staff, facilities contractors, or vendors. Attach vendor work orders and service reports to the same ticket trail. The log is primary audit evidence, and its failure-trend data should feed refresh and capacity decisions before equipment fails a third time.
Check Equipment Before It Returns to Service
Define a return-to-service step for anything repaired or serviced off site: physical inspection for tampering, configuration verified against the baseline (A.8.9 makes this checkable), malware scan where applicable, and a function test. Record the check on the same ticket. Apply the identical step when a loaner is swapped back out of service.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.7.13:
Documentation
- Maintenance procedure covering schedules, authorized maintainers, and data protection during servicing
- Maintenance schedule with completion records for resilience-critical equipment — UPS, generators, cooling, fire suppression
- Fault and service log showing preventive and corrective work, with dates and personnel
- Approved maintenance vendor list and contracts containing confidentiality and handling clauses
- Repair tickets evidencing the remove-sanitize-or-encrypt decision before devices left site, plus return-to-service checks
Interviews
- IT or facilities manager on service schedules, vendor authorization, and how completion is tracked
- Service desk staff on what happens, step by step, when a laptop or server needs repair — especially the data-protection step
- A staff member who recently hosted a maintenance visit, on technician verification, escorting, and logging
Observations
- Service labels and records inspected against the physical UPS, cooling, and fire-suppression units in the equipment room
- A recent repair traced end to end in the ticket system — fault, data decision, vendor, return-to-service check
- Visitor and escort records cross-checked against logged maintenance visits
Practitioner Insights
When an availability incident comes up in an audit, the maintenance log is the first record auditors reach for — and a failed UPS with no battery-test history converts an equipment failure into a management-system failure, which is a much worse finding. The second thing they probe is outsourced maintenance, because organizations delegate the work but not the accountability: show me the contract's confidentiality clause, show me who escorted the engineer, show me the return check. Keep the maintenance trail with the same discipline as the access log; it carries the same evidentiary weight.
Startups tell me they have nothing to maintain because everything is in the cloud — and then a developer's laptop dies and goes to a neighborhood repair shop with an unencrypted disk holding two years of code and customer exports. The control they were missing was not a CMMS; it was full-disk encryption plus a one-page rule: any device leaving site gets its storage removed, wiped, or verifiably encrypted, and the decision goes on the ticket. For a small company, that rule, the encryption report from MDM, and a handful of tickets are usually enough to satisfy this control without ceremony.
Common Challenges & Solutions
Challenge
Preventive maintenance is endlessly deferred because nothing is visibly broken and there is no budget line for it.
Solution
Anchor it to the risk register: the cost of an annual UPS battery service set against the cost of an unplanned site outage makes its own case. Create recurring tickets so deferral becomes a visible, recorded decision instead of a silent lapse, and report schedule completion to management review. Once skipping maintenance requires someone to own the deferral in writing, it mostly stops happening.
Challenge
Maintenance visits happen ad hoc — engineers turn up, are let in by whoever is at the door, and leave no trace.
Solution
Require a work order and a named technician for every visit, brief reception against unannounced engineers, and run visits through the standard visitor process: identity check, sign-in, escort, sign-out. Log which equipment was touched. The discipline matters double here because the maintenance-engineer pretext is a staple of physical penetration tests — and of real intrusions.
Challenge
Devices are sent for repair with data on them because nobody owns that decision at the moment it happens.
Solution
Put the decision into the repair workflow itself: a mandatory ticket field — storage removed, sanitized, or encrypted-plus-contract — that must be completed before shipment is booked. Roll out full-disk encryption fleet-wide so the safe answer is also the default answer. Back it with vendor agreements that carry confidentiality and media-handling clauses for anything serviced off site.
Challenge
Records are scattered: IT keeps tickets, facilities keeps a paper logbook, vendors keep their own service reports, and nobody can produce a coherent history.
Solution
Consolidate to one system of record — the IT ticket queue or a CMMS — and require vendor work orders and facilities jobs to be logged or attached there. Reconcile vendor invoices against logged visits periodically; invoices are a surprisingly effective completeness check. One searchable history per asset is what the auditor, and your own incident investigations, will ask for.
Challenge
Loaner and swap devices supplied by vendors join the network with unknown software and an unknown history.
Solution
Treat loaners as untrusted by default: reimage with your standard build or enroll in MDM before they touch production networks, and isolate them to a guest segment if neither is possible. On return, sanitize the loaner and record it on the same ticket as the repair. Those two records — hardened on arrival, sanitized on departure — close a loop most organizations never noticed was open.
