Zum Hauptinhalt springen
Elementary Threat · BSI IT-Grundschutz

G 0.27 — Lack of Resources

Updated on 4 min Reviewed by: Cenedril Editorial
A.5.1A.5.2A.5.4A.5.5A.5.7A.5.9A.5.14A.5.15A.5.19A.5.20A.5.21A.5.24A.5.25A.5.26A.5.27A.5.28A.5.29A.5.30A.5.35A.5.36A.6.7A.6.8A.7.2A.7.5A.7.9A.7.11A.7.12A.7.13A.7.14A.8.1A.8.2A.8.3A.8.5A.8.6A.8.7A.8.9A.8.10A.8.14A.8.15A.8.17A.8.18A.8.19A.8.20A.8.21A.8.22A.8.23A.8.24A.8.25A.8.26A.8.27A.8.28A.8.29A.8.30A.8.31A.8.32A.8.34 BSI IT-GrundschutzISO 27001ISO 27002

When budget, staff, time or infrastructure are missing, information security quietly erodes — often long before a concrete incident occurs.

Lack of resources (G 0.27) affects the entire IT operation: from server capacity through personnel to the funding of security measures. In normal operations, bottlenecks can be temporarily compensated. Under pressure — for example in an emergency — they become a critical risk.

What’s behind it?

Lack of resources acts as an amplifier for nearly every other threat. When an organisation’s foundation — staff, budget, infrastructure, time — does not match the requirements, even the best security concepts run empty.

Affected resources

  • Human resources — Too few administrators, missing backup arrangements, unfilled security roles. Critical tasks such as patch management, log analysis or emergency drills fall by the wayside.
  • Technical resources — Undersized servers, insufficient network bandwidth, missing redundancy. New applications are placed on infrastructure that was dimensioned for the original load.
  • Financial resources — No budget for spare parts, licence renewals or external specialists. In an insolvency, even basic maintenance contracts can no longer be served.
  • Time resources — Over-tight project plans that leave no time for security testing. Security measures are “deferred” — and then never implemented.

Impact

Lack of resources rarely causes a single, dramatic incident. Its impact unfolds gradually: patches are applied late, monitoring alerts are not processed in time, emergency plans are not tested. When a concrete incident then occurs — a ransomware attack, a hardware failure, a compliance audit — the capacity to respond adequately is missing.

Practical examples

Overloaded administrators. In a company, a single administrator is responsible for network, servers and security. Log files are checked only every few weeks. An attacker exploits a known vulnerability that has been unpatched for months. The breach is only noticed when customer data appears on the darknet — weeks after the initial access.

Network overload through new applications. An organisation introduces a video conferencing solution whose bandwidth requirement was not considered in the network planning. During peak hours, the entire network collapses because the infrastructure cannot scale. Business-critical applications such as ERP and email are unreachable for hours.

No budget for spare parts. A company in financial difficulties cannot purchase hard drives for an ageing storage system. When a disk in the RAID array fails, there is no replacement. A second disk failure within a few days leads to total loss of the array.

Relevant controls

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

Prevention:

Detection:

Response:

BSI IT-Grundschutz

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

  • ISMS.1 (Security management) — Requirements for providing resources for the ISMS.
  • ORP.1 (Organisation) — Organisational framework and staffing.
  • DER.4 (Emergency management) — Resource planning for emergency and crisis situations.
  • OPS.1.1.1 (General IT operations) — Basic requirements for IT operations staffing.

Sources

ISO 27001 Controls Covering This Threat

A.5.1 Policies for information security A.5.2 Information security roles and responsibilities A.5.4 Management responsibilities A.5.5 Contact with authorities A.5.7 Threat intelligence A.5.9 Inventory of information and other associated assets A.5.14 Information transfer A.5.15 Access control A.5.19 Information security in supplier relationships A.5.20 Addressing information security within supplier agreements A.5.21 Managing information security in the ICT supply chain 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.28 Collection of evidence A.5.29 Information security during disruption A.5.30 ICT readiness for business continuity A.5.35 Independent review of information security A.5.36 Compliance with policies, rules and standards for information security A.6.7 Remote working A.6.8 Information security event reporting A.7.2 Physical entry A.7.5 Protecting against physical and environmental threats A.7.9 Security of assets off-premises A.7.11 Supporting utilities A.7.12 Cabling security A.7.13 Equipment maintenance A.7.14 Secure disposal or re-use of equipment A.8.1 User endpoint devices A.8.2 Privileged access rights A.8.3 Information access restriction A.8.5 Secure authentication A.8.6 Capacity management A.8.7 Protection against malware A.8.9 Configuration management A.8.10 Information deletion A.8.14 Redundancy of information processing facilities A.8.15 Logging A.8.17 Clock synchronisation A.8.18 Use of privileged utility programs A.8.19 Installation of software on operational systems A.8.20 Networks security A.8.21 Security of network services A.8.22 Segregation of networks A.8.23 Web filtering A.8.24 Use of cryptography A.8.25 Secure development life cycle A.8.26 Application security requirements A.8.27 Secure system architecture and engineering principles A.8.28 Secure coding A.8.29 Security testing in development and acceptance A.8.30 Outsourced development A.8.31 Separation of development, test and production environments A.8.32 Change management A.8.34 Protection of information systems during audit testing

Frequently asked questions

How does lack of resources differ from loss of personnel?

Loss of personnel (G 0.33) describes the concrete departure of individual people. Lack of resources (G 0.27) is broader and covers human, technical, time and financial shortages. Both threats reinforce each other: an organisation already suffering from resource shortages copes much worse with a personnel loss.

Can resource shortages also be caused deliberately?

Yes, and the BSI explicitly points this out. A deliberately provoked excessive demand on a resource -- for example through a denial-of-service attack (G 0.40) -- can systematically overload resources. In practice, the line between accidental shortage and deliberate overload is often blurred.

How do I recognise that resource shortage is threatening security?

Typical warning signs: security patches are applied only weeks after release, log files are reviewed only sporadically, emergency drills do not happen, open security incidents remain unresolved longer than planned. When day-to-day operations crowd out security work, the resource shortage has already become security-relevant.