SI-22 Information diversity: requirements and evidence

What SI-22 information diversity asks for and when it applies

If you are selecting or tailoring SP 800-53 controls and have found SI-22, note first that no SP 800-53B baseline assigns it. SI-22 requires an organization to identify alternative information sources for defined essential functions and services, and to use them when the primary source is corrupted or unavailable. It applies only when you select it through tailoring or an overlay, and Appendix C of SP 800-53 Rev. 5 lists it as implemented by the organization and the system, marked as an assurance-related control.

The control addresses a simple failure pattern: a single source of information that an essential function depends on can be corrupted, poisoned or cut off, and everything downstream inherits the error or the outage. Examples include a single threat feed, one authoritative data store, or one time or reference source that a decision process trusts without a second opinion. In Release 5.2.0, SI-22 carries 3 organization-defined parameters and no control enhancements, so the requirement is shaped almost entirely by the decisions you record. The parameters are where you name the essential functions, the sources and the conditions that trigger a switch, and an assessor will test those choices rather than a fixed list.

Two decisions are usually the hard part. The first is defining essential functions narrowly enough to be testable, since a function that is "everything the platform does" cannot be given alternatives in practice. The second is identifying a source that is genuinely independent of the primary one. A second copy hosted on the same vendor, network or credentials often fails independence under examination. Confirm the parameter values and the source inventory with your authorizing official or risk owner before implementation, and confirm with your assessor how they will read independence in your environment.

Which systems, data and third parties SI-22 reaches

SI-22 has no baseline assignment, so its reach is set by the organization's own impact analysis and tailoring. The cards below cover the decisions that determine how much work the control creates, and they connect because each one changes which sources must have an alternative.

Essential functions defined by the organization

SI-22 requires the organization to define the essential functions and services it applies to. This list is the root of scope, and it should come from the impact analysis and mission or business priorities, not from a template. Check whether each function has a documented recovery expectation, which owner signs off on it, and whether the definition is reviewed when systems or services change. A narrow list keeps the control small. A broad list turns every data feed into a diversity question.

Primary information sources behind each function

For each essential function, record the information it depends on: market or transaction feeds, reference and master data, authoritative registries, threat intelligence, and time sources. Write down where each one originates and who operates it. This inventory is the evidence that the SI-22 determination statement about list of information sources can be tested. Without it, the organization cannot show which sources are primary and which alternatives exist.

DNS and time as dependency chains

DNS resolution and network time are easy to overlook because they sit under many systems. Map which resolvers and time sources each essential function uses, including internal forwarders and upstream servers. Check whether a second resolver or time source exists outside the same failure domain, and whether systems fall back safely when the primary is corrupted rather than simply unavailable. Document the design so an assessor can compare it with the stated sources.

Consuming systems and their configuration

Identify each system that reads a selected source, including applications, batch jobs, security tooling and reporting pipelines. The control is tested partly through system configuration settings, so the switchover logic must be visible in configuration, not only in a runbook. Check how each consumer detects a bad or missing source, which alternative it uses, and whether it can use that alternative without manual rework. Consumers that hard-code one endpoint are common gaps.

Third parties that supply sources

External vendors, data providers, cloud services and public registries often supply the primary source and sometimes the only alternative. Review contracts and service descriptions for availability commitments, change notification and data quality claims. Where an alternative comes from the same provider, record that shared dependency as a risk. Confirm with each supplier what it guarantees and what it does not, because the organization remains accountable for its own essential functions.

Tailoring and overlay decisions

Because SP 800-53B does not assign SI-22 to any baseline, the decision to select it is a tailoring or overlay choice that must be recorded in the system security plan with its rationale. Document which functions were considered and why the control was included or excluded. Assessors will look for that justification alongside the source inventory. Confirm with the authorizing official or governance owner how the decision is approved and reviewed.

How an assessor tests SI-22

This table maps the SP 800-53A assessment methods and examine objects for SI-22 to the evidence an assessor asks for and the findings that commonly follow. Read each row as a question the assessor will put to your team, and use the findings column to check your documentation before fieldwork begins.

Assessment element	What the assessor checks	Evidence to prepare	Common finding
Determination statement 1	The organization has defined the essential functions and services that need alternative information sources, and the defined set is complete and current.	Approved list of essential functions tied to the system boundary, with owner sign-off and review dates	Essential functions are undefined, or the list covers services that no longer exist
Determination statement 2	Alternative information sources are identified for those functions and are used when the primary source is corrupted or unavailable.	Source inventory showing primary and alternative sources, switchover procedure and records of past switchover tests	Alternative source is named in a document but no failover path exists in practice
Examine: list of information sources	The list names each primary and alternative source, its owner and the functions it supports, and matches what the system actually consumes.	Information source register exported from the CMDB or data catalog, with version and last review date	Source list omits feeds added after the last review, such as a new third-party data API
Examine: system design documentation	The architecture shows how the system detects loss or corruption of the primary source and switches to the alternative.	Architecture diagrams, data flow diagrams and failover design notes that reference the same source names as the register	Design shows a single data path, or diagrams and the source list use different names for the same source
Examine: system configuration settings and documentation	Configuration actually points to the alternative source, with health checks or thresholds that trigger switchover.	Configuration files or exports, health check definitions and change records showing when settings were applied	A documented alternative that was never configured, or a configured fallback that points at the primary source
Interview	Personnel who operate the essential function can explain the trigger, the decision owner and the steps to switch sources.	Interview notes or runbook acknowledgments from operators, and a named owner for each essential function	Operators are unaware the alternative exists, or the decision owner is undefined
Test	The switchover works when the primary source is made unavailable or its data is corrupted in a controlled test.	Test plan, test results with timestamps, and a record of corrective actions for any failed step	No test has ever been run, or the test used a copy of data that never exercised the real switch

Implementing SI-22 in sequence

This sequence turns SI-22 from a selected control into evidence an assessor can test: defined essential functions, a documented source inventory, a tested switchover path and records that show each step was carried out. Because SI-22 sits outside every SP 800-53B baseline, the organization must first decide that it applies before any of these steps begin.

Confirm SI-22 is selected and scoped
The control owner, usually the system owner with the information security officer, records why SI-22 is in the control set. Because SP 800-53B does not assign SI-22 to any baseline, it reaches a system only through tailoring or an overlay, so the selection decision and its rationale must be written down. The step closes when the tailoring record or overlay names SI-22 and the system boundary it covers.
Define essential functions and parameters
The organization sets the essential functions and services that must keep working during corruption or loss of information, and assigns values to the three organization-defined parameters in the Release 5.2.0 control text. Business owners, operations leads and the system owner agree on these values, since they determine which sources must have alternatives. The step closes when a signed parameter record lists each function and the parameter values that apply to it.
Inventory primary information sources
Engineers list every primary source that feeds each essential function, such as databases, data feeds, reference data services, sensor streams or identity directories. For each source, they record the owning team, the data it supplies and the functions that depend on it. The step closes when the list of information sources is complete enough that an assessor can trace each essential function back to its inputs.
Identify and document alternative sources
For each primary source, the team identifies an alternative that can supply the same information to the same function, and documents its limits, such as data age, format differences or lower resolution. Where no true alternative exists, the design records that gap and the decision made about it. The step closes when the design documentation pairs every primary source with its alternative or a recorded exception, and the owners of both sources have accepted the pairing.
Configure the switchover mechanism
Engineers implement the detection and switching logic, including how corruption or unavailability is detected, who or what triggers the switch and how the system returns to the primary source. Configuration settings, scripts and runbooks are stored under change control so the state of the mechanism can be reproduced. The step closes when configuration records show the triggers, the target alternatives and the fallback path for each essential function.
Test switching under controlled conditions
The team simulates loss of each primary source, and where practical corruption of its data, then observes whether each essential function moves to its alternative and produces acceptable output. Results are compared against the parameter record, and any failed switch is logged as a finding with an owner. The step closes when test results show each tested function switched successfully or have a documented remediation plan for each failure.
Retain records for assessment
The organization keeps the parameter record, source list, design documentation, configuration records and test results together under the system's documentation set, with dates and approvers. Records are reviewed when sources or essential functions change, so the evidence stays current. The step closes when an assessor could follow the chain from essential function to source, alternative, configuration and test result without asking the team for additional material.

How alternative sources work in a running system

SI-22 asks an organization to plan for the moment its primary information source stops being trustworthy or stops being available, and to keep essential functions running from an alternative. In a running system the pattern has four parts: a primary feed or dataset that the function normally uses, a secondary source that is independent of the primary in supplier, network path or data origin, a mechanism that detects corruption or unavailability in the primary, and a documented decision that says who switches, on what signal, and how the system is switched back. The defined essential functions and the sources for them are organization-defined parameters, so the first task is to list them. For a payment reconciliation job, for example, that might be a rate table or reference dataset and a second copy obtained through a different provider and path. This is an illustrative example, not a requirement for any particular function.

The central test is independence. An alternative that shares the primary's failure mode does not satisfy the intent of SI-22. A second mirror that replicates the same corrupted file, a backup pulled from the same storage array, or a fallback feed that depends on the same DNS zone and certificate authority will fail at the same moment as the primary. Ask for the dependency map of each source, including the upstream provider, the network route, the update pipeline and the credentials used to reach it, and check whether any element is shared. Where a shared element cannot be removed, record it as a residual risk and decide whether the essential function can accept it.

Detection and the switch decision are where assessors look for evidence. The SP 800-53A procedures for SI-22 examine the list of information sources, the system design documentation and the system configuration settings, so the switch logic should be visible in configuration and design records rather than only in someone's memory. Confirm with your own engineering and assurance teams which health checks, integrity checks and thresholds trigger a switch, who may override it, and how a switch is logged and reviewed. Backup tools can support the integrity side of this work. For example, restic's check command with read-data options reads pack files back to confirm stored data is unmodified, but whether that matches a specific information source is a design decision you must make and document.

Evidence that passes an SI-22 assessment

SI-22 is assessed on whether the organization can show which essential functions depend on which information sources, what the alternatives are, and that switching has been configured and tested. The artifacts below connect those answers, and each one needs a named owner and a review trigger so it stays accurate between assessments.

Defined essential functions and parameters

The organization-defined parameters for SI-22 name the essential functions and services that need alternative information, and the conditions that trigger a switch. Keep this as a signed, versioned register that lists each function, its owner, its primary source and the condition for switching. Assessors compare this list against the system design, so any function added to the architecture should appear here before the next review. Confirm the parameter values with the control owner rather than inheriting them from a template.

Register of information sources

The list of information sources is the artifact an assessor examines first. For each essential function, record the primary source, each alternative, the data type, the update frequency, and who is accountable for the source relationship. An alternative that is never refreshed or that depends on the same upstream provider as the primary does not show diversity, so note any shared dependencies explicitly.

System design documentation showing alternatives

Architecture diagrams and data flow documents must show where each alternative source enters the system and how components choose between sources. Assessors look for the switchover path, not just the existence of a second feed. Review these documents whenever a source is added, replaced or moved to a new network segment, and record the date and reviewer of each revision.

Configuration settings and change history

Export the configuration that defines source priority, health checks and failover conditions, then store it under version control. Change history should show who altered a source setting, why, and which approval covered it. Confirm that access to these settings is restricted, because an unauthorized change to source priority can defeat the control without any visible failure.

Records of switchover tests

Test records show that the system actually moves to an alternative source when the primary is corrupted or unavailable. Document the test scenario, the expected behavior, the observed result, the time taken to switch and any data discrepancies found between sources. Re-run switchover tests after every source change and keep the results with the change ticket that triggered them.

Review triggers and currency checks

Between assessments, the register, diagrams, configuration and test records can drift apart. Set review triggers for any change to a source, a new essential function, a change to the upstream provider, or a failed switchover test. A dated review log that links each trigger to the updated artifacts shows an assessor that the evidence reflects the system as it runs today.

What meeting SI-22 costs in money and effort

This table breaks SI-22 costs into components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up. No cost figures are supplied for this control, so use the drivers and quote items to compare written proposals. The main takeaway is that the number of essential functions and sources, not the control text itself, usually sets the size of the work.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Analysis to define essential functions	Organization staff, with optional outside analyst time	One-time, revisited on major change	Number of mission functions and service dependencies in scope
Identifying alternative information sources	Organization and implementation partner	One-time, then on source changes	Number of candidate sources and how many have independent ownership
Engineering to build and configure alternative sources	Implementation partner or internal engineering	One-time build, then recurring maintenance	Integration complexity, data formats and failover design
Licensing for additional data feeds	Third-party data or service providers	Recurring, usually contract-based	Number of feeds, volume, and contract terms for redundant sources
Testing that switching works	Internal teams or implementation partner	Initial test, then recurring exercises	Number of functions tested and how often exercises run
Evidence upkeep	Organization compliance and engineering staff	Recurring	Frequency of source reviews, change records and test reports
Assessor time	Independent assessor, paid by the organization	Recurring per assessment cycle	Scope size, sample testing depth and quality of evidence on hand
Third-party contract review	Legal and procurement staff	One-time per contract, then on renewal	Number of suppliers and whether sources depend on the same provider

How self-hosted backup tools support information diversity

SI-22 asks an organization to identify alternative information sources for essential functions and to switch to them when the primary source is corrupted or unavailable. Backup tools can supply the recovery copy and the evidence that the copy is usable, but they do not define the alternative-source design. The cards below cover what two open-source tools provide and what the organization must confirm.

Bareos job scheduling and supervision

The Bareos Director schedules and supervises backup, restore, verify and archive jobs from one place. For SI-22, this matters because the alternative copy only helps if it is produced on a defined schedule and its job history shows it ran. Check that each essential information source has a backup job, that failed jobs raise alerts, and that the job definitions are kept under change control. Bareos runs in your environment, so you own the schedules and the records.

Bareos catalog and point-in-time restore

Bareos keeps a SQL catalog of the files it has backed up and can restore selected files from the current backup or from one taken before a given date and time. This supports the SI-22 question of whether an earlier, uncorrupted version of a source can be recovered when the current version is damaged. Test restores to a separate location, record the restore point used and the time taken, and confirm that the catalog itself is backed up and protected.

Bareos license and AGPL-3.0-only obligations

Bareos is licensed under AGPL-3.0-only. Before building an alternative-source design on it, have counsel or your license steward confirm what the AGPL terms require if you modify the software or make it available to users over a network. This is a licensing check, separate from the technical design, and it should be complete before the tool becomes part of a documented control.

restic structural checks

restic check verifies the structural consistency of snapshots, trees and pack files in a repository. It shows that the backup metadata is intact, which is necessary before any restore is trusted as an alternative source. Run it on a schedule and store the results with the other control evidence. Confirm that the check output is retained and that failures are routed to the team that owns the repository.

restic read-data verification

With the --read-data or --read-data-subset options, restic check reads pack files back to confirm that the stored backup data is unmodified. This is the stronger check for SI-22 because it tests the content the organization would switch to, not only its structure. Full reads take longer and cost more I/O, so decide with the system owner which sources need a full read and which can use a subset, and document that choice.

Confirming the alternative-source design

Neither tool identifies which information sources are essential, which alternative source applies to each, or how the switch is decided and approved. Those are design decisions the organization must make and document, then test against the SI-22 determination statements and the examine objects, such as the list of information sources and the system configuration settings. Use the tool outputs as recovery evidence for that design, not as a substitute for it.

Who owns SI-22: your team, a partner and the assessor

Your organization owns SI-22 in full. Because the control applies only when you select it through tailoring or an overlay, the first decision belongs to your risk owners: whether SI-22 is in scope at all and, if so, which essential functions and services it covers. Your team then defines the organization-defined parameters the control leaves open and approves each alternative source before it becomes part of a recovery path.

Scope decision: record whether SI-22 is selected, why, and under which baseline, overlay or tailoring decision.
Essential functions: name the functions and services that must keep running when the primary information source is corrupted or unavailable.
Source approval: choose alternative sources, document their owner, and confirm they are independent enough that one failure does not take out both.
Switchover rules: define who decides to switch, how the switch is triggered, and how the team returns to the primary source.
Ongoing ownership: keep the source list current when systems change and review it with the rest of the SI family.

Before relying on a partner or assessor, confirm internally that someone accountable can explain every source on the list and the reason it was chosen.

Where SI-22 programs usually fall short

SI-22 is a short control with a lot of room for paper compliance. Most shortfalls come from alternative sources that were named but never defined, tested or kept current. The cards below cover the gaps assessors most often find and the fix for each.

Essential functions never defined

SI-22 only works once the organization has named the essential functions and services it covers. Many programs skip this step, so there is no list to test against. Ask who owns the list of functions, whether each one has a documented primary information source, and whether the organization can name the alternative for each. An assessor will start with the parameter values, so vague wording here sets up every later finding. Write the functions down before choosing any sources.

Alternatives tied to the same supplier

A backup source that shares a supplier, network path or identity provider with the primary offers little diversity. If one upstream outage or one compromised credential takes out both, the control has failed in practice. Map each alternative source to its supplier, network segment and administrative accounts. Confirm that the alternative remains reachable when the primary's provider or network is down, and document any shared dependency that cannot be removed.

Switchover never tested

A documented fallback that nobody has used is an assumption, not a capability. Test whether systems actually switch to the alternative source, whether data formats match, and whether users notice a difference. Record the test scope, the date, the people involved and the results. Include a case where the primary source is corrupted, not just offline, because corrupted data can pass a simple availability check while still causing harm.

Alternative sources missing from inventory

Sources that were added quickly for a single project often never reach the asset inventory or the system boundary. The assessor then sees an alternative feed that the configuration management and monitoring records do not cover. Reconcile the list of alternative sources against the component inventory and the architecture diagrams. Check that each source has an owner, a documented purpose and the same logging and access controls as the primary.

Evidence not refreshed after changes

Source lists, design documents and configuration settings are examined during an SI-22 assessment. When a new feed, provider or migration changes the design, these records often stay at the version written for the first audit. Tie SI-22 evidence to change control so that every change to a primary or alternative source triggers a review of the source list and the design documentation. Ask for the last review date and the change ticket that triggered it.

Does SI-22 apply to FedRAMP or my baseline?

SI-22 is not part of any SP 800-53B baseline. The low, moderate, high and privacy baselines all leave it out, so an organization that simply adopts a standard baseline does not inherit an obligation to identify alternative information sources. The FedRAMP Rev5 baselines follow the same pattern: they do not require SI-22 at Class B, C or D. For most federal cloud services, SI-22 therefore arrives only if someone chooses to add it. The same is true for a commercial SaaS provider or a regulated firm that starts from a NIST baseline and tailors it.

Selection can still happen for reasons that have nothing to do with the baseline. A contract clause, an agency's authorizing official, an overlay, or a risk assessment that identifies a single feed or data service as critical to an essential function can each add SI-22 to the control set. When that happens, the organization owns the decision and must define the essential functions, the primary information sources and the alternatives. Confirm the selection in your System Security Plan, record the organization-defined parameters for the three open values, and check that the implementation statement names who maintains each alternative source. Ask your assessor to test the two determination statements against that documentation, since the SSP is the first thing they will read.

If SI-22 is not selected, record that decision with a rationale in the tailoring documentation so a reviewer can see it was considered. If it is selected, the scope of work is set by the essential functions you name, not by the baseline. Ask any implementation partner to quote against that written list, and confirm with your authorizing official or contract owner whether SI-22 is a requirement or a recommendation before budgeting for alternative sources.

Questions buyers ask about SI-22

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

No. SI-22 Information diversity is not assigned to the low, moderate, high or privacy baseline in SP 800-53B, so it applies only when your organization selects it through tailoring, an overlay, or a contract or agency requirement that names it. Appendix C of SP 800-53 lists it as implemented by the organization and the system and as an assurance-related control. FedRAMP's Rev5 baselines also do not require it at Classes B, C or D. Check your authorizing official, contract clauses and any overlay before assuming it is in scope, because a customer or agency can add it through tailoring.

How long does it take to implement SI-22?

The duration depends on scope, not on a fixed figure. SI-22 has three organization-defined parameters and no enhancements, but the work expands with the number of essential functions you name, how many systems depend on each function, and how many alternative sources you must identify and keep current. Each alternative source also needs a documented switchover path and a way to show it works. Ask any partner for a written schedule tied to a defined scope, and ask which tasks depend on your staff being available, such as interviews and sign-off on the list of information sources.

Can our team implement SI-22 without an outside partner?

Often yes, if you already maintain system design documentation, configuration baselines and a clear list of essential functions. SI-22 is mostly a design and documentation exercise: identify the sources, decide which functions depend on them, define the trigger for switching, and test the switch. The harder parts are usually agreeing on which functions are essential and proving that the alternative source is actually usable under failure. A partner can help with that design and the test evidence, but your organization always owns the decision and the control.

What does SI-22 require from our staff?

Expect to involve system owners, data owners, the people who run the affected services and whoever maintains the architecture documents. They need to name the essential functions and services, list the primary and alternative information sources, and explain the switchover steps in their own words. Security or compliance staff must confirm that the design matches the assessment objects an assessor will examine. Plan time for interviews, because SP 800-53A also assesses SI-22 through interviews as well as examination and testing.

What drives the cost of implementing SI-22?

The main cost drivers are the number of essential functions in scope, the number of systems that depend on each source, how many alternative sources need to be built or licensed, and how much testing is needed to show a switch works. One-time costs include discovery, design, configuration and the first test. Recurring costs include reviewing the source list when systems change, retesting after architecture changes, and keeping alternative data current. When you request a quote, ask for the scope in writing, the list of functions and sources covered, the test approach, and which costs are one-time versus recurring.

When should we bring in an implementation partner for SI-22?

Bring in a partner when the essential functions are hard to define, when several systems share dependencies, or when you need to build or configure alternative sources in your own cloud, data center or air-gapped network. DeployOpen plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure and prepares the evidence an assessment needs, typically under a fixed scope agreed in writing before work starts. For backup-based alternatives, for example, a self-hosted tool such as Bareos can keep a catalog of backed-up files and restore from a backup taken before a given date and time, and restic's check command can read pack files back to confirm stored data is unmodified. Confirm each tool's capabilities against its own documentation for your use case.

Can a partner certify that we comply with SI-22?

No. An implementation partner can prepare systems, controls and evidence, but only an independent assessor, auditor or certification body can issue an assessment report, attestation or certificate. Your organization remains responsible for its controls and for the decisions it makes about risk. Ask any provider to state its role in writing, and ask your authorizing official or contract owner which independent assessment they will accept as proof that SI-22 is met.

How DeployOpen scopes and prepares SI-22 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so SI-22 work is scoped against the organization's own essential functions and their primary information sources. Only independent assessors issue assessment results, so DeployOpen prepares the systems, configuration and evidence that an assessor will examine.

How we scope

Agree in writing which essential functions and services the organization defines for SI-22 and which primary sources they depend on.
Record the list of alternative information sources, their owners and the conditions that trigger a switch to each one.
Confirm the scope before work starts, since engagements are fixed-scope with deliverables and timelines agreed in advance.

How we build

Configure the systems that hold alternative sources, such as replicated data stores or secondary feeds, inside the client's accounts or data centers.
Document system design and configuration settings so an assessor can examine how each switch-over path is set up.
Test the switch-over path on the defined scenarios, including loss of the primary source, and record the results with the configuration used.

How we hand over

Deliver the list of information sources, system design documentation and configuration records that map to the SI-22 assessment objects.
Provide test records showing the alternative source was used when the primary was corrupted or unavailable, with dates and outcomes.
Confirm with the organization's assessor which evidence formats and sampling they expect before final handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer to keep alternative sources current after changes.
Review the source list when essential functions, architecture or the SI-22 parameters change, and update documentation to match.
Ask the organization's compliance lead to confirm whether SI-22 is in their tailored baseline, since it is not in any SP 800-53B baseline.