SI-22: Information Diversity

The si-22: information diversity requirement means you must pre-identify alternative sources for specific mission/business-critical information types so operations can continue when a primary source is degraded, biased, unavailable, or compromised. Operationalize it by building and maintaining an “information source diversity register” tied to key decisions, owners, triggers for switching sources, and recurring evidence.

Key takeaways:

• Scope SI-22 to the information types that drive security, operational, or mission decisions, not to “all data.”
• Document primary and alternative sources, plus criteria and procedures to switch between them, and test the switch.
• Evidence matters: auditors will look for a maintained register, ownership, decision linkages, and proof the alternatives are usable.

SI-22 sits in the NIST SP 800-53 System and Information Integrity (SI) family and focuses on a practical problem: your organization depends on information feeds (internal and third party) to make decisions, detect threats, manage safety, and run operations. If those feeds fail or become untrustworthy, you can make bad calls quickly. SI-22 asks you to plan ahead by identifying alternative sources of information for defined information needs.

For a Compliance Officer, CCO, or GRC lead, the hard part is keeping SI-22 concrete. Teams often mistake it for a generic “data quality” initiative, or they treat it as an IT-only task. In practice, SI-22 is a resilience and integrity control: define the information you cannot afford to lose, identify independent alternatives, and prove you can pivot to them under pressure.

This page gives requirement-level implementation guidance you can execute quickly: scoping, governance, step-by-step buildout, evidence to retain, and the audit questions you should be ready to answer. Citations reference the NIST control catalog and NIST’s 800-53 Rev. 5 publication page. ¹

Requirement: SI-22 Information Diversity (what it means operationally)

SI-22 requires you to identify alternative sources of information for defined information needs so decisions and controls do not depend on a single source that could be incomplete, manipulated, unavailable, or biased. The operator outcome is simple: for each high-impact information input, you can point to at least one viable backup source and a documented way to use it.

Treat SI-22 as a “dependency mapping” control for information inputs:

• Information need (what decision/control depends on it)
• Primary source (system, team, third party, feed)
• Alternative source(s) (independent where possible)
• Switch criteria (when you stop trusting primary)
• Operating procedure (how you pivot and how you validate)

This becomes especially relevant where third parties provide critical intelligence or operational inputs (threat intel feeds, fraud scoring, sanctions screening, credit data, identity verification, OT sensor vendors, cloud control plane logs).

Regulatory text

“Identify the following alternative sources of information for {{ insert: param, si-22_odp.02 }}: {{ insert: param, si-22_odp.01 }} ; and” ²

How to read this as an operator: the catalog text is parameterized, meaning your system authorization boundary (and your tailoring decisions) define (1) what information types or information needs are in scope and (2) what alternative sources must be identified. Your job is to fill those parameters with a defensible, documented list and keep it current. ¹

Who SI-22 applies to (entity and operational context)

Entity types commonly in scope

• Federal information systems.
• Contractors handling federal data (including cloud and SaaS providers supporting federal programs). ²

Operational contexts where SI-22 is easiest to justify (and easiest to fail)

• Security monitoring that relies on one telemetry source (only EDR, only cloud logs, only SIEM ingestion).
• Fraud/AML/KYC programs dependent on a single third-party data provider.
• Safety or availability operations dependent on one sensor type, one facility monitoring system, or one OT vendor portal.
• Incident response decisioning based on a single “source of truth” without corroboration.

Plain-English interpretation (what auditors expect you to have done)

An assessor typically wants to see three things:

1. You defined which information needs matter (the “for what”).
2. You named alternatives (the “from where else”).
3. You made it operational (owners, procedures, and proof you can actually use the alternatives).

If you only produce a list of “other sources” without decision linkages and operating procedures, SI-22 will look like shelfware.

What you actually need to do (step-by-step)

Step 1: Set the scope using decision-driven “information needs”

Start with the decisions that can create material harm if based on bad or missing information:

• Block/allow access decisions
• Detect/contain incidents
• Release approvals (change management)
• Customer onboarding / transaction approvals
• Safety shutdown decisions
• Regulatory reporting inputs

Deliverable: a short list of “information needs” and their dependent processes.

Step 2: Build an Information Source Diversity Register (ISDR)

Create a register (spreadsheet, GRC module, or CMDB-adjacent record) with fields:

Field	What “good” looks like
Information need	Named and tied to a process/control
Decision owner	A role, not a person (e.g., SOC Manager)
Primary source	System/feed/team/third party
Alternative source(s)	Specific and accessible
Independence note	Explain if alternatives share upstream dependencies
Switch triggers	Clear criteria (integrity, availability, timeliness)
Validation method	How you confirm the alternative is trustworthy
Runbook link	Where the procedure lives
Test evidence	Date, outcome, and issues found
Review cadence	How you keep it current (choose a cadence you can sustain)

Practical tip: Start with the top few information needs where downtime or manipulation would drive immediate operational risk (SOC, fraud, payments, identity, OT monitoring).

Step 3: Define “alternative source” standards (so teams don’t game it)

Write a one-page standard that answers:

• What qualifies as an alternative source?
• Can it be a different view of the same system (e.g., host logs vs. network logs)?
• When do you require a different third party vs. an internal corroboration source?
• What minimum access is required (credentials, API keys, licensing, retention)?

This prevents weak entries like “ask someone on Slack” or “check the same dashboard in another browser.”

Step 4: Assign control ownership and embed into procedures

Map SI-22 into:

• Control owner: typically Security GRC, Security Operations leadership, or Risk (depends on your org model).
• Process owners: SOC, IAM, Fraud, AML, SRE/Infra, OT Ops, depending on the information needs.

Update the procedures people already follow:

• Incident response runbooks should reference secondary sources for key facts (scope, affected assets, timeline).
• Monitoring playbooks should include fallback telemetry sources when primary log pipelines fail.
• Third-party management should capture “single-source dependency” as a risk and require alternatives for critical feeds.

Daydream (as a workflow system) fits naturally here by assigning SI-22 ownership, tracking the register as a living artifact, and scheduling recurring evidence collection tied to the control record.

Step 5: Prove the alternatives work (tabletop or technical test)

For each high-impact information need, run a simple scenario:

• Primary source unavailable (outage, access revoked, ingestion broken).
• Primary source integrity in question (data poisoning, misconfiguration, known-bad vendor update).
• Time sensitivity mismatch (primary delays, alternative is faster).

Capture whether the alternative source provided enough fidelity to support the decision. Log gaps as remediation items.

Step 6: Operational maintenance (change and third-party events)

Your register goes stale unless you tie updates to:

• New systems and integrations (architecture review gate)
• Vendor onboarding/offboarding (third-party risk intake)
• Major incidents (post-incident review item: “did SI-22 alternatives work?”)
• Logging/telemetry changes (SIEM routing, EDR agent migrations)

Required evidence and artifacts to retain

Keep evidence that shows design and operation:

Core artifacts

• SI-22 control statement and scope definition (tailoring decision for what information needs are covered). ²
• Information Source Diversity Register (current version + change history).
• Runbooks or SOP excerpts showing switch procedures.
• Access evidence that alternatives are reachable (permissions, subscriptions, backup credentials escrow process where applicable).
• Test records: tabletop notes, drill reports, ticket links, and outcomes.

Nice-to-have artifacts (helps in audits)

• Architecture diagrams showing telemetry/data flow diversity.
• Third-party risk records showing single-source dependency analysis for critical third parties.
• Post-incident review notes referencing alternate sources.

Common exam/audit questions and hangups

Expect questions that probe whether your “alternatives” are real and usable:

• “What information needs did you define for SI-22, and why these?” ²
• “Show me the alternative sources for your security event detection inputs.”
• “If your primary third-party feed is down, what do you do in the first hour?”
• “How do you know the alternative source is independent and not the same upstream data repackaged?”
• “Who can approve switching sources, and where is that documented?”
• “When did you last test a switchover, and what failed?”

Audit hangup to avoid: teams point to disaster recovery for systems, but SI-22 is about information inputs, not server failover.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating “alternative source” as “backup storage.”
   Fix: focus on decision inputs (facts you need) and sources for those facts.

2. Mistake: listing alternatives that are not accessible in an incident.
   Fix: verify credentials, licensing, network access, and retention before you claim it as an alternative.

3. Mistake: alternatives share the same upstream dependency.
   Fix: document dependency chains. If both sources depend on the same third party API, you still have a single point of failure.

4. Mistake: no switch triggers, so nobody knows when to distrust primary.
   Fix: define integrity and availability triggers (data gaps, conflicting indicators, vendor advisory, ingestion failures) and put them in runbooks.

5. Mistake: register is created once, then ignored.
   Fix: attach it to change management and third-party lifecycle events; assign an owner responsible for refresh.

Risk implications (why SI-22 shows up during incidents)

SI-22 is a control against:

• Operational disruption: loss of monitoring or decision inputs stalls response.
• Integrity failures: manipulated or biased information drives wrong actions.
• Third-party concentration risk: a single provider becomes a hidden systemic dependency.

From a governance perspective, SI-22 gives you a defensible answer to “what do we do if we can’t trust this feed/system/vendor?”

Practical execution plan (30/60/90)

You asked for speed. Here is a plan you can run without waiting on a major tooling project.

First 30 days (stand up the minimum viable SI-22)

• Name a SI-22 control owner and define in-scope information needs (start with security monitoring + one business-critical decision process). ²
• Draft the Information Source Diversity Register template and populate initial entries with process owners.
• Write a one-page “what qualifies as an alternative source” standard.
• Identify at least one gap where an alternative source is missing; create a remediation ticket.

Days 31–60 (make it operational)

• Add runbook steps for switching sources in incident response / operations playbooks.
• Validate access to alternative sources (permissions, subscriptions, credential handling).
• Run a tabletop that forces teams to use the alternative source and document outcomes.
• Add an intake question to third-party onboarding: “Does this create a single-source information dependency? If yes, what is the alternative?”

Days 61–90 (make it audit-ready and durable)

• Expand scope to additional information needs (fraud/AML, identity, SRE, OT, depending on your environment).
• Add governance hooks: architecture review and change management require an ISDR update for relevant changes.
• Establish recurring review ownership (calendar + ticket automation).
• Centralize evidence collection in your GRC system (Daydream or equivalent) so the register, tests, and runbooks are versioned and easy to produce.

Frequently Asked Questions

What counts as an “alternative source” under SI-22?

An alternative source is a distinct way to obtain the same decision-critical information when the primary source is unavailable or untrustworthy. It can be an internal corroborating signal (e.g., network logs vs. endpoint logs) or a different third party, as long as you can access and use it in practice. ²

Do I need two third-party providers for every critical data feed?

SI-22 does not state “two vendors,” it requires you to identify alternative sources for defined information needs. For some needs, an internal source or a different telemetry layer is a valid alternative; for others, third-party concentration risk may justify a second provider.

How do I scope SI-22 without making it unmanageable?

Scope by decision impact: start with information needs tied to incident detection/response and one or two business processes where bad inputs cause immediate harm. Expand as you mature, but keep the register tied to real decisions and owners.

How do auditors test SI-22?

They usually sample a few high-impact information needs and ask you to show the alternative sources, the runbook for switching, and evidence you reviewed or tested it. They also check that the register is current and owned. ²

We have a SIEM and a data lake. Doesn’t that satisfy information diversity?

Not automatically. A SIEM and data lake often share the same upstream ingestion pipelines, so an ingestion failure can break both. Map your upstream dependencies and confirm you have independent ways to obtain key facts (or at least a documented fallback path).

What evidence is “enough” to show SI-22 is operating?

Keep the register, ownership assignments, runbooks, and records of at least one exercise where teams attempted to use alternatives. Also retain proof that access to alternatives exists (accounts, subscriptions, permissions) so you can demonstrate feasibility during an assessment.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON; NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON