Technical control

ISO/IEC 27002:2022 clause 8 groups 34 technological controls, from 8.1 (user endpoint devices) to 8.34 (protection of information systems during audit testing). They cluster into identity and access (8.2 privileged access rights, 8.3 information access restriction, 8.4 access to source code, 8.5 secure authentication), host and malware protection (8.7), vulnerability and configuration management (8.8, 8.9), data protection (8.10 information deletion, 8.11 data masking, 8.12 data leakage prevention, 8.24 use of cryptography), resilience (8.13 backup, 8.14 redundancy), detection (8.15 logging, 8.16 monitoring activities, 8.17 clock synchronisation), network security (8.20-8.23, including web filtering) and secure development (8.25-8.33). Controls 8.9, 8.10, 8.11, 8.12, 8.16, 8.23 and 8.28 (secure coding) were new in the 2022 edition.

The US literature uses "technical" or "logical" controls in the same sense, and NIST SP 800-53 historically labelled families as management, operational or technical before dropping those class designations in Revision 4. As with the other ISO themes, the category says what implements the control, not what it does: a technical control may be preventive (a firewall rule, MFA), detective (an IDS signature, file integrity monitoring) or corrective (automatic rollback, restore from backup), which ISO 27002 captures in its separate control-type attribute.

The main advantage of technical controls is consistency and scale: they apply the same decision to every request at machine speed and produce evidence (logs, configuration states) that can be checked automatically. Their characteristic failure modes are different from those of organisational or people controls. Misconfiguration silently removes protection while the dashboard stays green; exceptions accumulate (a firewall "any-any" rule added for a migration and never removed); controls fail open under load or error; coverage gaps leave assets outside the control's reach; and controls can be bypassed or disabled by an attacker with sufficient privilege. Technical controls therefore need their own monitoring - alerting when an EDR sensor goes silent, configuration compliance scanning, periodic rule reviews - and an organisational owner.

Every technical control rests on organisational decisions: a DLP rule enforces a classification scheme, an access control list enforces an access policy, a patch deployment enforces a remediation SLA. Without the policy, the technical control encodes an undocumented guess. Conversely, where a rule can be technically enforced it usually should be, because enforcement is more reliable than instruction - the logic behind "technical where possible, organisational where necessary". In GDPR and NIS2 language these are the "technical" half of technical and organisational measures (GDPR Art. 32, NIS2 Art. 21(1)), and a compliance assessment has to look at both halves together.