ISO 27001 Annex A 7.13: equipment maintenance that survives audit

The due-diligence questionnaire asks when your UPS batteries were last replaced and who escorted the engineer who serviced them. Nobody can say, and the certification date slips. This guide to ISO 27001 Annex A 7.13 is for UK regulated service providers and B2B SaaS firms: what the control asks for, how to scope it when you run in the cloud, and the evidence an auditor will read.

It is written for security managers and IT leads who need a working programme in days, not a policy library. You will leave with a short in-scope list, a supervision routine, a remote-access pattern and a way to let your service desk produce the evidence.

What does ISO 27001 equipment maintenance require under Annex A 7.13?

ISO 27001 Annex A 7.13 requires equipment to be maintained so it keeps its security promises, and requires that maintenance itself be controlled. It has two faces: reliability, meaning serviced kit and supporting plant on a schedule with records; and trust, meaning authorised, supervised maintainers, controlled remote access and inspected returns.

The control treats maintenance as a security-sensitive moment, not housekeeping. The engineer with a screwdriver inside your rack can see what is stored there and could alter what runs. Neglect does the same damage more quietly, through the plant nobody owns.

Each face breaks into practices that later sections take in turn:

• Reliability: service kit to the manufacturer's schedule, log faults and fixes, and include the supporting plant: UPS batteries, cooling, alarms and fire suppression.
• Trust: allow only authorised maintainers, supervise them on site, authenticate remote sessions and inspect returned devices before they go back to work.

The control is preventive. Planned servicing heads off failure, and the controls around maintainers head off compromise, so neither waits for damage to show. All three security properties are in play: availability for kit that dies from neglect, confidentiality for what a technician can see or take, and integrity for what they could alter or implant.

Two neighbours share the border. Equipment leaving for repair also falls under Annex A 7.9 on off-site assets, and equipment that maintenance condemns exits through Annex A 7.14 on secure disposal. Auditors use ISO 27001 Annex A equipment maintenance as a quick probe of operational ownership: either someone can produce the service schedule or nobody can.

How do you scope ISO 27001 Annex A 7.13 in a cloud-first firm or serviced office?

A cloud-first firm still maintains a short, mostly non-IT list: UPS units and batteries, comms-room cooling, alarms and detectors, extinguishers, office network kit and laptops under warranty. Your cloud provider maintains its data centres, not your comms cupboard. In serviced offices, map which plant the landlord maintains and hold their evidence on file.

Cloud hosting shrinks the list rather than deleting it. A warranty laptop, the switch in the comms cupboard and the extinguisher by the door still age, fail and need a record. The failures that hurt are unglamorous: cooling that cooked the comms room over a bank holiday, or a UPS whose ageing batteries lasted seconds into an outage. "We never maintained it" is a poor sentence in a post-incident report.

For a firm of around 50 people, the inventory usually reads like this:

• UPS units and batteries, serviced to the manufacturer's interval.
• Comms-room or cupboard cooling, which tends to fail quietly.
• Alarms and detectors covering intruder, fire and environmental events.
• Extinguishers and any suppression system, each with a dated service sticker.
• Office network kit such as switches, firewalls and access points.
• Laptops under warranty or repair arrangements, plus any on-premises kit that survives.

Put each item on a schedule driven by the manufacturer's guidance and by how much it would hurt if it failed. Then read your insurance schedule: insurers write maintenance conditions into policies, usually for fire systems and electrical inspection, and claims teams check them. Fold those dates into the same calendar.

This control is about physical equipment and the people who touch it. Software patching and vulnerability management sit in other Annex A controls, so keep them off this calendar and it stays short.

The landlord split is usually clean: the building's systems are theirs, while the UPS under your rack and your own alarm contract are yours. Map it once and file their maintenance confirmations, because their servicing counts for you only if you hold the evidence.

Start the list with the plant, because the servers depend on it.

How should you manage engineers who visit to service your equipment?

Treat every visiting engineer as a physical access event. Use named, authorised suppliers with contracts and NDAs in place before the first visit, sign engineers in, escort and supervise them near racks, patch panels and stored records, and inspect the equipment afterwards for interference. Supervision is not rudeness; it is the control.

Engineer visits borrow the visitor process you already run for physical entry under Annex A 7.2, with extra care near racks and records. Because servicing is scheduled, every visit can be planned and recorded in advance.

An engineer left alone in the server room is an access-control bypass in a hi-vis vest.

A workable routine for each visit:

1. Authorise the supplier. A named company with a contract and NDA on file before the first visit, not after.
2. Raise the visit as a ticket. Name the engineer, the task and the areas they will enter.
3. Sign them in. Use the visitor book or system that reception already runs.
4. Escort and supervise. Stay with them near racks, patch panels and stored records.
5. Inspect afterwards. Does the kit behave normally, does the configuration match, are there signs of interference?
6. Record the result. A two-line inspection note, signed, before the device returns to work.

Escorting feels rude to some teams, so engineers wander unescorted and a service visit turns into an access finding. Give reception a standard line that the rule applies to every visitor. Repaired kit plugged straight back into production has the same flaw: tampering or misconfiguration then surfaces through an incident rather than a checklist.

How do you secure remote maintenance sessions and off-site repairs?

Keep vendor remote access closed by default and open it per session with approval, MFA, least privilege, a defined window and a session log. Before data-bearing hardware leaves for repair, back it up, confirm full-disk encryption or pull the drive, and ship it tracked with a chain-of-custody note.

Remote maintenance sessions

A standing, always-on vendor tunnel is the classic quiet hole in an otherwise tidy estate. NIST SP 800-53 Rev. 5 Control MA-4 (Nonlocal Maintenance) expects remote maintenance to be approved and monitored, with strong authentication, detailed records and termination when the session ends. The NCSC Guidance on Third-Party Risks to Operational Technology adds that a third party should reach only the assets specified, and warns that connectivity you have not mapped, such as undisclosed out-of-band channels, can leave you carrying substantial unmanaged risk.

A session runs in five steps:

1. Request. Raise a ticket with the vendor, the reason and an end time.
2. Approve. A named internal owner approves, and only then is the account enabled.
3. Authenticate. Use a named account with MFA, never a shared login, scoped to the specified assets.
4. Record. Log the session and attach the log to the ticket.
5. Close. Disable the account at the end time, or sooner when the work finishes.

Shared accounts, missing MFA and sessions nobody logs or reviews are the usual failure pattern. Each step above removes one of them, and the ticket keeps the proof.

Off-site repairs

Data-bearing kit crosses the Annex A 7.9 boundary the moment it leaves. The NCSC Guidance on Secure Sanitisation and Disposal of Storage Media names returning a faulty device to the vendor for repair as one of the moments its sanitisation advice applies. It also notes that on devices encrypted with BitLocker or FileVault, deleting the keys makes the data unreadable.

Run this checklist before dispatch:

• Back up the data to a location the repair cannot touch.
• Protect the drive. Pull it, or confirm full-disk encryption such as BitLocker or FileVault is active and the key is not travelling with the device.
• Paper the repairer. Agree an NDA with the repair shop before the parcel goes.
• Ship tracked with a chain-of-custody note naming sender, courier and recipient.
• Inspect on return using the post-repair check from the engineers section.

A laptop shipped with a cleartext disk is a data breach in waiting. If the data is sensitive and none of the protections are possible, a new drive and a destroyed old one is often the economical answer.

Do you need a formal maintenance policy document for A.7.13?

No. At this scale, a maintenance schedule, a simple log and a line in your Statement of Applicability or IT procedures stating who maintains what is a complete answer. Auditors ask for evidence of servicing, not a freestanding policy document, so spend the effort on the calendar and the log.

Standing the programme up takes a day or two: inventory, calendar and supplier paperwork. After that it runs on its own rhythm. Build it alongside the rest of the physical family, once the physical security perimeters under Annex A 7.1 are defined.

The minimum set is four things:

• An owner. One named person answers the auditor's first question.
• A calendar. Recurring tickets or diary entries per item.
• A log. Date, what was found, what was replaced, and who signed it back into service.
• A line in the SoA or IT procedures saying who maintains what.

A maintenance programme with no log isn't a control. It's an assertion.

Work that happens with nothing written down becomes a shrug at audit and a "the IT guy handles it". Write the log entry when the engineer leaves, while the details are fresh. A few minutes per job is the whole cost.

What does an A.7.13 audit evidence pack contain?

The evidence pack centres on the maintenance log and the schedule it executes, backed by service-desk work orders, visitor and escort records, supplier NDAs and contracts, physical service stickers on extinguishers and UPS units, remote-session authorisations and logs, and custody notes with tracked-shipping records for off-site repairs.

Each artefact proves one thing:

• Maintenance log and schedule prove servicing was planned and happened: dates, faults, parts and sign-off per asset, against manufacturer-recommended intervals.
• Service-desk work orders show hardware jobs from request to close.
• Visitor and escort records show who attended and who accompanied them.
• Supplier NDAs and contracts show the maintainer was authorised before the first visit.
• Service stickers on extinguishers and UPS units show the last service date on the asset itself.
• Remote-session authorisations and logs show who opened access, for how long, and who closed it.
• Custody notes, tracked-shipping records and the return inspection note show what protected an off-site repair.
• Landlord confirmations cover the plant that is not yours.

Assemble the pack per asset, not per document type. For the UPS, hold the schedule line, the last log entry, the ticket and a photo of the sticker together, so a single trace answers the auditor's first question.

What will an auditor ask about equipment maintenance, and how is it graded?

Auditors trace a couple of assets from schedule to log to sticker, cross-check one engineer visit against the visitor book and supplier contract, and probe remote routes for MFA and session records. Under certification-body norms, a missing programme or a standing unauthenticated remote channel grades major; lapsed servicing, a missing NDA or an uninspected return grades minor.

Questions to expect in the room:

• "What is on your maintenance schedule, and who owns it?"
• "When were the UPS batteries last replaced, and what does the manufacturer say the interval should be?"
• "Walk me through the last engineer visit: who authorised it, who escorted them, where is the NDA?"
• "How does your hardware vendor get remote access, and what closes it again afterwards?"
• "This laptop went for repair in May. Show me what protected the data on it."

On the walk-round the auditor physically reads the extinguisher and UPS tags, so out-of-date stickers surface fast. The follow-through question is a favourite: a fault logged in March, with no entry showing it was fixed.

A fault logged but never closed out is an audit finding waiting for its question.

Unsupervised third-party access to areas holding sensitive data also grades major, because it is the absence of the requirement rather than a lapse in it. Minor lapses aggregate to major when they form a pattern, so remove the pattern rather than patching single records.

Run the trace yourself a month before the audit: two assets, one engineer visit, one remote route, one repair. Every gap you find is a finding you did not receive.

How do you automate A.7.13 evidence with service-desk tickets and telemetry?

Turn the control into workflow: recurring service-desk tickets replace the diary, comms-room sensors and UPS self-tests raise tickets before outages, vendor accounts expire by design, and off-site repair tickets refuse to close without backup, encryption and return-inspection evidence. The closed ticket becomes the log entry, so evidence accrues as the work happens.

Four mappings do the work:

• Schedule as recurring tickets. Each maintainable asset carries recurring service tickets in the service desk. Overdue services surface on a dashboard instead of in an audit.
• Telemetry as early warning. Cheap temperature and humidity sensors in the comms room, UPS self-test results and device health alerts feed your monitoring. Degradation becomes a ticket before it becomes an outage.
• Vendor access that expires. Remote-maintenance accounts stay disabled until an approval workflow enables them with an end time. The approval and the session log land in the same ticket.
• Repair custody as workflow. An off-site repair ticket asks for backup confirmation, an encryption check, tracking references and the return inspection before it will close.

The human layer shrinks to judgement: who approves a vendor window, whether a battery reading justifies early replacement, what the inspection note says. Everything else is routine the service desk runs.

At this scale, one dashboard answers both the auditor and the enterprise customer's security questionnaire, so evidence stops being a scramble before each review.

Frequently asked questions