SI-13 predictable failure prevention explained

What SI-13 predictable failure prevention asks an organization to do

SI-13 asks an organization to find out how long its critical system components are likely to run before they fail, and to have replacements ready so that a predictable failure is swapped out before it becomes an outage. Because no SP 800-53B baseline includes SI-13, an organization only carries it when its tailoring decisions or an overlay select it, so the first task is to record that decision and the reason for it in the system security and privacy plan. The control has two parts. The first is determining mean time to failure for defined system components in specific environments, meaning the organization names the components that matter (for example, storage arrays, power supplies or network appliances), states the operating environment, and produces a failure estimate for each. The second is providing substitute components and a means to exchange active and standby components according to defined criteria, which means keeping spares or standby capacity and writing down the conditions under which a swap happens.

The outage risk is straightforward: a component that is known to wear out on a roughly predictable schedule can take a service down if nobody acts on that knowledge. The control's organization-defined parameters let the organization set the component list, the environments and the substitution criteria, and its five enhancements (four active, one withdrawn in Release 5.2.0) add further detail. The organization owns these choices. Confirm the current enhancement wording in the CPRT or OSCAL catalog rather than relying on older summaries. The work is hard for two practical reasons. Component inventories are often incomplete, especially for hardware that sits outside the main asset register, and failure data such as replacement dates, fault logs and vendor return records is rarely kept in a form that supports an estimate. Start by confirming which inventory is authoritative and whether failure history exists for the components you intend to name.

Which components and teams SI-13 scoping changes

SI-13 has no baseline assignment, so the organization decides what it covers. The choices below set how much measurement, spare hardware and coordination the control needs, and each one should be recorded before anyone builds a failure model.

Components defined in scope

SI-13 asks the organization to name the system components whose mean time to failure it will determine. Typical candidates are storage arrays, network devices, compute nodes, power distribution and specialized hardware such as hardware security modules. Scope too broadly and the measurement program becomes unmanageable. Scope too narrowly and an outage in an unlisted component falls outside the control. Ask which components the system's availability requirements actually depend on, and document the list with its rationale.

Environments that produce failure data

MTTF values are only meaningful for the environment that produced them. A component running in a production data center, a disaster recovery site and a test lab can fail at different rates because of load, cooling and maintenance practice. SI-13 requires the organization to determine MTTF in specific environments, so the scope must name them. Check that monitoring covers each named environment, and that failure records from one site are not silently reused for another.

Teams that own substitutes and spares

The control requires substitute components and a way to exchange active and standby components. Those duties sit with whoever manages hardware lifecycle, which is often infrastructure operations, not the security team. Name an accountable owner for each spare pool, the procedure for swapping an active unit to standby, and the people authorized to perform it. Without named owners, the substitution mechanism exists on paper but nobody acts on it during an incident.

Substitution criteria and thresholds

SI-13 expects the organization to define criteria that trigger substitution of a component before it fails. These criteria turn MTTF data into action, for example a replacement interval or a threshold tied to observed error rates. Assessors look for these criteria as a named document, so record which measurements trigger which action and who approves the change. Confirm that the thresholds were set from the organization's own failure data, not copied from a vendor datasheet.

Cloud and third-party managed components

Many components are operated by a cloud provider or an outsourced data center, so the organization cannot read their failure history directly. The organization still owns the control for the system it authorizes, so it must decide how to address these components: request MTTF or availability data from the provider, rely on the provider's contingency evidence, or record the gap as a risk. Review the contract and service documentation before assuming coverage, and confirm what the provider will share.

FedRAMP-bound systems must select SI-13

FedRAMP's Rev5 baselines do not require SI-13 at Class B, C or D. A FedRAMP-bound system therefore does not inherit the control from the baseline, and the organization must select it deliberately through tailoring and document the decision in the system security plan. If the authorizing body expects it, the selection should be justified in writing. Confirm the requirement with the authorizing official before scoping, because an unselected control that an assessor later expects becomes a finding.

How an assessor tests SI-13 and what they ask for

This table maps the two SP 800-53A determination statements for SI-13 to the examine, interview and test methods, lists the examine objects and notes where assessments usually stall. Read it as a checklist of what to prepare before an assessor arrives, since the organization owns the control and only an independent assessor reaches a finding.

Assessment element	What the assessor checks	Evidence to have ready	Common finding
Determination statement 1: MTTF determination	Whether the organization has determined mean time to failure for the defined components in the defined environments, using a documented method	MTTF calculation method, source failure data for each defined component, environment definitions	MTTF figures quoted with no source data or no stated environment
Determination statement 2: substitution and exchange	Whether substitute components exist and whether active and standby components can be exchanged according to the defined criteria	Documented MTTF substitution criteria, standby inventory, exchange procedure	Components listed as defined but no substitution criteria written
Examine: MTTF substitution criteria	That the criteria exist, are approved, name the trigger for replacement and match the organization-defined parameters	Approved criteria document with version and review dates	Criteria that restate the control rather than set a threshold or trigger
Examine: system design documentation	That the design shows which components are standby, how they connect and how the switchover is meant to happen	Architecture diagrams, failover design, standby component register	Diagrams that omit standby hardware or cloud failover paths
Examine: system configuration settings and documentation	That configuration matches the design, for example replication, health checks and failover settings	Configuration exports, change records, settings tied to the documented design	Configuration drift from the design with no change record
Examine: system audit records	That exchanges between active and standby components are logged and can be traced to a date, a reason and an operator	Log exports of failover events, maintenance tickets, time stamps	No logged exchanges, so an assessor cannot confirm that exchanges happened
Interview	That operations, platform and maintenance staff can explain how MTTF is tracked and when a standby is used	Named owners, runbooks, staff who can walk through a recent event	Staff unsure who owns the MTTF figures or where they are kept
Test	That an exchange of active and standby components can be run and produces the expected result	Test plan, test record, result and any corrective action	Standby components never exchanged in a test, so readiness is unproven

How to implement SI-13 in six steps

This sequence moves SI-13 from a policy statement to a working practice: it names the components that matter, measures how long they last, prepares replacements before they are needed, and proves the swap works on a schedule. Each step produces a record an assessor can examine.

Define components and environments in scope
Start by listing the system components whose failure would cause an outage or degrade a critical function, such as storage arrays, network appliances, hypervisor hosts, load balancers or database nodes. For each one, record the environment it runs in (production, disaster recovery, air-gapped network) because failure behavior differs between them. The organization owns this decision, and the system owner signs off. The output is a component list with environment tags and a short justification for each inclusion, which becomes the scope statement for SI-13.
Set the MTTF method and data sources
Decide how mean time to failure will be calculated for each component class and where the raw data will come from. Options include vendor reliability data, your own failure history from incident tickets, and hardware lifecycle records. Write down the formula, the minimum observation period you will accept before trusting a figure, and how you will treat components with little history. Confirm with each vendor which reliability figures they publish and under what conditions. The output is a method note approved by the operations owner, which an assessor can compare against the figures you later report.
Document substitution criteria
Write the criteria that trigger an exchange of an active component for its standby, such as a MTTF threshold reached, a degraded health signal, a failed health check or a scheduled lifecycle end. Define who authorizes the exchange, the maximum acceptable time the service may run degraded, and the rollback conditions. Link each criterion to the components in step one. The output is a substitution criteria document, reviewed by operations and the system owner, that states exactly when an exchange happens and who decides.
Provision and register standby components
Provision substitutes that match the active components in capability and configuration, and record where each one sits, including site, rack, network segment and the configuration baseline it runs. Confirm that the standby is compatible with the workload and that it is kept in a state the criteria allow you to use. Where an active component is in cloud infrastructure, record the equivalent replacement resource and its configuration source. The output is a standby register that maps each active component to its substitute, with location, status and last verification date.
Test the exchange and record the result
Run a controlled exchange in a non-production or maintenance window, switching service from an active component to its standby and back according to the documented criteria. Measure whether service continuity held, how long the switch took and whether the monitoring tools registered the change correctly. Record any deviation as a finding with an owner. Confirm the test is performed under change control with approval and rollback steps. The output is an exchange test record for each component class, which shows the criteria and standby work in practice.
Set a review cycle for MTTF and criteria
Schedule a recurring review in which the MTTF figures are recalculated from new failure data, the standby register is checked against the current inventory, and the substitution criteria are confirmed or revised. Define the review frequency in your SI-1 policy and assign an owner. Feed findings into the plan of action and milestones where a gap remains open. The output is a review log showing the date, participants, figures changed and decisions taken, which is the evidence an assessor expects to see that SI-13 is maintained rather than written once.

Evidence that passes an SI-13 test and how to keep it current

An assessor testing SI-13 looks for a defined component list, a documented method for mean time to failure, substitution criteria, design and configuration records, and dated proof that standby components actually take over. The cards below cover each artifact and the routine that keeps it accurate between assessments, because stale failure data is the most common reason this evidence stops being credible.

Defined component list

The organization sets the parameters that name which system components fall under SI-13 and the environments they run in. The list should name each component, its owner, its location and whether it has a standby. Assessors compare this list against the asset inventory, so it must match what is actually deployed. Refresh it whenever a component is added, retired or moved, and record the date and approver of each revision. Confirm your organization's parameter values in its own system security plan before the assessment starts.

MTTF determination method and data

Assessors expect a written method showing how mean time to failure is calculated for each defined component, along with the failure and uptime records that feed it. The method should state the data window, the source of failure events and how components with too few failures are handled. Schedule a recalculation on a fixed cadence, and record when the input data was last pulled so the figures can be traced to a period. Ask the platform owner to confirm which monitoring data sources hold these records.

Substitution criteria

The substitution criteria define when a component is replaced before failure, such as a threshold on MTTF, observed error rates or end-of-support dates. SI-13 examines these criteria directly, so they must be written down, approved and specific enough to test. Review them after each MTTF recalculation and whenever vendor support windows change. Keep each revision with its approval record so an assessor can see which criteria were in force on any given date.

Design documentation for standby components

Design documentation shows which components have substitutes, how active and standby roles are assigned and how traffic or workloads move during an exchange. Diagrams and runbooks should match the deployed topology. When a standby is added, removed or reconfigured, update the design document in the same change window, not at the next audit. Note the platform's monitoring and inventory tools here as well, since they supply the signals that trigger a switch.

Configuration records for active and standby components

Configuration records show the settings that keep standby components ready, including firmware or software versions, replication status, health checks and the alerts that fire when a standby drifts. An assessor may compare these settings with what runs in production. Export configuration snapshots on a schedule and after every change, and store them under change control. Flag any standby that falls behind the active version, because a standby that cannot take over does not meet the intent of the control.

Dated exchange audit records

Audit records of exchanges prove that active and standby components have actually switched roles according to the criteria. Each record should show the component, the trigger, the time, the outcome and the person or automation that approved it. Planned exchange tests, run on a dated schedule, give assessors evidence that the process works before a real failure occurs. Keep the logs in a protected store with retention set by your own policy, and confirm with your logging platform that exchange events are captured.

Open-source tools that produce SI-13 evidence

Prometheus (Apache-2.0) collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series identified by metric name and labels on local storage. For SI-13, that time series history can serve as raw failure and uptime data from which an organization derives its own mean time to failure figures for defined components. Prometheus does not compute MTTF for you, does not know which components are in scope, and does not record why a component failed. Those definitions belong to the organization.

Failure data source: Export health and error metrics from the defined components, so each failure or restart has a timestamp and labels that identify the component.
Query evidence: PromQL queries can show availability and failure counts over the review period, which an assessor can examine alongside the MTTF method.
Local storage limits: Local storage is autonomous, so retention and backup of the time series are your responsibility. Confirm the retention window meets your review cycle.
Licensing: Apache-2.0 permits use and modification, but confirm that any exporters or add-ons you deploy carry licenses your policy accepts.

Confirm with your platform team that the metrics you collect actually capture the component failures SI-13 targets, and that the query outputs can be retained as assessment evidence.

What meeting SI-13 costs in money and effort

This table breaks down the cost and effort components of implementing SI-13 Predictable failure prevention, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build the questions you put to vendors, your staff budget and your auditor before you commit to a scope. No cost or duration figures are given because none were supplied for this control.

Cost component	One-time or recurring	What drives it	What to request in a written quote
Standby hardware or licensed substitutes	One-time purchase, then recurring support and renewals	Number of components in the MTTF scope, redundancy model chosen, vendor support tier, and whether spares are on site or contracted	Itemized list of spares, support terms, replacement lead times and renewal pricing for each year
Engineering time to define components and MTTF method	One-time, with revisions when systems change	Number of component classes, heterogeneity of the environment, and how much design documentation already exists	Named deliverables: component list, MTTF method, substitution criteria and the staff roles assigned
Data collection and monitoring tooling	Recurring operating cost, plus one-time setup	Volume of telemetry, retention period, number of data sources, and whether self-hosted open-source tools replace paid licenses	Confirmation of which tools are licensed versus open source, hosting needs, and the staff hours for setup and tuning
Staff time to operate open-source tooling	Recurring	Team size, on-call model, and how often MTTF data and alerts are reviewed	Estimated operating hours per month from the implementer, stated as an assumption to be confirmed in your environment
Recurring evidence upkeep	Recurring	Frequency of component changes, how often MTTF records are refreshed, and how the substitution criteria are kept current	A schedule of evidence refreshes and the owner for each record
External review of the design	One-time per review cycle, recurring if the design changes	Scope of review, whether the implementer or a separate reviewer performs it, and how many revisions are needed	Review scope, reviewer qualifications and what the report will and will not cover
Auditor sampling and testing time	Recurring at each assessment cycle	Number of components sampled, quality of existing evidence, and whether examine, interview and test methods are all used	The auditor's own fee basis, sample approach and the evidence list they expect before fieldwork

Who does what for SI-13: your team, a partner and the auditor

Your organization owns SI-13 in full. SP 800-53 expects the organization to determine mean time to failure for the components it defines, decide which components need substitutes and set the criteria for exchanging active and standby components. Those decisions depend on your mission, your outage tolerance and your risk appetite, so no outside party can make them for you. Your team also keeps the control working after go-live, because failure rates change as hardware ages and workloads shift.

Set the MTTF criteria: Decide which components are in scope, which environments apply and what failure rate or age triggers replacement.
Own the substitution rules: Define when a standby takes over, who approves the switch and how the switch is recorded.
Review the results: Read MTTF trends and standby readiness reports on a schedule and act on the findings.
Approve the documentation: Sign off the system design documentation and the MTTF substitution criteria that assessors will examine.

Confirm with your own risk and infrastructure owners which components you will classify as in scope before any partner begins work on tooling.

Questions buyers ask about SI-13 cost, effort and outside help

Is SI-13 required by default under NIST SP 800-53?

No. SI-13 is not assigned to any SP 800-53B baseline, so it applies only when your organization selects it through tailoring or an overlay, or when a contract, authorizing official or other requirement names it. Appendix C of SP 800-53 marks it as implemented by the organization and as an assurance-related control. Start by reading your system's selected baseline and any overlay, then record whether SI-13 was selected and why. If it was not selected, the decision and its rationale belong in your documentation, not silence. Confirm the tailoring position with whoever owns your authorization package before planning any work.

How much effort does SI-13 take, and what drives it?

Effort depends mainly on how many components the selection covers and how much of their reliability data already exists. The control asks you to determine mean time to failure for defined components in specific environments and to provide substitute components and a way to exchange active and standby units under defined criteria. Drivers include the number of defined components, whether failure history is recorded in a monitoring or inventory system, how many environments differ, how standby hardware or capacity is provisioned, and how well the failover procedure is documented and exercised. Ask the provider to break effort down by component class and by environment.

How long does SI-13 work take?

Duration is set by the scope agreed in writing, not by the control itself. Timing depends on whether you already have inventory data, historical failure records and tested standby arrangements, and on how quickly your staff can review MTTF criteria and approve substitution rules. Change windows for hardware or cloud capacity, procurement lead times for spare components and any dependency on contingency planning work all extend the schedule. Ask for a milestone plan that separates data collection, criteria definition, configuration, and evidence capture so you can see which steps you control.

What does the work need from our staff?

Plan for named owners from infrastructure, operations and the business service that depends on each component. Someone must supply failure and maintenance history, confirm which components are critical, approve the MTTF criteria and substitution rules, and authorize changes to standby arrangements. Engineers need access to monitoring data and configuration records, and the risk owner must accept the residual position. Because these roles belong to your organization, an implementation partner can prepare the analysis and draft documents, but decisions and sign-off remain internal.

Can our team implement SI-13 in-house with open-source tools?

Often yes, if you have the engineering capacity and a clear scope. Prometheus collects metrics from instrumented jobs over HTTP and stores them as time series, which can support component reliability analysis. Grafana Alerting builds alert rules from queries across data sources and can alert on metrics and logs together, which helps detect degradation before failure. GLPI's Assets module records computers, network equipment, racks and other components, and Wazuh Syscollector collects hardware and software inventory from endpoints. Confirm that each tool captures the failure and replacement history your MTTF criteria need, since none of these tools determines MTTF on its own.

What should we ask for in a fixed-scope quote?

Ask for a written scope that names the components, environments and systems in the SI-13 selection, and the deliverables for each: MTTF criteria, substitution rules, system design documentation, configuration settings, and sample audit records. Confirm which activities the provider performs, which you perform, and what assumptions apply, such as access to historical data and change windows. Request the acceptance criteria, the change process for scope adjustments, and whether monitoring configuration or testing of standby exchanges is included. Ask how evidence will be packaged for your assessor.

Who issues the assessment result for SI-13?

An independent assessor issues the assessment result, not the implementation partner or your own team. Assessors test SI-13 using SP 800-53A procedures, which examine documentation, configuration and audit records and may interview staff. Your organization owns the control and its risk decision, and an authorizing official or the contracting body decides whether the control is acceptable. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue audit reports, attestations or certifications.

How DeployOpen scopes and prepares SI-13 evidence

DeployOpen works on SI-13 Predictable failure prevention as an implementation partner. We help define which components are in scope, set up the monitoring and standby records the control asks for, and document the results so your team and your assessor can review them. Your organization owns the control, and only an independent assessor issues findings.

How we scope

Agree in writing which system components fall under SI-13 and the environments they run in.
Confirm with your organization whether SI-13 is selected through tailoring or an overlay, since no SP 800-53B baseline includes it.
Record the organization-defined parameters and substitution criteria your assessor will examine before work starts.

How we build

Configure self-hosted monitoring so mean time to failure can be measured for the scoped components.
Prepare a documented inventory of standby and substitute components, with the criteria for swapping active and standby units.
Test the failover and exchange procedure in a non-production environment and record the results for review.

How we hand over

Deliver system design documentation and configuration records that show how the failure prevention design works.
Provide audit records and monitoring exports that map to the examine objects in SP 800-53A for SI-13.
Walk your team through the evidence package so your organization can maintain it after the engagement ends.

How we support

Offer ongoing support and upgrades as a retainer when your organization wants help keeping the records current.
Review evidence again after significant configuration or hardware changes so documentation stays accurate.
Confirm with your assessor which evidence format and retention period they expect before the assessment begins.

SI-13 Predictable failure prevention