11 skills.
Use when asked to write a business continuity plan (BCP) — an organization-wide plan for keeping critical operations running through a major disruption (facility loss, supplier failure, pandemic, natural disaster) — as distinct from disaster-recovery-testing (see below), which is the IT-systems-only slice of this.
Use when asked to write or process a change request — a formal request to modify a specific system, process, or environment under IT/ITIL-style change control — as distinct from [[enterprise-change-management]], which governs organizational and people change (reorgs, new processes, culture shifts) rather than controlled technical or operational changes to a system.
Use when asked to set up or document configuration management — systematically tracking and controlling a system's settings, versions, and dependencies so its actual state is known and reproducible rather than drifting unrecorded — as distinct from a [[change-request]], which is the approval process for a specific proposed change rather than the ongoing record of a system's current configuration.
Use when asked to write a disaster recovery plan — the written plan for recovering IT systems and data after a major disruption, including recovery objectives, sequence, and backup strategy — as distinct from [[disaster-recovery-testing]] (verifying the plan actually works, rather than the plan itself) and narrower than a [[business-continuity-plan]] (org-wide continuity across people, facilities, and suppliers, not just IT systems and data).
Use when asked to write or review an incident response plan — the pre-defined process for handling a security or operational incident while it's happening, including severity levels, roles, and escalation — as distinct from a [[postmortem]] (the after-the-fact analysis once the incident is over) and a [[business-continuity-plan]] (broader, org-wide continuity planning rather than tactical in-the-moment response).
Use when asked to set up, configure, secure, or troubleshoot Keycloak, the open-source identity and access management server, including realms, clients, users, roles, single sign-on with OpenID Connect or SAML, identity brokering, and deployment. Distinct from [[threat-modeling]], which analyzes risks without configuring an identity provider.
Use when asked to set up or document an on-call rotation — the schedule and process for who's responsible for responding to alerts and incidents outside normal hours, and how that responsibility hands off between people — as distinct from an [[incident-response-plan]], which governs what happens once an incident is declared rather than who's watching for one in the first place.
Use when asked to write or facilitate a postmortem — a blameless, after-the-fact analysis of an incident, its timeline, root cause, and follow-up actions — as distinct from an [[incident-response-plan]] (what happens during the incident, not after) and a routine [[agile-reflection]] (triggered by an incident, not run on a scheduled cadence).
Use when asked to write a runbook — a step-by-step operational procedure for a specific, recurring task or system situation, such as restarting a service, rotating a credential, or failing over a database — as distinct from an [[incident-response-plan]], which governs roles and communication during an incident rather than the precise technical steps for one specific action.
Use when asked to build or document a service catalog — a structured, discoverable list of the IT or business services an organization offers internally or externally, what each includes, and how to request it — as distinct from a [[service-level-agreement]], which defines the performance commitment for one specific service rather than listing what services exist at all.
Use when asked to threat model a system or feature — proactively analyzing a design for security weaknesses before it's built — as distinct from penetration-testing (see below), which attacks a system that already exists.