SI-23 Information fragmentation: requirements and evidence

What SI-23 information fragmentation asks for and why it is hard to scope

SI-23 requires an organization to fragment defined information and distribute the fragments across defined systems or components when defined circumstances apply. The control is a base control in the System and Information Integrity family of SP 800-53 Rev. 5. Its purpose is to limit the damage from a single compromised component: if an attacker reaches one system, they should not be able to read the whole of a sensitive dataset. You are most likely reading this because a customer, contract or internal architecture review has asked you to address SI-23, or because your team selected it during tailoring.

The control is not in any SP 800-53B baseline. The low, moderate, high and privacy baselines do not assign it, so no impact level brings it in automatically. It enters your scope only when you select it through tailoring or an overlay, and Appendix C of SP 800-53 marks 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 Class B, C or D. Before you commit to it, confirm with the authorizing official or contract owner that the requirement is actually binding on your system, because a control selected without a reason becomes a cost with no offsetting benefit.

The difficulty lies in the three organization-defined parameters that Release 5.2.0 attaches to SI-23. You must define which information is fragmented, which systems or components receive the fragments, and which circumstances trigger fragmentation. Each choice is an architecture decision with consequences for performance, recovery, key management and operations, so the assessor will test whether your definitions are justified and consistent with your enterprise architecture. SP 800-53A checks this through examine methods against your identified information, your list of fragmented and distributed information, your list of triggering circumstances and your enterprise architecture. Start by inventorying where sensitive data actually sits, then decide, in writing, which sets qualify and why.

Where SI-23 information fragmentation applies once you select it

SI-23 has no baseline assignment, so the work starts with decisions the organization makes itself. Four decisions shape the effort: what information is defined for fragmentation, which systems can hold fragments, which circumstances trigger the control, and how the enterprise architecture constrains placement. Each one changes what the assessor examines and what evidence must exist.

Defining the information to fragment

The control's first organization-defined parameter is the set of information that must be fragmented. This is the most important scoping decision because every later artifact depends on it. Start with the data that would cause the greatest harm if one system were compromised, such as credentials, cryptographic key material or high-impact records. Document each information type and the reason it is included. Vague definitions like "sensitive data" leave the assessor unable to test anything, so ask the assessor to confirm the wording before work begins.

Choosing systems that hold fragments

The second parameter names the systems or components that receive the fragments. Each added location adds an asset to inventory, a boundary to document, access controls to maintain and monitoring to cover. Fragments placed in systems owned by different teams or providers also create dependencies on those parties. Confirm which components are in scope for the system security plan and whether any of them fall outside the authorization boundary.

Defining trigger circumstances

The third parameter defines when fragmentation applies. Without defined circumstances, the organization cannot show when the control operates, and an assessor will look for a documented list. Triggers might include information above a classification threshold, data crossing a defined trust boundary or records held by a particular service. Each trigger needs a named owner and a test that proves it fires, so the list stays aligned with actual data flows.

Constraining placement with enterprise architecture

Assessors examine enterprise architecture documentation to confirm that fragment placement is planned rather than ad hoc. If the architecture shows shared databases, flat networks or a single backup target, distributing fragments across separate components may require redesign. Check whether storage, backup and replication paths already reach the components you chose, and whether any fragment would be recombined by a common service. Architecture changes often cost more than the fragmentation logic itself.

How an assessor tests SI-23 information fragmentation

This table maps the two SP 800-53A determination statements for SI-23 against the examine, interview and test methods, the assessment objects each one uses, the evidence an assessor will ask for and the findings that most often appear. Read it as a checklist for preparing the fragmentation evidence before an assessor arrives, since SI-23 applies only when the organization has selected it through tailoring.

Assessment element	What the assessor examines or asks	Evidence that passes	Common findings
Determination statement 1: information to fragment	Examine the procedure used to identify which information is fragmented and distributed, and confirm the organization-defined information matches that procedure.	A written identification procedure, a documented list of the information types selected, and records showing the procedure was applied to the current system.	Parameter values defined in the control but no procedure showing how new information types are identified for fragmentation.
Examine: list of fragmented and distributed information	Compare the list against the system data flows and storage locations to confirm each listed item is actually split.	A current inventory naming each fragmented information item, its fragments and the system or component that holds each fragment.	The list is out of date, omits data copied into logs, caches or backups, or names information that is no longer fragmented.
Examine: list of circumstances requiring fragmentation	Check the defined circumstances, such as data classification levels or threat conditions, and confirm they trigger fragmentation in practice.	A documented list of circumstances approved by the control owner, with a mapping to the systems where each applies.	Circumstances are undocumented, vague or never tested, so teams cannot show when fragmentation was required.
Examine: enterprise architecture	Trace how fragments are distributed across systems and components and whether the architecture keeps them separate.	Architecture diagrams or data flow records showing fragments on separate systems, accounts or trust boundaries.	Fragments sit on the same server, database or backup set, so compromise of one component still exposes the full information.
Determination statement 2: fragmentation and distribution	Confirm that information is fragmented and distributed across the defined systems or components when the defined circumstances occur.	Configuration records, pipeline or application logs and sample transactions showing fragmentation and distribution happened.	Fragmentation is designed but not enforced, or it fails silently and nobody reviews the failure.
Interview	Ask system owners, architects and engineers how fragments are created, stored and reassembled, and who approves exceptions.	Consistent answers from several roles, matching the documented procedure and architecture records.	Staff describe fragmentation differently from the documents, or no one knows which circumstances apply.
Test	Sample data items from the list, trace each fragment to its storage location and attempt to confirm no single component holds the complete information.	Test results showing the sampled items are split, the fragments are on separate defined components and reassembly requires the intended access path.	Testing is not performed, or the test only checks that fragments exist without checking their separation.

Implementing SI-23 information fragmentation step by step

This sequence turns SI-23 from a selected control into a documented, testable design: which information is split, under what circumstances, where each fragment lives and how the organization proves the split holds. Each step produces a record that an assessor can examine against the SP 800-53A procedures.

Confirm selection and set the parameters
The system owner and the authorizing official confirm that SI-23 is in the control set, either through deliberate tailoring from a baseline or through an overlay, because no SP 800-53B baseline includes it. The same group then assigns values to the control's three organization-defined parameters and records the reasoning in the system security and privacy plan. Output: a signed parameter record that names the information types, the circumstances and the distribution rule. The step is complete when every parameter has a value and an owner, and no parameter is left as a placeholder.
Inventory the information to fragment
The data owners and security architects list the information that the parameter record marks for fragmentation, such as cryptographic key material, high-value credentials, or a sensitive dataset whose combination creates the main risk. For each item they note its classification, where it is created and stored, and which processes read it. Output: a fragment inventory with one row per information item. The step is complete when each row has a named owner and the inventory matches the parameter record without gaps.
Define the circumstances that trigger fragmentation
Security engineering and risk owners write down the conditions under which the split applies, for example by data class, by environment, or by threat scenario. The circumstances must be specific enough that an engineer can decide, for a new system or workflow, whether fragmentation is required. Output: a trigger matrix that links each circumstance to the information it covers. The step is complete when a reviewer can apply the matrix to a sample of new projects and reach the same answer.
Map distribution in the enterprise architecture
Enterprise architects place each fragment in a defined system or component so that compromising any single location does not expose the full information. They check that the chosen locations do not share administrators, credentials, network paths or backup copies in ways that would reassemble the data. Output: an architecture diagram and a placement table showing each fragment, its host, its trust boundary and its access path. The step is complete when the diagram shows no single component holding enough fragments to reconstruct the information, and the review is signed by the architect.
Configure the split and reassembly path
Engineers implement the splitting logic, the distribution to each location and the controlled reassembly process used by the authorized applications. They document who or what can request reassembly, how requests are logged and which components must be online for it to work. Backup and recovery procedures are included, because a restore that collects all fragments in one place can undo the design. Output: configuration records, reassembly runbooks and test accounts with least-privilege access. The step is complete when a reassembly request succeeds through the approved path and fails through any other path.
Verify fragmentation and retain evidence
An independent tester, not the engineer who built the split, checks the design against the SP 800-53A examine, interview and test steps for SI-23. They confirm the fragment inventory, the trigger matrix and the architecture records match the running system, and they attempt to reconstruct the information from a single compromised component. Output: a test report, an updated fragment inventory and a list of any findings tracked in the plan of action and milestones. The step is complete when the tester records the result and the owner accepts or remediates each finding. An independent auditor or assessor, not DeployOpen, decides whether the evidence satisfies the control.

Evidence that passes an SI-23 information fragmentation assessment

SI-23 is assessed by examining documented decisions, inventories and architecture, then testing whether the split works as written. The cards below cover the artifacts an assessor is likely to request and the upkeep each one needs between assessments, since most findings come from records that no longer match the running environment.

Organization-defined parameter definitions

SI-23 has three organization-defined parameters: the information to be fragmented, the systems or components where fragments are distributed, and the circumstances that trigger fragmentation. Record each value explicitly in the system security plan or the control implementation statement, with the owner who approved it and the date. An assessor will check that every parameter is filled in and that the wording is specific enough to test. Vague entries such as "sensitive data" are a common reason the control fails to be verified.

List of fragmented information

Maintain a register of each information set that the organization has chosen to fragment, identifying the data class, the system where it originates and the systems that hold each fragment. The assessment procedure looks for this list directly, so it should be produced from the same source as the configuration rather than typed separately. Review it whenever a data flow is added, because a new dataset that meets the defined criteria but is missing from the register will be identified during testing.

Documented circumstances requiring fragmentation

The circumstances that trigger fragmentation must be written down as conditions someone can apply, such as a classification level, a threat condition or a regulatory scope. Assessors interview staff to confirm they know these conditions, and they compare the written list with what operators actually do. Circumstances that exist only in one engineer's judgment cannot be shown to operate consistently, so convert them into a dated procedure that is approved and reviewed at a defined interval.

Architecture diagrams showing distribution

Provide current diagrams that show each fragmented information set, the systems and components that hold its fragments, and the network and trust boundaries between them. The enterprise architecture is itself an examine object for this control, so the diagrams should reconcile with it. Diagrams drawn at the time of the original design and never updated are a frequent finding. Check them against the live environment, including cloud accounts, backup targets and any system added after the last revision.

Configuration records for the split

Keep records that show how fragmentation is enforced: storage locations, key or access separation between fragment holders, and the rules that split and reassemble data. Export these from the platform configuration under version control so the record reflects the deployed state. For self-hosted systems, the assessor will want evidence that the split survives upgrades and restores, so note which settings are verified after each change.

Test results and reassembly checks

Testing shows whether no single component exposes the full information. Record tests that attempt access to one component at a time and confirm that the fragments held there do not reveal the protected information, along with the results of any integrity or reassembly checks. Backup verification also belongs here: where backups hold fragments, the verification output should show the fragments are intact. Retain dated results and link each test to the parameter it exercises, then rerun them after any change to the distribution.

What SI-23 information fragmentation costs to meet

This table lists the cost components of meeting SI-23 and shows who is paid for each, whether it is one-time or recurring, and what moves it up or down. No price or duration is supplied for this control, so use the table to structure a written scope request rather than to estimate spend.

Cost component	Who is paid	One-time or recurring	What drives it, and what to request in a quote
Architecture analysis and selection of information to fragment	Internal architects, plus any implementation partner or consultant	One-time, revisited when the architecture or circumstances change	Number of systems and data types in scope and how many circumstances are defined. Request the analysis deliverable and the list of fragmented information it will produce.
Engineering the split and reassembly path	Internal engineers or a contracted implementation partner	One-time build, with recurring change work	Number of organization-defined parameters and the complexity of reassembly. Request a fixed-scope list of components touched and the test cases for reassembly.
Storage and operations for additional components	Cloud or data center provider, internal operations team	Recurring	Count of distributed components and replication settings. Request a sizing estimate tied to the number of components and their operating model.
Evidence upkeep for examine and interview methods	Internal compliance staff, or a partner preparing evidence packages	Recurring, usually tied to assessment cycles	Frequency of assessment, rate of architecture change, and whether the list of fragmented information is maintained automatically. Request the evidence list and update cadence.
External testing or review of the fragmentation design	Independent security testing provider	Recurring or per engagement	Scope of the review and whether testing covers reassembly paths. Request the test scope and the methods used in writing.
Assessor sampling and testing effort	Independent assessor or the organization's assessment authority	Per assessment cycle	Number of fragmented information sets the assessor samples and the depth of test method applied. Ask the assessor for its sampling approach before work starts.

Which self-hosted open-source tools support SI-23 evidence

Bareos is an AGPL-3.0-only backup system whose Director schedules and supervises backup, restore, verify and archive jobs. It keeps a SQL catalog of the files it has backed up and can restore files selected from the current backup or from a backup taken before a given date and time. For SI-23, this catalog can help show which systems hold which stored copies, and the restore history can show that fragments were recovered from the defined locations. Bareos does not split information into fragments or decide how fragments are distributed, so that design work stays with the organization.

Catalog records: The SQL catalog can serve as a starting point for listing where backed-up data resides, if the organization maps backup jobs to fragment locations.
Restore testing: Point-in-time restores can support evidence that fragments can be recovered from each defined system.
Verify jobs: Verify jobs can support evidence that stored data still matches what was backed up.
Job scheduling records: Director job logs can show when each distribution or backup job ran.
License caveat: AGPL-3.0-only terms apply to Bareos itself. Ask counsel how those terms affect your use, modification and any hosted service you run.

Confirm in your own environment which fragment locations you can map to specific Bareos jobs, and whether your catalog and logs are retained long enough for the assessor to sample.

Questions buyers ask about SI-23 information fragmentation

Is SI-23 information fragmentation required by FedRAMP or a NIST baseline?

No. SP 800-53B does not assign SI-23 to the low, moderate, high or privacy baseline, and FedRAMP's Rev5 baselines do not require it at Class B, C or D. SI-23 applies only when your organization selects it through tailoring or an overlay, usually because a contract, a risk assessment or a regulator asks for it. Appendix C of SP 800-53 marks it as implemented by the organization and the system and as an assurance-related control. Confirm with your contracting officer or assessor whether it appears in your required control set before scoping any work. You can review the control text in the SP 800-53 Rev. 5 publication.

How much effort does SI-23 add to an existing system?

The effort depends on how much sensitive information you choose to fragment and how many systems must hold the fragments. SI-23 has three organization-defined parameters and no enhancements, so the control itself is narrow, but the design work behind it is not. Your team must define which information is covered, the circumstances that trigger fragmentation, and the systems that will hold each fragment. Costs are mainly one-time design and integration work, followed by recurring effort to review the list of distributed information and the triggers as the architecture changes. Ask any provider for a written breakdown of design, build, testing and evidence work, since no figure for this control is published by NIST.

How long does implementing information fragmentation take?

Duration is driven by scope, not by the control text. The main factors are the number of sensitive data types in scope, how many independent systems or components you can use as distribution targets, whether those systems already exist in your enterprise architecture, and how much integration work each target requires. Work usually runs in phases: identify information and circumstances, design the distribution pattern, build and test it, then document the evidence. NIST does not set implementation timelines for federal systems, so any duration should come from a written, fixed-scope plan that lists deliverables and dependencies. Ask for that plan before committing budget.

What does SI-23 require from architecture and engineering teams?

Architecture teams must document where sensitive information lives today and decide which components can hold separate fragments without creating a new single point of exposure. Engineering teams must implement the split, the reassembly path, access controls on each fragment store and monitoring for unexpected reassembly. The assessment objects named in SP 800-53A include the procedures used to identify information for fragmentation, the list of fragmented and distributed information, the list of circumstances that require fragmentation, and the enterprise architecture. Those artifacts must match what is running, so engineers should keep them current as systems change.

Can we implement SI-23 in-house without outside help?

Yes, if you have the architecture skills and capacity to do it. Your organization owns the control, the risk decision and the evidence. An implementation partner such as DeployOpen can plan, build and document the fragmentation design inside your own infrastructure under a fixed-scope written agreement, but it does not assess or certify your system. Choose outside help when your team lacks distributed-architecture experience or is already committed to other control work. Whatever you choose, make sure someone internal owns the list of covered information and the triggers after handover.

What will an assessor ask first about SI-23?

An assessor will usually start with scope: which information your organization defined for fragmentation, and under which circumstances. They will then ask for the enterprise architecture showing where each fragment is stored and how the systems are separated. Expect requests for the list of distributed and fragmented information and the procedure used to identify it. Assessors will also test whether the fragments are actually distributed as documented, using examination, interviews and testing. Only an independent assessor can issue a finding, so prepare these artifacts before the assessment rather than during it.

Which open-source tools help with backup fragments and integrity checks?

Open-source tools do not implement SI-23 on their own, because fragmentation is an architectural decision. They can support related evidence, however. Bareos, licensed under AGPL-3.0-only, schedules backup, restore and verify jobs and keeps a SQL catalog of backed-up files, which helps show where data copies are held. restic, licensed under BSD-2-Clause, uses its check command to verify snapshot, tree and pack file structure, and with --read-data or --read-data-subset it reads pack files back to confirm stored data is unmodified. Confirm that any tool fits your distribution design and access model before relying on it as evidence.

Who does what for SI-23 information fragmentation

Your organization owns SI-23. That means deciding whether the control applies at all, defining the information that must be fragmented, defining the circumstances that trigger fragmentation, and naming the systems or components that receive the fragments. SI-23 has three organization-defined parameters, so these choices are yours to make and document. The control is not in any SP 800-53B baseline, so the first decision is whether your tailoring or overlay selects it.

Selection and tailoring: Record whether SI-23 is in scope for each system, with the rationale in the system security plan.
Parameter decisions: Define the information types, the triggering circumstances and the distribution targets.
Enterprise architecture: Keep the architecture documents current, because the assessment examines them directly.
Accountable owner: Assign a named person to approve the design and accept residual risk.
Recurring review: Confirm that the list of fragmented information still matches what the systems hold.

Confirm with your assessor which artifacts they expect for each parameter before you finalize the design.

How DeployOpen scopes and prepares SI-23 information fragmentation

DeployOpen treats SI-23 Information fragmentation as a scoped engineering and documentation task inside your own infrastructure. We identify with you which information and circumstances the control covers, implement the distribution across the systems you define, and hand over evidence an independent assessor can examine. Assessment and any certification remain with your organization and independent assessors.

How we scope

Agree in writing which information types and circumstances your organization defines for fragmentation.
Map the systems and components that will hold fragments, using your enterprise architecture as the starting reference.
Confirm the three organization-defined parameters for SI-23 with your control owner before any build begins.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Implement fragmentation and distribution logic on open-source platforms running in your cloud, data center or air-gapped network.
Separate fragment storage so compromise of one component does not expose the complete sensitive dataset.
Test recovery and reassembly with restore exercises, including verification of backed-up data integrity.
Test the distribution design with security testing where your scope includes it, and record the results.

How we hand over

Deliver a list of the distributed and fragmented information and the circumstances that trigger fragmentation.
Document the architecture diagrams and configuration showing where each fragment type is stored.
Provide procedures for identifying new information that requires fragmentation, with named owners.
Hand over evidence in a form your assessor can examine, interview against and test, aligned to SP 800-53A procedures.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Review the fragmentation design when enterprise architecture or the list of covered information changes.
Keep documentation current so the SI-23 evidence matches the systems as they run.

SI-23 Information fragmentation