Annex A 7.13: Equipment Maintenance

To meet the annex a 7.13: equipment maintenance requirement, you must maintain equipment on a defined schedule, using authorized procedures and controlled third parties, and retain evidence that maintenance protects information security (for example, secure handling of storage media and configuration changes). Operationalize it by inventorying in-scope equipment, defining maintenance triggers, and running a documented, ticketed maintenance workflow.

Key takeaways:

• Define “equipment maintenance” as a security control, not just an IT ops activity, and assign an owner with a repeatable cadence.
• Control maintenance access and data exposure: approved tools, vetted third parties, secure transport, and media handling.
• Keep an audit-ready evidence bundle: schedule, tickets, approvals, logs, and closure records tied to specific assets.

Annex A 7.13 focuses on a simple exam question: “Can you prove that equipment is maintained in a way that prevents security failures and protects information?” The control is broader than patching. It covers preventive maintenance, break/fix work, calibration, firmware updates, parts replacement, and any service activity that could expose data or change a system’s security state.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a requirement-level workflow with clear triggers and evidence. Auditors rarely accept “IT handles maintenance” without a schedule, ownership, and traceability to assets. They also look for the security edge cases: maintenance performed by third parties, devices leaving your facilities, temporary admin access, and removed storage components.

This page gives you a practical runbook: who it applies to, what to do step-by-step, what artifacts to retain, and how to avoid common failures. It also includes an execution plan you can run with your IT and Facilities owners without rewriting your entire ISMS. Source references are limited to the public ISO overview and a public Annex A index summary. ¹

Regulatory text

Control statement (provided excerpt): “ISO/IEC 27001:2022 Annex A control 7.13 implementation expectation (Equipment Maintenance).” ¹

What the operator must do (requirement interpretation):
You must implement and operate a maintenance program for equipment that could affect the confidentiality, integrity, or availability of information. The program must be planned (not ad hoc), executed by authorized personnel or approved third parties, and performed in a way that prevents data exposure, unauthorized configuration changes, and loss of asset control. ¹

Plain-English interpretation

If equipment fails or is serviced incorrectly, security fails. Annex A 7.13 expects you to:

• Maintain equipment predictably (preventive and corrective maintenance).
• Control who performs maintenance and how access is granted.
• Protect data during maintenance (especially when devices are transported, serviced offsite, or have storage removed).
• Capture records so you can prove maintenance happened and issues were closed.

Think of this as “change control + physical/asset control + service management,” applied specifically to maintaining equipment.

Who it applies to

Entity scope

• Service organizations seeking ISO/IEC 27001:2022 alignment or certification. ²

Operational scope (what “equipment” usually means)

Include any equipment that stores, processes, transmits, or supports information services, such as:

• End-user devices (laptops, desktops) used for production access.
• Servers, network devices, firewalls, storage arrays, backup appliances.
• Specialized devices (OT/IoT where in scope), conference room systems if they store credentials or recordings.
• Power/cooling and environmental equipment where failure impacts availability (data center or comms rooms).
• Security tooling appliances and HSMs where maintenance could change trust boundaries.

Exclude truly out-of-scope items only if your ISMS scope statement and asset inventory support the exclusion.

What you actually need to do (step-by-step)

Step 1: Define ownership, boundaries, and triggers

Create a control card (one page) that states:

• Owner: typically IT Operations, Infrastructure, or Facilities for physical plant; GRC owns oversight.
• In-scope equipment classes: tie to asset categories in your inventory/CMDB.
• Triggers: preventive schedule, manufacturer recommendations, break/fix incidents, end-of-life notices, security advisories that require firmware updates, post-incident corrective actions.
• Exception rules: what happens for emergency maintenance, and who can approve retroactively.

Practical tip: if ownership is split (IT vs Facilities), define a single accountable owner and list contributing teams.

Step 2: Build a maintenance standard that includes security conditions

Write a short “Equipment Maintenance Standard” with:

• Pre-maintenance checks: confirm asset ID, location, and maintenance reason; verify backup state for critical systems.
• Access controls: least privilege accounts for maintenance; time-bounded access; MFA where applicable; no shared credentials.
• Approved tools and methods: prohibit unapproved diagnostics that copy data indiscriminately.
• Media handling: rules for removing drives, replacing disks, and protecting or wiping storage components.
• Configuration integrity: require post-maintenance validation (baseline checks, monitoring restored, logging enabled).
• Third-party maintenance: only approved third parties; require ticket reference; define escort requirements and chain-of-custody when equipment leaves your control.

Keep it operational. Policies won’t pass an audit if technicians can’t follow them.

Step 3: Implement a ticketed workflow (the “system of record”)

Run maintenance through a system that produces immutable-ish records (ITSM, work order system, or equivalent):

1. Create maintenance ticket/work order linked to the asset ID.
2. Risk screen (simple): does this touch storage, credentials, or perimeter devices? If yes, require additional approvals.
3. Approve per your change/maintenance rules (normal vs emergency).
4. Execute maintenance with required checklists.
5. Record outputs: replaced parts, firmware versions, config diffs, test results.
6. Close with validation: service restored, monitoring/EDR present, logs flowing, access removed.

If you do not have ITSM maturity, start with a controlled template and a central repository. Auditors care about traceability more than tooling brand.

Step 4: Control third-party maintenance like a third-party risk scenario

Maintenance providers can become a direct path to data exposure. Minimum operational controls:

• Maintain an approved third-party list for maintenance services.
• Confirm contract terms cover confidentiality and handling of data-bearing components.
• Require access provisioning through normal identity processes (no “vendor admin” shared accounts).
• For onsite work: log arrival/departure, scope of work, and escort requirements for restricted areas.
• For offsite repairs: document chain-of-custody, shipping method, tamper controls, and return verification.

Daydream note (earned mention): if your third-party due diligence process lives separately from IT maintenance, Daydream can centralize control ownership, evidence bundles, and recurring health checks so you can answer audits without stitching together emails and tickets.

Step 5: Run recurring control health checks

A 7.13 control that “exists” but can’t show ongoing operation is fragile. Build a lightweight review:

• Sample recently closed maintenance tickets and confirm required fields and approvals.
• Confirm overdue preventive maintenance is tracked and risk accepted where needed.
• Review exceptions/emergency maintenance and verify retroactive approvals and validation.
• Track findings to closure with named owners.

This is where many teams fail: maintenance is happening, but the control is not provable.

Required evidence and artifacts to retain

Keep an “evidence bundle” that an auditor can trace end-to-end. Minimum artifacts:

• Equipment Maintenance Standard (current, approved version).
• Maintenance schedule or defined triggers by equipment class (manufacturer guidance references if you keep them internally).
• Asset inventory/CMDB extract showing in-scope equipment categories and asset IDs.
• Tickets/work orders showing request, approval, execution notes, and closure validation.
• Access records for maintenance sessions (who had access, when it was granted and removed).
• Third-party records: approved provider list, statements of work, site logs, chain-of-custody for shipped devices.
• Exception log: emergency maintenance, deferred maintenance, risk acceptances with approver.
• Control health check reports and remediation tracking.

Retention period should align to your ISMS documentation retention rules and audit cycle; keep it consistent and documented.

Common exam/audit questions and hangups

Auditors and customer diligence teams tend to ask:

• “Show me your maintenance procedure and how technicians follow it.”
• “How do you know maintenance was performed for critical equipment?”
• “How do you prevent data exposure when devices are serviced offsite?”
• “What happens when you replace a failed drive?”
• “How do you ensure maintenance access is removed after service?”
• “How do you handle emergency maintenance and document approvals?”

Hangups that slow audits:

• Preventive maintenance exists informally but has no schedule, owner, or completion evidence.
• Tickets don’t reference asset IDs, so you can’t tie activity to equipment.
• Third-party maintenance occurs via email/text with no controlled record.
• No proof that security posture was revalidated after service (monitoring/logging/EDR gaps).

Frequent implementation mistakes (and how to avoid them)

1. Treating maintenance as “facilities-only” or “IT-only.”
   Fix: define equipment classes and shared responsibilities; one accountable owner.

2. No secure handling rules for data-bearing components.
   Fix: add explicit steps for drive replacement, return-to-vendor, wiping, and custody.

3. Emergency maintenance bypasses records.
   Fix: allow expedited execution, but require retroactive documentation and approval.

4. Third-party technicians get unmanaged admin access.
   Fix: provision named accounts, time-box access, and require ticket linkage.

5. Evidence is scattered across tools and inboxes.
   Fix: define a minimum evidence bundle and a single retention location mapped to the control.

Enforcement context and risk implications

ISO/IEC 27001 is a certifiable standard, not a regulator. The practical enforcement mechanism is certification audits and customer contractual requirements tied to ISO alignment. If you cannot demonstrate controlled equipment maintenance, the risk shows up as:

• Audit nonconformities tied to operational control weakness.
• Increased likelihood of outages, misconfigurations, or data exposure during service events.
• Third-party risk escalation where maintenance providers have physical or logical access to sensitive systems. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and make it auditable)

• Assign a control owner and publish a one-page control card.
• Define in-scope equipment classes and map to asset inventory categories.
• Draft the Equipment Maintenance Standard with security conditions (media handling, access, validation).
• Choose the system of record for maintenance tickets and require asset IDs going forward.

Days 31–60 (operate the workflow and close obvious gaps)

• Start logging all maintenance through tickets/work orders.
• Stand up the approved third-party maintenance list and minimum engagement rules.
• Create checklists for high-risk equipment (perimeter, storage, authentication infrastructure).
• Run the first control health check and open remediation items with owners.

Days 61–90 (prove consistency)

• Expand preventive maintenance scheduling across critical equipment classes.
• Add chain-of-custody workflow for offsite repairs and shipped devices.
• Perform a second health check; trend recurring issues and update procedures.
• Package the evidence bundle for audit: policy/standard + schedule + sampled tickets + exception log + third-party records.

Frequently Asked Questions

Does Annex A 7.13 only apply to IT hardware, or also to facilities equipment?

It applies to equipment that can impact information security outcomes, including availability. If HVAC/power failures can take down in-scope systems, include the relevant maintenance controls in scope.

We outsource hardware break/fix. What do we need beyond the contract?

You need operational controls: approved third party list, controlled access, ticket traceability, and chain-of-custody for devices or media that leave your control.

Do we need a formal preventive maintenance schedule for every device?

You need defined triggers and a predictable approach for in-scope equipment classes. For lower-risk endpoints, you can define maintenance through standard lifecycle practices, but keep it documented and provable.

What evidence is strongest in an ISO audit for equipment maintenance?

Asset-linked maintenance tickets with approvals, execution notes, and validation checks, plus a written standard that matches how work is done in practice.

How do we handle emergency maintenance without failing audit expectations?

Allow emergency execution but require after-the-fact documentation: the reason, who authorized it, what changed, and evidence that access was removed and controls were revalidated.

We don’t have a CMDB. Can we still pass?

Yes, if you can uniquely identify in-scope equipment and link maintenance records to those identifiers. Many teams start with an asset register spreadsheet and tighten it over time.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview