Self-Assessment

The SRF self-assessment is an online tool that guides you through 64 sub-domains, across 11 domains, producing a scored reliability profile and gap list at the end. This page walks through each stage so you know what to expect before you start.


Before you start

Who should complete it

You don't need to be the person who built the systems — but you do need to know what is actually in place. That means someone with operational knowledge of your production environment: what monitoring exists, what alerting fires, what redundancy is configured, what runbooks exist, and what your deployment controls look like.

For the enabling domains (Governance, Personnel, Incident Management), the right assessor is typically an engineering lead or SRE manager rather than an individual engineer. For technical domains (Code, Infrastructure, Database, Deployment, and so on), a senior engineer or platform lead who works with those systems day-to-day is usually best placed to answer accurately.

If no single person has full visibility, the sidebar navigation (see Step 3) makes it practical to split the assessment across two or three team members, each completing the sub-domains within their area.

Time and persistence

The assessment is completable in under 20 minutes by someone with broad operational knowledge of their environment. The wizard moves quickly once you have a clear picture of what your organisation has in place.

State is held in memory only — there is no save or resume. Complete the assessment in one sitting. If you need to pause, use the Skip button (described below) to defer sub-domains you're uncertain about, reach the results screen, and then return to those sub-domains via the sidebar before exporting. Once you close or refresh the page, your session is lost.

Answering accurately

The assessment takes your answers at face value — it does not verify evidence. This makes accurate self-reporting essential. A few guidelines before you begin:

  • Answer for your current state, not your intended or aspirational state. If a control is planned but not yet deployed, do not check it.
  • If a control exists but is informal or person-dependent (for example, a senior engineer mentally tracks database query performance but there is no automated alert), check the ad-hoc capability only — not the automated or managed variant.
  • When in doubt, skip and return later. A skipped sub-domain is excluded from scoring rather than counted as zero, so it is always better to skip than to overestimate.

Step 1 — Navigate to the assessment

Go to /self-assessment. You will land on a page showing the framework statistics: 11 domains, 64 sub-domains, 192 evaluation axes. When you are ready, click Start Assessment to enter the wizard.


Step 2 — The wizard

The wizard presents one sub-domain at a time. Each sub-domain page has three sections: Detection, Mitigations, and Response. These correspond to the three axes every sub-domain is assessed on:

  • Detection — can you see the problem coming? Monitoring, alerting, and proactive identification.
  • Mitigations — what architectural controls are in place? Redundancy, defensive design, and policy enforcement.
  • Response — can you recover quickly? Runbooks, rollback capability, and incident response procedures.

Each section contains a list of capabilities. Check every capability your organisation currently has in place. Leave unchecked anything that is absent, planned but not deployed, or only occasionally practised.

Capability prerequisites

Some capabilities are greyed out until you check their prerequisites. This reflects the framework's dependency model: you cannot claim automated alerting without first establishing that baseline monitoring is in place. The prerequisite logic is enforced by the tool so that your score reflects genuine capability rather than aspirational selections.

When you check a prerequisite, its dependent capabilities unlock automatically. If you uncheck a prerequisite, any dependent capabilities you had already selected are cleared — the score is recalculated to remain consistent.

Navigation

Four navigation actions are available at the bottom of each sub-domain page:

  • Continue — save the current sub-domain's answers and advance to the next sub-domain.
  • Previous — return to the previous sub-domain. Your current answers are preserved.
  • Skip — mark this sub-domain as unanswered and advance. Skipped sub-domains are excluded from scoring entirely — they are not counted as zero. You can return to any skipped sub-domain at any time via the sidebar.
  • View Results — this replaces Continue on the final sub-domain. Clicking it scores all answered sub-domains and takes you to the results screen.

Step 3 — Using the sidebar

The left sidebar lists all 11 domains as collapsible groups. Each domain expands to show its sub-domains. You can click any sub-domain at any time to jump directly to it — the wizard will save your current answers before navigating.

Completed sub-domains show a visual indicator so you can track progress at a glance.

The sidebar is most useful for:

  • Returning to skipped sub-domains — if you skipped sub-domains you were uncertain about, come back to them via the sidebar before clicking View Results.
  • Reviewing answers before scoring — if you want to check a previous sub-domain, click it in the sidebar, adjust if necessary, and then navigate back to where you were.
  • Splitting the assessment across team members — one person can handle all Database sub-domains while another handles Deployment. Each navigates to their relevant sub-domains in the sidebar. Because state is in-memory for the session, this works best in a shared screen or working through the domains sequentially on a single device.

Tips for accurate results

Prioritise completeness over speed. A partially skipped assessment still produces a valid grade — scored across the sub-domains you did answer — but more answers produce a more representative result. It is worth taking an extra five minutes to return to skipped sub-domains before viewing results.

Mitigations is the hardest axis to score honestly. Industry-wide, Mitigations averages 1.1 out of 4.0 — the lowest of the three axes. The natural tendency is to check more capabilities than are genuinely in place, particularly for architectural controls ("we should have this"). Check Mitigations capabilities only if the control is deployed and active in production.

Detection is the easiest axis to inflate. Monitoring dashboards exist in many organisations but are rarely reviewed. If an alert fires but nobody is on call to act on it, the detection capability is partial at best. Check only what is actively monitored with appropriate alerting that reaches someone who can respond.

Response capabilities require actual testing. A runbook that has never been executed is not the same as a runbook that works. Check Response capabilities where you have confidence the procedure would actually succeed under pressure, not merely that the document exists.

For enabling domains, answer at the organisational level. Governance, Personnel, and Incident Management sub-domains describe organisational practices, not individual behaviours. Answer for what the organisation has formally adopted and consistently applies — not for what a particular team or individual does.