SI-23: Information Fragmentation

To meet the si-23: information fragmentation requirement, define where and how you will fragment sensitive information in your environment, implement the chosen technique(s) consistently across in-scope systems, and keep evidence that fragmentation is designed, operating, and reviewed. Operationalize SI-23 by assigning an owner, writing an implementation procedure, and producing recurring artifacts an assessor can test. ¹

Key takeaways:

• SI-23 is an engineering-and-operations control: you must make fragmentation real in system design, not just policy. ²
• Assessment success depends on traceability: control owner, procedure, and repeatable evidence mapped to each in-scope system. ¹
• Your fastest path is a documented pattern (where applied, where not, why) plus testable configuration and verification records. ²

SI-23 (Information Fragmentation) is easy to fail for one reason: teams treat it as a concept (“we split data”) instead of a requirement you can prove in a system boundary. For a CCO, compliance officer, or GRC lead, the practical goal is to turn SI-23 into a small set of repeatable design choices and a clean evidence trail that survives turnover, tooling changes, and audit sampling.

This page focuses on operationalizing SI-23 quickly: scoping what “information fragmentation” means in your environment, selecting approved fragmentation methods, embedding them into architecture and procedures, and producing evidence that stands up to assessment. NIST SP 800-53 is a framework standard used across federal information systems and contractor systems handling federal data, so SI-23 typically shows up in authorization packages, security plans, and customer security questionnaires. ²

The highest-risk failure mode is not malicious activity; it’s inability to demonstrate implementation. If your documentation says “fragment data,” but the system design, configurations, and operational checks don’t show it, assessors will write it up as a control design or operating gap. ¹

Requirement: SI-23 information fragmentation (what it means)

SI-23: Information Fragmentation requires you to implement a defined approach to fragmenting information so sensitive data elements are separated in a way that reduces the impact of compromise. The provided excerpt indicates the control is parameterized (“Based on {{ insert: param, si-23_odp.01 }}:”), meaning your organization must define the organization-defined parameter(s) (ODP) that specify what fragmentation approach you will use and under what conditions. ¹

Plain-English interpretation

You must:

1. Decide and document your fragmentation rule(s) (the ODP): what you fragment, where, and by what technical pattern.
2. Implement fragmentation in the systems that process/store the targeted information (not just in policy).
3. Prove it works operationally through configurations, architecture artifacts, and recurring verification.

Think of fragmentation as “separation that breaks the value of a single compromise.” Common real-world patterns include separating identifiers from sensitive attributes, splitting secrets across services, or segmenting data stores so a single access path cannot retrieve complete records.

Who SI-23 applies to

Entity applicability

• Federal information systems and
• Contractor systems handling federal data (including regulated cloud and SaaS providers supporting federal workloads). ¹

Operational context (where assessors will expect to see it)

SI-23 becomes “real” in places like:

• Data architecture for regulated datasets (PII, mission data, controlled unclassified information when applicable in your boundary)
• Application data models (separating identity, auth, and sensitive attributes)
• Key management and secret storage patterns
• Backup/replication designs and analytics pipelines (fragmentation can be accidentally undone during ETL)

Regulatory text

Excerpt (as provided): “Based on {{ insert: param, si-23_odp.01 }}:” ¹

What an operator must do with this excerpt

Because SI-23 is expressed through an organization-defined parameter, your immediate compliance task is to define the parameter content and bind it to implementation. Practically, that means your SI-23 procedure should state:

• The approved fragmentation methods (one or more)
• The data types and system components in scope
• The exceptions process (when fragmentation is not feasible and what compensating controls apply)
• The verification method (how you confirm fragmentation remains intact through changes)

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

Step 1: Assign ownership and scope the control

• Name a control owner (often Security Architecture, AppSec, or Data Platform) and a GRC owner responsible for evidence and assessment coordination.
• Define the system boundary list where SI-23 applies (authorization boundary, enclave, or product line).
• Identify the information types that require fragmentation in your environment.

Deliverable: SI-23 control record with owner, in-scope systems, and defined ODP content. ¹

Step 2: Choose your fragmentation pattern(s) and make them testable

Pick patterns that your teams can implement consistently and that an assessor can validate through artifacts. Examples (adapt to your boundary):

• Data store separation: keep identity/profile data in one datastore and sensitive attributes in another, with separate access roles.
• Tokenization / surrogate keys: store a token in the primary app datastore and keep the mapping in a restricted service.
• Service-level separation: separate components so no single microservice can return a full sensitive record without cross-service authorization.

Operator tip: Write each pattern as a “build standard” with (a) intent, (b) where allowed, (c) IAM requirements, (d) logging expectations, and (e) what evidence proves it.

Step 3: Implement in architecture, code, and platform configuration

• Update reference architectures and data flow diagrams to show fragmentation boundaries.
• Implement IAM separation aligned to fragmentation (distinct roles for each fragment).
• Ensure downstream processes (ETL, analytics, backups) preserve fragmentation or apply equivalent separation.

Evidence you want to exist by default: architecture diagrams, data model documentation, IAM policy snippets, and configuration exports showing separation.

Step 4: Add change gates so fragmentation doesn’t decay

SI-23 commonly fails during “helpful” refactors that rejoin datasets.

• Add SDLC checks: design review requirement for new data stores or schema changes that touch in-scope data.
• Add infrastructure-as-code guardrails: prevent creation of “combined” tables/buckets for in-scope datasets unless approved.
• Require security sign-off for exception requests.

Step 5: Verify continuously (or at least routinely) and retain proof

Your verification method should detect:

• New joins/replications that defeat fragmentation
• Overbroad IAM grants that allow single-path reconstruction
• Data pipelines that copy both fragments to the same destination

If you use Daydream, implement SI-23 as a mapped control with an owner, a documented procedure, and a recurring evidence schedule so evidence stays current and assessment-ready. This directly addresses the most common SI-23 risk factor: missing implementation evidence. ¹

Required evidence and artifacts to retain (audit-ready)

Maintain a tight evidence set that ties design to operation:

Governance and definition

• SI-23 control narrative with the organization-defined parameter content (what fragmentation means for you). ¹
• Assigned control owner and RACI for engineering, security, and GRC.

Technical implementation

• Current architecture diagrams and data flow diagrams showing fragmented components.
• Data model documentation (schemas, entity relationships) showing separation of sensitive elements.
• IAM artifacts proving separation (role/policy exports, access boundaries, service accounts).

Operational proof

• Change management records for fragmentation-relevant changes (tickets, PRs, approvals).
• Verification outputs (queries, scripts, checks) demonstrating fragmentation remains intact.
• Exception register with approvals and compensating controls.

Common exam/audit questions and hangups

Assessors usually test SI-23 with “show me” questions:

1. What is your organization-defined SI-23 fragmentation approach? Where is it documented? ¹
2. Which systems and information types are in scope, and why?
3. Show an example of a fragmented dataset and the access controls that prevent single-path reconstruction.
4. How do you prevent data pipelines, analytics, or backups from re-aggregating fragments?
5. How do you detect drift after releases or infrastructure changes?

Hangup to expect: teams can describe fragmentation verbally but cannot produce artifacts that map cleanly to the system boundary and current production state.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	How to avoid it
Fragmentation defined only in a policy	Policies don’t prove implementation	Write an implementable standard plus system-specific mappings and proof artifacts. 2
Fragmented in prod, rejoined in analytics	Downstream systems recreate the sensitive whole	Treat ETL/BI as in-scope; enforce destination controls and reviews.
Overbroad IAM across fragments	One role can read everything	Separate duties; require distinct roles and approvals per fragment.
No exception process	Teams bypass the control informally	Maintain an exception register with compensating controls and approvals.
No recurring evidence	You can’t show ongoing operation	Schedule and retain recurring verification outputs in your GRC system. 1

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SI-23, so this page does not cite specific enforcement actions. ¹

Operationally, the risk is straightforward: if an attacker, insider, or misconfiguration gains access to one store or service, fragmentation can limit exposed data completeness. The compliance risk is also straightforward: if you cannot show defined parameters, implementation, and operational checks, SI-23 will be treated as not implemented or not operating effectively in an assessment against NIST SP 800-53. ²

Practical execution plan (30/60/90)

First 30 days (foundation)

• Name SI-23 control owner and backups; document the SI-23 ODP definition and scope per system boundary. ¹
• Inventory where sensitive elements live today (primary DBs, caches, logs, object storage, analytics).
• Select approved fragmentation patterns and write a short engineering standard with “proof points.”

By 60 days (implementation + evidence)

• Implement fragmentation in highest-risk systems first (internet-facing apps, shared platforms, broadly accessed datasets).
• Update diagrams, data models, and IAM artifacts for each in-scope system.
• Stand up verification checks (queries/scripts) and store outputs as evidence.

By 90 days (operationalization)

• Add SDLC gates: design review triggers, IaC checks, and exception workflow.
• Create recurring evidence tasks in Daydream (or your GRC tool) mapped to SI-23: owner attestations, config exports, verification outputs, and exception review. ¹
• Run an internal mini-assessment: sample one system and walk an auditor through definition → implementation → verification.

Frequently Asked Questions

What counts as “information fragmentation” for SI-23 in practice?

It’s an intentional design where sensitive information is split so one compromise path does not expose the complete dataset. Your organization must define the specific fragmentation approach as an organization-defined parameter for SI-23. ¹

Does SI-23 require tokenization or encryption?

SI-23 is about fragmentation; it does not, based on the provided excerpt, mandate a specific mechanism like tokenization. You choose and document the method(s) in your SI-23 parameter definition and implement them consistently. ¹

How do I scope SI-23 for a SaaS platform serving both federal and commercial customers?

Apply SI-23 to the defined federal system boundary (or enclave) and document where fragmentation is implemented within that boundary. Keep evidence that boundary data stores, pipelines, and roles preserve the fragmentation approach. ²

What evidence is most persuasive to an assessor?

Architecture/data flow artifacts showing separation, plus IAM/config exports and repeatable verification outputs that demonstrate fragmentation is currently in place. Pair that with a clear control narrative that defines your SI-23 parameter content. ¹

We fragment data, but engineers say it’s “obvious.” Do we still need documentation?

Yes. SI-23 is assessed against documented parameters and demonstrable implementation; “obvious” designs still need an owner, a written procedure/standard, and retained evidence tied to the system boundary. ¹

How should we handle exceptions where fragmentation is technically hard?

Create a formal exception workflow with documented rationale, scope, approvals, and compensating controls, then track exceptions as an auditable register. This prevents silent drift away from the defined SI-23 approach. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5