G 0.33 — Loss of Personnel

The sole network administrator of a company is on sick leave for several weeks. The network initially continues to run stably — until after two weeks a server crashes. No one in the company can fix the fault. The network remains offline for days, because all knowledge about the infrastructure was held by a single person.

Loss of personnel (G 0.33) is one of the most frequently underestimated threats. As long as everything runs, it is not apparent that critical knowledge only exists in one head. Only when this person is absent does the extent of the dependency become visible.

What’s behind it?

Personnel can be absent for many reasons — foreseeable (holiday, training, end of contract) and unforeseeable (illness, accident, pandemic, strike). The real problem arises when an organisation is unprepared to take over the tasks of the absent person seamlessly.

Failure scenarios

Individual absence — A key person (administrator, CISO, subject matter expert) is unavailable. It becomes critical when only this person can administer certain systems or knows certain credentials.
Extended illness or accident — For an absence lasting weeks or months, simple backup arrangements often do not suffice. The deputy must be able to act independently.
Pandemic — In a pandemic, more and more people drop out progressively — through their own illness, care of relatives, childcare or fear of infection. The remaining staff can only handle the most urgent tasks.
Foreseeable departure with knowledge loss — In case of resignation or retirement, the personnel loss is plannable, but if the handover of knowledge does not happen in a structured way, critical information is nevertheless lost.

Impact

The availability of entire business processes is at stake when key people drop out and no backup is trained. In a pandemic situation, the effect can cascade: maintenance work piles up, systems gradually fail, operations shrink to a minimum. Especially critical are credentials and passwords known only to one person — they can render entire systems inaccessible.

Practical examples

Safe code only in the head. During an administrator’s holiday, access is needed to the backup media in the data protection safe. The access code was changed only recently and is known only to this administrator. Data recovery is delayed by several days until he can be reached on holiday.

Pandemic-driven cascade of absences. In a medium-sized company, 40% of the IT department drop out within two weeks during a flu wave. Routine maintenance tasks pile up — including monitoring of the air conditioning in the server room. When the unit develops a defect, no one notices in time, and three servers suffer heat damage.

Resignation without knowledge transfer. A long-serving system administrator resigns and leaves the company after a shortened notice period. A structured handover does not take place. In the following months, the IT department discovers that numerous cron jobs, scripts and workarounds are undocumented anywhere. Reconstruction takes months.

Relevant controls

The following ISO 27001 controls mitigate this threat. (You’ll find the complete list of 17 mapped controls below in the section ‘ISO 27001 Controls Covering This Threat’.)

Prevention:

A.5.29 — Information security during disruption: Continuity planning accounts for the loss of key personnel.
A.6.8 — Information security event reporting: Defined reporting paths work even when the primarily responsible person is absent.
A.5.14 — Information transfer: Secure handover of operationally critical knowledge to deputies.
A.5.11 — Return of assets: On departure, access means, hardware and documentation are systematically collected.

Detection:

A.8.15 — Logging: Automated monitoring detects when overdue maintenance tasks are not performed.
A.8.7 — Protection against malware: Automated protection mechanisms continue to function even without manual intervention.

Response:

A.5.24 — Information security incident management planning and preparation: Incident response plans with named deputies at each escalation level.
A.5.27 — Learning from information security incidents: Lessons-learned process after personnel losses identifies further single points of failure.

BSI IT-Grundschutz

G 0.33 is linked by the BSI IT-Grundschutz catalogue to the following modules:

ORP.2 (Personnel) — Requirements for backup arrangements and onboarding.
DER.2.1 (Handling of security incidents) — Ensuring operational capability during personnel loss.
OPS.1.1.1 (General IT operations) — Organisational requirements for staffing.
DER.4 (Emergency management) — Consideration of personnel shortages in emergency planning.

Sources

BSI: The State of IT Security in Germany — Annual report with findings on organisational risks
BSI IT-Grundschutz: Elementary Threats, G 0.33 — Original description of the elementary threat
ISO/IEC 27002:2022 Section 5.29 — Implementation guidance on information security during disruption

ISO 27001 Controls Covering This Threat

A.5.5 Contact with authorities A.5.7 Threat intelligence A.5.11 Return of assets A.5.14 Information transfer A.5.24 Information security incident management planning and preparation A.5.25 Assessment and decision on information security events A.5.26 Response to information security incidents A.5.27 Learning from information security incidents A.5.29 Information security during disruption A.6.5 Responsibilities after termination or change of employment A.6.7 Remote working A.6.8 Information security event reporting A.7.9 Security of assets off-premises A.8.2 Privileged access rights A.8.7 Protection against malware A.8.15 Logging A.8.18 Use of privileged utility programs

Frequently asked questions

What distinguishes loss of personnel from lack of resources?

Loss of personnel (G 0.33) refers to the concrete departure of individual people -- through illness, accident, resignation or holiday. Lack of resources (G 0.27) describes the fundamental mismatch between available resources (including personnel) and the requirements. Both threats reinforce each other.

How do you identify single points of failure in personnel?

Systematically go through all critical IT systems and business processes. For each ask: who can administer this system, who understands the process, who has the credentials? If the answer is always the same name, you have a single point of failure. Document these dependencies and plan for backups.

How do you handle access codes known only to one person?

Critical credentials (safe codes, root passwords, encryption keys) must be deposited in a sealed envelope or a password safe that authorised backup personnel can access in an emergency. The deposit must be documented and regularly checked for currency.