The deputy is not a loophole

A significant security incident does not wait until the information security officer is back from leave. Section 32(1) of the German BSI Act (BSIG) requires the early initial report "without undue delay, but no later than within 24 hours of becoming aware", and Article 33 GDPR requires a personal data breach to be notified where feasible within 72 hours. Both deadlines start when the organisation becomes aware, not when the responsible person returns.

So every role that a deadline or an approval depends on needs a deputy. That is undisputed and in most organisations it is regulated, on paper. In practice there are two ways to fail.

First failure: nobody sees it

The task sits in the absent person's inbox. The out-of-office reply in the mail client answers the sender, but it changes nothing about the assignment in the tool. The deputy is named but does not know they are needed right now. After two weeks the returning person finds an expired resubmission and an approval that has been blocked for ten days.

Second failure: the deputy may do too much

The second failure is less visible. In small teams two people deputise for each other. One requests a firewall change, the other is supposed to approve it and is on leave. The approver's deputy is the requester. She approves her own request, on time and formally correct.

That is exactly what IT-Grundschutz rules out. Basic requirement ORP.1.A4 demands that incompatible tasks such as operational and supervisory functions be assigned to different people, and ends with the sentence: deputies must also be subject to segregation of duties. A deputy rule that does not reflect this undermines the four-eyes principle precisely when nobody is watching.

What a deputy rule has to record

Three things therefore belong in every technical deputy rule. First, the deputy receives tasks in addition, not instead: on return, the absent person should see what was decided on their behalf. Second, anyone who may not decide under the four-eyes principle is excluded, even if entered as deputy. Third, it remains traceable who decided for whom.

And a fourth point that has nothing to do with information security but everything to do with data protection: the reason for the absence is nobody's business. "Sick" in a deputy entry is health data within the meaning of Article 9 GDPR, visible to everyone who can see the deputy arrangement.

How isidaten handles it

With the Absence and Deputy module, employees enter the period and their deputy themselves; user administration can do so for everyone. It can be set separately whether the deputy takes over tasks, approvals or resubmissions from the document store. The deputy receives them in addition to the absent person and can act on them. The module deliberately does not ask for a reason.

In multi-stage approvals, the deputy only applies if the stage allows it. Where the four-eyes principle applies, the requester and the creator of the object are excluded, also as deputies: the approval is not routed to them, and it is checked again at the decision. If the deputy decides, the approval records whom the decision actually belonged to.

Two rules prevent surprises when an absence is entered. The deputy must share a team with the person, and must not be absent during the period themselves. There are no chains in which the deputy's deputy decides.

The test question

Who deputises for the person who approves firewall changes in your organisation during their next leave? And does that deputy file firewall requests themselves?

If so, your four-eyes principle becomes a two-eyes principle for the duration of the leave.

Sources

BSI IT-Grundschutz Compendium, module ORP.1 Organisation, 2023 edition, requirement ORP.1.A4 (German). Section 32 BSIG (German). Regulation (EU) 2016/679 (GDPR), Articles 9 and 33.