IT Compliance and Hardware Monitoring: What Auditors Actually Look For

ISO 27001, SOC 2, NIS2, and GDPR all require evidence of hardware asset management and system monitoring. Most organizations running these audits scramble to produce documentation retroactively — pulling screenshots, chasing records, reconstructing timelines. Continuous hardware monitoring solves this by generating the evidence automatically: every sensor reading is timestamped, every alert is logged, every asset state change is recorded. This post covers exactly what each framework requires and how monitoring data satisfies those requirements.

What Compliance Frameworks Require from Hardware Monitoring

The four frameworks most relevant to SMBs in the EU, Denmark, and internationally each address hardware monitoring from a different angle:

ISO 27001:2022 — Annex A 5.9 and 8.8

ISO 27001:2022 made two hardware-specific controls mandatory:

Annex A 5.9 — Inventory of Information and Other Associated Assets requires a documented, maintained inventory of all hardware assets. Auditors specifically look for: unique asset or serial number, current usage status, date of last technical check, and the asset’s role in data processing. The inventory must be audited at least annually, with physical spot checks to verify accuracy.

Annex A 8.8 — Management of Technical Vulnerabilities requires continuous monitoring processes for identifying and addressing vulnerabilities. Auditors expect 12 months of historic scan logs showing consistent execution, CVSS-based risk scoring, and documented remediation timelines (critical vulnerabilities: patch within 48 hours).

The 2022 revision tightened both controls compared to the 2013 version. A static spreadsheet asset register is no longer sufficient evidence for Annex A 5.9 — auditors want to see that the inventory reflects current machine status, not a point-in-time snapshot from 6 months ago.

SOC 2 — Availability Criterion and CC7.2

SOC 2's Availability criterion requires evidence that systems are monitored for hardware degradation and failures. Auditors check: uptime dashboards, hardware failure monitoring records, MTBF metrics, recovery time objective documentation, and evidence of disaster recovery testing.

Common Criteria CC7.2 requires that system monitoring shows ongoing detection of anomalies — including hardware failures and degradation events. Evidence must include monitoring dashboards, alert records with resolution documentation, and availability metrics retained for the full audit period.

Log retention for SOC 2: minimum 12 months for infrastructure monitoring logs, security incidents, and configuration changes.

NIS2 Directive — Articles 21 and 23

NIS2 was fully transposed into EU member state law on October 17, 2024. It applies to organizations with more than 50 employees and annual turnover above €10 million — directly covering the SMB clients GGFix serves.

Article 21 mandates ten cybersecurity risk-management measures including asset management: covered entities must maintain a granular inventory of all hardware assets, classify each asset’s risk level, and demonstrate preventive measures. Tool outputs and dashboard screenshots are explicitly acceptable as evidence for SMEs.

Article 23 creates the most urgent operational requirement: when a significant incident is detected, organizations must provide an early warning to the national CSIRT within 24 hours, an intermediate report within 72 hours, and a final report with root cause analysis within 1 month.

This 24-hour requirement makes automated hardware monitoring non-optional for any organization in scope. Without timestamped, automated alerts, producing an incident timeline within 24 hours of detection is not realistic. GGFix generates timestamped alerts the moment a sensor anomaly crosses a threshold — that alert is the start of your NIS2 incident documentation.

CIS Controls v8.1 — Control 1

CIS Control 1 is titled "Inventory and Control of Enterprise Assets" and is the most prescriptive public framework for hardware asset management. It requires: a documented inventory updated at least weekly using DHCP logs or IP management tools, unique identifiers for each asset (network address, hardware address, machine name, owner, department, approval status), and passive discovery tools to identify all connected assets.

CIS Controls v8.1 serves as the foundation many auditors cross-reference regardless of which primary framework the organization is pursuing.

What the Evidence Matrix Looks Like

Across all four frameworks, the same core evidence categories are required:

| Evidence Type | ISO 27001 | SOC 2 | NIS2 | CIS v8 | |---|---|---|---| ---| | Hardware asset inventory | Required (A 5.9) | Expected | Required (Art. 21) | Control 1 | | Hardware health / status logs | Expected | Availability | Expected | Control 1 | | Vulnerability scan history (12 months) | Required (A 8.8) | Expected | Expected | Control 7 | | Patch and update records | Required | Expected | Required | Control 7 | | Incident logs with timestamps | Required | Required | Required (Art. 23) | Control 17 | | System uptime / availability metrics | Implicit | Required | Expected | — | | Alert records with resolution documentation | Expected | Required | Required | — |

For hardware specifically, auditors look for evidence that monitoring is continuous — not point-in-time. Screenshots taken the day before an audit are not the same as 12 months of timestamped telemetry data.

What Auditors Actually Do With Hardware Logs

Understanding the audit process helps you prepare the right evidence rather than producing everything and hoping.

Phase 1: Evidence request list. Auditors issue a PBC (Prepared By Client) list. For hardware, this typically includes: current asset register export, last 12 months of vulnerability scan reports, patch deployment logs, and incident logs. If you cannot produce these quickly, the audit slows down and findings accumulate.

Phase 2: Log integrity verification. Auditors check whether logs can be modified retroactively. Immutable logging — write-once storage, server-side timestamps — significantly increases trust in evidence. Locally generated log files can be dismissed if chain of custody is questionable. GGFix stores all sensor data and alerts in Firebase with server-side timestamps that the user cannot modify — that tamper-evident structure is what auditors assign highest confidence to.

Phase 3: Sampling and gap detection. Auditors do not review every log entry. They sample specific date ranges and specific assets, then trace forward and backward through the record. If gaps exist in the telemetry timeline, that is a finding. A system that shows CPU temperatures consistently elevated for 3 months with no documented investigation is a control gap — even if no failure occurred.

Phase 4: Trend analysis. For availability and hardware health controls, auditors look for baselines and deviations. Proactive alert records with resolution documentation are the ideal artifact. "Alert fired on [date], acknowledged [date], repaired [date], closed [date]" is the evidence structure auditors want to see.

The GDPR Question: Is Hardware Monitoring Personal Data?

This is the question most organizations deploying fleet monitoring tools fail to address before deployment, and it creates unnecessary risk.

Hardware sensor data is not inherently personal data. CPU temperature readings, drive SMART values, fan speeds, and voltage rails are machine-linked, not person-linked. However:

• If the machine is assigned to a named individual, sensor telemetry becomes indirectly identifiable to that person — bringing it within GDPR's broad definition.
• If the telemetry includes process names, application usage patterns, or activity timestamps, it is almost certainly personal data.

Legal basis: Legitimate Interest under Article 6(1)(f) is the most practical and defensible basis for hardware monitoring in employment contexts. It requires a three-part Legitimate Interest Assessment: (1) Is there a legitimate business purpose (hardware health management, asset protection)? Yes. (2) Is monitoring the least invasive way to achieve it? Hardware sensor data is the minimum required — not keystrokes, not screen content. (3) Do employee privacy interests override the business interest? For hardware-health-only telemetry, this test is generally passed.

Consent is not recommended as the legal basis in employment contexts. EU data protection authorities consistently hold that employees cannot freely give consent due to power imbalance — meaning consent-based monitoring in workplaces is vulnerable to challenge.

Mandatory disclosure requirements before deployment:

1. What data is collected (list specific sensor types)
2. Why it is collected (hardware health management, asset protection)
3. How long it is retained
4. Who has access to it
5. Employee right to object under Legitimate Interest basis

Data minimization: GDPR requires collecting only data sufficient for the stated purpose. GGFix collects temperatures, SMART data, voltages, fan speeds, and power draw — all directly relevant to hardware health. This is the defensible minimum. It does not collect keystroke data, screen content, browser history, or application-level activity.

If you are deploying across a fleet of assigned employee machines, prepare a short written notice (can be included in the IT acceptable use policy) describing the monitoring scope before installation. This is both a GDPR requirement and good practice that removes ambiguity for employees.

Log Retention: How Long Is Long Enough?

Retention requirements vary by framework:

Framework	Recommended Retention
SOC 2	12 months (auth, incidents, config changes)
ISO 27001	Organization-defined; risk-based; 12 months industry standard
NIS2	No fixed period; must support incident reporting requirements
PCI DSS 4.0	12 months total; 3 months immediately accessible
GDPR	Retain for stated purpose only; delete when purpose is met
Cyber insurance	12 months minimum (standard underwriting condition)

Practical recommendation: 12 months minimum for all hardware monitoring logs where no specific mandate applies. For organizations pursuing ISO 27001 or SOC 2, align retention to the audit cycle (typically 12 months). For NIS2, retain at minimum long enough to support the 1-month final incident report requirement — which in practice means continuous retention with a minimum 13-month rolling window.

Storage is not a constraint: a year of compressed sensor data per machine at 1-minute intervals requires approximately 5–10 MB. Retaining 3 years of monitoring history for a 50-machine fleet costs effectively nothing in cloud storage terms.

Audit-Ready by Default

The practical value of continuous monitoring for compliance purposes is not just the data — it is the posture. An organization with 12 months of hardware sensor history, alert logs with resolution timestamps, and an automatically maintained asset register walks into an ISO 27001 or SOC 2 audit with its Annex A 5.9, A 8.8, and CC7.2 evidence already prepared.

This contrasts sharply with the typical compliance preparation pattern: two weeks before the audit, someone scrambles to pull together records that were never systematically maintained, producing a documentation package that auditors assess as retroactively assembled — which is exactly what it is.

For the fleet management and MSP context — where demonstrating monitoring capability to clients is as important as the compliance record itself — our MSP hardware monitoring operations guide covers how to structure the reporting workflow for client-facing compliance evidence.

Frequently Asked Questions

Does ISO 27001 require hardware health monitoring specifically?

ISO 27001:2022 Annex A 5.9 requires a maintained asset inventory with current status for all hardware. Annex A 8.8 requires ongoing vulnerability monitoring with 12-month scan history. Together, these controls expect evidence that hardware is tracked continuously, not just at audit time. A static spreadsheet updated annually does not satisfy A 5.9 in a 2022-revision audit — auditors expect dynamic inventory data reflecting current machine states.

What does NIS2 require that most SMBs are not prepared for?

NIS2 Article 23's 24-hour early warning requirement is the most operationally demanding. Organizations in scope must notify the national CSIRT within 24 hours of detecting a significant incident. Without automated hardware monitoring with timestamped alerts, it is practically impossible to produce an accurate incident timeline within that window. NIS2 also requires the asset inventory (Article 21) to be current and risk-classified — a requirement that automated monitoring satisfies continuously.

Is hardware sensor data covered by GDPR?

Hardware sensor data (temperatures, drive health, voltages) is not inherently personal data — but it becomes indirectly identifiable if the machine is assigned to a named employee. The appropriate legal basis is Legitimate Interest under Article 6(1)(f). Before deploying fleet monitoring on employee machines, prepare written disclosure covering what is collected, why, how long it is retained, and who can access it. Hardware-health-only telemetry (not keystrokes, screen data, or application usage) is the most defensible monitoring scope under data minimization principles.

How long should hardware monitoring logs be retained for compliance purposes?

The industry standard and the practical minimum for most compliance frameworks is 12 months. SOC 2 explicitly requires 12 months for infrastructure monitoring logs. ISO 27001 and NIS2 do not specify a period but require records sufficient to support audit and incident reporting — which in practice means at minimum 12–15 months. For PCI DSS, 12 months total with 3 months immediately accessible is the published standard.

Does hardware monitoring data help with insurance as well as compliance?

Yes — and the same log that satisfies an ISO 27001 auditor also satisfies an equipment breakdown insurance adjuster. Both want to see timestamped, tamper-evident records showing the equipment was monitored, anomalies were flagged, and responses were documented. The compliance audit trail and the insurance claim documentation are structurally the same artifact. For the full insurance angle, see our IT insurance and hardware monitoring guide.