SI-22: Information Diversity

Quick-reference card

What this control requires

SI-22 requires organizations to identify alternative sources of information that can sustain essential functions and services when a primary source becomes corrupted or unavailable. In practice, this control asks you to build redundancy into the information inputs that drive critical system actions, so that no single point of data failure can halt operations.

The requirement has two parts. First, you must catalog the essential functions and services that depend on external or internal information feeds, then map each one to at least one alternative source. Second, you must configure systems and components to switch to those alternative sources when the primary feed is compromised. This isn’t limited to disaster recovery scenarios. Any corruption, fabrication, or deletion of input data that changes how a system behaves falls within scope.

The underlying principle is cyber resilience. Most organizations design redundancy into infrastructure (failover servers, backup power) but overlook the data pipelines that inform automated decisions. SI-22 closes that gap by requiring you to treat information inputs with the same resilience planning you’d apply to hardware or network connectivity.

Why it matters

Most compliance frameworks focus on protecting data at rest and in transit. SI-22 addresses a less visible risk: what happens when the information your systems rely on to make decisions is wrong, missing, or manipulated. Failure to maintain this control introduces audit risk during NIST SP 800-53 assessments, particularly for organizations operating systems where automated actions depend on external data feeds.

In practice, the absence of information diversity means a single corrupted data source can cascade into flawed automated responses across an entire environment. Security tools that depend on a sole threat intelligence feed, identity systems that rely on one directory source, or operational technology that consumes a single sensor stream all represent concentrated points of failure. Auditors evaluating your system and information integrity posture will look for documented evidence that you’ve planned for these scenarios.

The risk compounds in environments where organizations don’t distinguish between data availability and data integrity. Backup systems restore access to data, but they don’t protect against a scenario where the primary source is still online and actively delivering corrupted information. SI-22 specifically targets this gap.

What attackers exploit

• Single-source dependency in threat intelligence feeds: Adversaries who compromise or manipulate a sole threat intelligence source can blind defensive tools, causing them to miss indicators of compromise or misclassify malicious activity as benign.
• Poisoned training data or decision inputs: Automated systems that consume a single data pipeline for policy enforcement or anomaly detection are vulnerable to data injection attacks that alter system behavior without triggering alerts.
• DNS or configuration source manipulation: Attackers who gain control of a primary DNS resolver or configuration management source can redirect system behavior organization-wide when no alternative source exists to validate or override the compromised input.
• Supply chain data feed compromise: Third-party data providers that serve as the sole source of pricing, inventory, or compliance information create a dependency that adversaries can exploit to manipulate downstream business logic.

How to implement

The most common failure mode with SI-22 isn’t a lack of alternative sources. It’s that organizations identify alternatives on paper but never test whether their systems can switch to them under real conditions.

For your organization

Start by inventorying every essential function or service that depends on information inputs to operate. This includes automated security responses, identity and access management decisions, operational technology controls, and any system where the output changes based on the data it receives. Document each primary information source alongside the function it supports.

Next, identify at least one alternative source for each primary input. Alternative sources don’t need to match the precision or update frequency of the primary feed. A slightly less granular threat intelligence feed, a cached local copy of configuration data, or a secondary DNS resolver all qualify as long as they provide sufficient quality for the function to continue operating. The goal is degraded operation over total failure.

Configure your systems to detect when a primary source is corrupted or unavailable and to switch to the alternative automatically or through a documented manual process. This means defining what “corrupted” looks like for each data type, whether that’s a failed integrity check, an unexpected data format, or a timeout threshold.

Test the switchover process at least annually. Include information diversity scenarios in your tabletop exercises and incident response drills. Document the results and any gaps you discover.

Common tooling categories that support this control include data validation and integrity monitoring tools, configuration management platforms with multi-source support, and redundant DNS or directory service architectures.

Common mistakes to avoid:

• Listing alternative sources in documentation without configuring actual failover mechanisms
• Assuming data backups satisfy the requirement (backups restore availability, not integrity of live inputs)
• Failing to define detection criteria for when a primary source is compromised versus temporarily unavailable
• Neglecting to test switchover processes after initial implementation

The Breach Risk product can help identify external-facing systems where single-source information dependencies create exploitable gaps in your attack surface.

For your vendors

When assessing vendors against SI-22, focus your questionnaire on whether they’ve moved beyond theoretical documentation into operational practice.

Questionnaire questions to ask:

• Which essential functions or services in your environment depend on external information sources?
• Have you identified and documented alternative information sources for each essential function?
• What mechanisms detect corruption or unavailability of primary information sources?
• How frequently do you test failover to alternative information sources?
• Can you provide evidence from a recent switchover test?

Evidence to request:

• System design documentation showing primary and alternative information source mappings
• Configuration settings demonstrating automated or manual failover mechanisms
• Test results from the most recent information diversity exercise
• System and information integrity policy addressing alternative information sources
• List of information sources with their classification (primary versus alternative)

Red flags:

• The vendor can’t name specific alternative sources for their critical functions
• Documentation lists alternative sources but has no corresponding configuration or test evidence
• Failover testing hasn’t occurred in the past 12 months
• The vendor conflates data backup and recovery with information diversity

Verification approach:

Request both the policy documentation and the technical configuration evidence. A vendor that can produce a system and information integrity policy but can’t show configuration settings or test results likely has a documentation-only implementation. Cross-reference the list of essential functions against the list of alternative sources to confirm coverage.

Vendor Risk assessments can streamline questionnaire distribution and evidence collection when evaluating vendor compliance with controls like SI-22.

Evidence examples

Cross-framework mapping

No applicable content for this control.

Related controls

No applicable content for this control.

Frequently asked questions

What is NIST SP 800-53 SI-22?

SI-22 is a NIST SP 800-53 control that requires organizations to identify and maintain alternative information sources for essential functions so operations continue when a primary source is corrupted or unavailable. It falls within the System and Information Integrity family and applies to both organizational systems and vendor environments. The control addresses a specific resilience gap: ensuring that the data inputs driving automated system actions have fallback options, not just the infrastructure itself.

What happens if SI-22 is not implemented?

Without SI-22, a single corrupted or unavailable information source can disrupt essential functions across your environment with no fallback mechanism in place. Auditors reviewing your system security plan will flag the absence of documented alternative information sources and failover configurations as a control deficiency. The risk extends beyond audit findings. Systems that consume poisoned or fabricated data from a compromised primary source will continue executing flawed actions without any integrity check from an alternative feed.

How do you audit SI-22?

Auditing SI-22 starts with verifying that the organization maintains a current list of information sources mapped to essential functions, with each primary source paired to at least one documented alternative. Assessors then review system configuration settings to confirm that failover mechanisms are implemented, not just documented. Test records from information diversity exercises demonstrate whether switchover works under simulated failure conditions. The audit also examines system design documentation to verify that detection criteria for source corruption or unavailability are defined and operational.

What are examples of alternative information sources under SI-22?

Alternative information sources include secondary threat intelligence feeds, cached local copies of configuration data, redundant DNS resolvers, backup directory services, and fallback sensor data streams. These sources don’t need to match the precision of the primary feed. A slightly less granular data source that allows an essential function to continue operating in a degraded mode satisfies the control requirement. The key criterion is that the alternative source provides sufficient data quality for the function to execute its intended actions, even if at reduced accuracy or timeliness.