DEFENCE IN DEPTH
What is the defence-in-depth model for third-party OT access and what are the six control layers?
Across all four patterns, the same structural answer recurs: no single control is load-bearing. A defensible third-party access pattern is a stack of independent layers, each catching what the previous missed. If one layer fails, the asset is still protected by the next. This is the structural answer to the supply-chain risk that NIS2 Article 21(2)(d) addresses, and it is the reason Patterns A through D differ in implementation but not in shape.
The six layers, from outermost to innermost: Identity and Access (who is requesting); Approval and Ticketing (why and when); Network Path Control (where the session may go); Session Mediation (how the session is rendered into the zone); Session Recording and Monitoring (the witness); Log Integrity and Export (the evidence). Each layer carries its own framework anchor; together they cover the FR 1 through FR 7 spectrum of IEC 62443-3-3.
Figure 6. Six concentric control layers wrap a single OT asset. Each layer carries its own framework anchor; together they span the seven Foundational Requirements of IEC 62443-3-3.
INCIDENT HANDLING ACROSS THE LAYERS
How does incident handling work across the defence-in-depth layers?
NIS2 Article 21(2)(b) requires entities to implement incident handling as a named technical and organisational measure. The layers above are structured for prevention; a defensible pattern also needs structured detection and response when prevention fails. Incident handling threads through three of the six layers.
At the Session Recording and Monitoring layer, the recording is not passive; it is piped into an automated rule set that alarms on specific anomalies: attempts to stop or restart a PLC, unauthorised code upload, command sequences that do not match the ticketed work, and authentication events outside the approved window. Anchors: IEC 62443-3-3 SR 6.1 (audit log accessibility) and SR 6.2 (continuous monitoring); audit log generation is anchored in SR 2.8 (auditable events) and SR 2.9 (audit storage capacity); Lov om styrket beredskab i energisektoren §8 stk. 2 nr. 6 (parent law) and BEK 260 §66 stk. 2 nr. 2 (logging on remote-access equipment).
At the Log Integrity and Export layer, the pipeline feeds an OT intrusion detection system or a security operations centre that can see events in near-real-time, not only after the fact. Passive logs without alarming do not satisfy §8 stk. 2 nr. 6, because §8 stk. 2 nr. 6 requires the log to support alarms and incident handling, not only forensic reconstruction. The same obligation is reinforced by NIST SP 800-53 Rev. 5 control AU-6 (Audit Record Review, Analysis, and Reporting), which requires review with frequency matched to the risk of the system.
At the Approval and Ticketing layer, incident handling closes the loop: a detected anomaly revokes the active session, notifies the site owner, and opens an incident record with the same identifiers as the session recording. This makes the incident handling response traceable to a specific session, a specific vendor identity, and a specific set of actions, which is the evidence pattern NIS2 Article 23 (significant incident reporting) requires.
Personal data note. Session recordings typically contain personal data within the meaning of the EU General Data Protection Regulation (GDPR). Retention periods, access control, data subject rights, and processing grounds must be addressed in the recording policy, independently of the technical control. GDPR obligations apply to the recording whether or not the underlying OT system is subject to NIS2.