Skip the detailed risk analysis at the start — instead apply standardised baseline protection (Grundschutz) against a catalogue of "pauschale Gefährdungen" (generic threats), then add risk analysis only for the bits that need more.

* Grundschutz inverts the classic order: baseline catalogue first, risk analysis only for erhöhter Schutzbedarf. *

The classic ISMS approach is: identify assets → assess risks → derive controls. That's heavy. BSI inverts it: assume every standard IT setup faces the same standard threats, and apply a standard control catalogue. Save the expensive risk analysis for the few systems with erhöhter Schutzbedarf (elevated protection needs).

As Wikipedia puts it:

"Basis eines IT-Grundschutzkonzepts ist der initiale Verzicht auf eine detaillierte Risikoanalyse. Es wird von pauschalen Gefährdungen ausgegangen und dabei auf die differenzierte Einteilung nach Schadenshöhe und Eintrittswahrscheinlichkeit verzichtet."

Why this is powerful: the IT-Grundschutz-Kompendium ships 80+ Bausteine (building blocks: Sicherheitsmanagement, ORP, CON, OPS, DER, IND, APP, SYS, NET, INF), each already mapped to threats and controls. A new project can pick the building blocks that apply, and 80% of the security work is done.

Tip: Grundschutz is the antidote to "we'll do security after risk analysis." It lets you deploy a defensible baseline on day one, then refine.

Go deeper:

• BSI IT-Grundschutz (official) — BSI's own description of the baseline methodology and the 200-x standards.
• IT baseline protection — the cookbook approach that skips initial detailed risk analysis in favour of standard building blocks.

Idle = expires after a period of inactivity. Absolute = expires N units after the session was created, regardless of activity.

* Idle expiry resets on each activity; the absolute cap ends even a continuously-active session. *

Both are required — they address different threats.

On expiry: both kill the session server-side and force re-authentication.

The guiding principle (in German):

• "Eine Session sollte immer nur eine bestimmte Lebensdauer haben." (Sessions must have a defined lifetime.)
• "Je kürzer die Session-Lebensdauer, desto kleiner das Zeitfenster für einen potenziellen Session-basierten Angriff." (Shorter lifetime = smaller attack window.)

Logout still matters: even with timeouts, a user-initiated logout must immediately invalidate the session server-side. Don't rely on the timeout to clean up.

Tip: The trade-off is UX vs. blast radius. The right values depend on Schutzbedarf (protection need): a webmail might be 30 min idle / 24 h absolute, a private-banking session 5 min / 1 h. Pick based on what an attacker can do with one stolen session.

Go deeper:

• OWASP Session Management Cheat Sheet — Session Expiration — idle vs absolute timeouts and why both are needed.