ISO 27400 Lead Manager study materials
ISO 27400 Lead Manager study resources

A green dashboard during a seven-week retail compromise

ISO 27400 Lead Manager · Put your knowledge to work in context.

All case studies

A green dashboard during a seven-week retail compromise

A retail chain has 1,200 stores, each with 12 IP cameras, a smart HVAC controller and a store hub connecting to a central video platform. The security team's monthly dashboard reports 98% of cameras on the latest firmware, 99.6% patching compliance and zero open critical vulnerabilities. Then an incident: for seven weeks, attackers used default credentials on HVAC controllers to reach store networks and exfiltrate test card data from staging systems in three stores. The dashboard stayed green throughout. The COO asks whether the security programme is working and what should change. The board also wants assurance before the peak trading season in four months. You are asked to redesign measurement, the review cycle and the improvement loop in line with ISO/IEC 27400's expectations for monitoring and continual improvement.

1. Why did the dashboard fail to detect this, and what would you measure instead?

Read the worked answer

The metrics measured activity and compliance inside a narrow scope, not effectiveness or outcome. Four specific failures: HVAC controllers were outside the reporting scope entirely; default-credential risk was never measured; patch percentages counted only devices under management, so unmanaged devices improved the score by being invisible; and nothing measured detection, so a seven-week dwell time registered as health.

Replace with layered measures, each tied to a risk scenario and an owner:

  • Coverage: discovered versus expected devices by class, and percentage with a named owner. This is the metric that would have exposed the HVAC gap.
  • Exposure: internet-reachable devices, default or weak credentials found in sample testing, and the age of open exceptions.
  • Control effectiveness: sample-based configuration verification, drift from baseline, and segmentation test results - tested, not assumed.
  • Detection and response: median time to detect IoT anomalies, alert triage time, containment time.
  • Supplier: patch availability against SLA and count of devices nearing end of support.

Apply a 'so what' test. Every metric needs a threshold, a decision it triggers and a named owner; otherwise it is decoration. Keep the compliance figures for audit, but never let them stand alone as evidence that the programme works. Report leading indicators such as new device classes onboarded and unowned devices found, so the picture changes before an incident reveals it.

2. Design the review cycle: cadence, inputs, outputs and participants.

Read the worked answer

Three tiers, each with a different decision right.

Operational, weekly: security operations with IT and store operations. Inputs: alerts, onboarding requests, patch backlog, open exceptions, incident follow-ups. Outputs: containment actions and owners.

Programme, monthly: security lead, facilities, store operations, network and procurement. Inputs: treatment plan status, risk register changes, metric trends, supplier performance, audit findings. Outputs: prioritisation, resourcing requests, contract actions.

Management review, quarterly: COO or CISO chairing, with facilities, store operations and finance. Inputs: trends, incidents and lessons, internal audit, penetration tests, asset discovery deltas, regulatory and threat changes, appetite statements. Outputs: decisions with owners and dates, revised treatment plans, policy changes, budget, escalation and explicit acceptance of residual risk.

Add a peak-season assurance review four months out with a single question: what would have to be true for us to detect this attack during peak trading? Test it rather than assert it, and report the result to the board.

The improvement loop is: incident or finding, root cause, corrective action, effectiveness verification, update to risk assessment and controls, then re-measure. Track corrective actions to closure with ageing visible at each tier, so the loop cannot stall silently between meetings.

3. Who should own IoT security across 1,200 stores, and how do you fix the accountability gap?

Read the worked answer

Appoint one accountable owner for the IoT estate in the security or programme function, with clear responsibility split: facilities remains responsible for HVAC operation and physical access, store operations for local behaviour and escalation, IT for network and identity, procurement for contracts. Put this in a RACI that people have actually seen, not a document in a repository.

Introduce a device onboarding gate. No device reaches a store network without registration, a named owner, a baseline configuration and confirmation that default credentials have been removed. Facilities' HVAC refresh would have been stopped at this gate. Pair it with an exception process that has an expiry date, so urgent installs remain possible without becoming permanent.

Change the contracts. Camera and HVAC suppliers should provide credential management, patching commitments, notification of vulnerabilities and end-of-support dates. Where a supplier cannot, that becomes a recorded procurement risk decision.

Require central visibility. Every store device must report to central monitoring, and store networks must be segmented so a compromised HVAC controller cannot reach staging or point-of-sale systems.

Enforce through the COO where local practice conflicts. The accountability gap existed because no single person could answer 'who owns this device'; fixing the RACI, the gate and central visibility makes that question answerable every time.