Atomization
About atomization
Section titled “About atomization”Atomization is the process of turning complex regulations, risk management frameworks, or internal policies and procedures into discrete, self-contained requirements called controls.
An atomized control expresses one specific obligation while remaining connected to the source language that supports it. The goal is to create controls that can be understood, assigned, implemented, evidenced, and evaluated independently.
Dense regulations, standards, and internal policies often combine several requirements within long or cross-referenced passages. Atomization makes those requirements easier to:
- Understand and review.
- Assign to an accountable party.
- Connect to focused supporting evidence.
- Evaluate individually.
- Trace to authoritative source language.
- Maintain when the source changes.
This structure can also support comparison and evidence reuse across frameworks. Similar controls are easier to identify when each control represents one clear obligation. Any reuse still requires human review and must preserve the meaning, scope, and applicability of each source.
Understanding an atomized control
Section titled “Understanding an atomized control”Atomization begins with the source documentation. Definitions, scope statements, conditions, exceptions, cross-references, and surrounding language may all affect how a requirement should be interpreted. A single passage may produce several controls, and one control may rely on several passages.
An atomized control generally contains four elements:
- Responsible party: The person, organization, team, or system responsible for the action.
- Type of obligation: “Must” identifies a required action. “May” identifies an expressly optional or conditional action.
- Mandate: The action or outcome established by the source, including any material conditions, timing, exceptions, thresholds, or limitations.
- Context: The additional information necessary for the control to be interpretable in absence of the source documentation, such as what the mandate means or when it applies.
Responsible party
Section titled “Responsible party”Determine who is accountable for satisfying the requirement.
The responsible party may appear in the same sentence as the mandate, or it may be established by a heading, introductory paragraph, definition, or earlier provision. Review the surrounding text before assigning the control.
Use the responsible party named by the source whenever possible. If the source assigns responsibility to a broad legal actor, you may use an equivalent organizational role only when the substitution preserves the source’s meaning.
Type of obligation
Section titled “Type of obligation”Determine whether the source establishes a mandatory obligation or an expressly optional or conditional action.
Use:
- Must when the source uses mandatory language such as shall, must, or is required to.
- May when the source expressly permits an action or makes it available only when stated conditions are met.
Preserve every condition attached to a may statement. A conditional permission is incomplete without the condition that makes it available.
Do not automatically turn descriptive or advisory language into a control. Words such as should, can, or generally require review to determine whether the source establishes an obligation, offers guidance, or provides context only.
Mandate
Section titled “Mandate”Determine the specific action or outcome required by the source.
A mandate is discrete when it can be assigned, implemented, evidenced, and evaluated independently. If a passage contains several actions or outcomes that require different evidence or could receive different review decisions, create a separate control for each one.
Context
Section titled “Context”Identify the context that determines what the requirement means or when it applies.
Carry material context into the control so an implementer can understand the requirement without repeatedly returning to the source. Do not add context that creates a new obligation or expands the source.
Important context may include:
- Scope and applicability.
- Definitions.
- The system, record, process, or asset governed by the requirement.
- Lifecycle stage.
- Timing or frequency.
- Conditions and exceptions.
- Thresholds or required properties.
- Cross-references to other provisions.
How to atomize a control
Section titled “How to atomize a control”A well-written control contains the following qualities:
- Understandable on its own without changing the legal or operational meaning of the source.
- Written as one complete sentence using the following structure: [Responsible party] + [must or may] + [discrete mandate] + [material context].
- Preserves the source’s terminology where it remains clear. Rewritten only as needed to make the control self-contained and testable.
- Avoids semicolons, long lists, and compound clauses that combine obligations requiring different evidence.
Example atomized control
Section titled “Example atomized control”The following example applies the methodology to 21 CFR Part 11, which establishes FDA requirements for electronic records and electronic signatures.
Source passage
Section titled “Source passage”We will focus on §11.10(d).

Identify the responsible party
Section titled “Identify the responsible party”The responsible party is established by the introductory language in §11.10 and applies to paragraph (d), even though it is not repeated inside the paragraph:

To preserve the simplified nature of a control, we restate the responsible party as persons using closed systems for electronic records.
Persons using closed systems for electronic records + [must or may] + [discrete mandate] + [material context].
Identify the type of obligation
Section titled “Identify the type of obligation”The obligation is established by the introductory language after the responsible party in §11.10:

“Shall” indicates a mandatory requirement.
Persons using closed systems for electronic records + must + [discrete mandate] + [material context].
Identify the mandate
Section titled “Identify the mandate”Paragraph (d) contains one outcome that can be evidenced and evaluated independently:

We adjust the mandate so that it maintains proper grammar within the control.
Persons using closed systems for electronic records + must + limit system access to authorized individuals + [material context].
Identify the context
Section titled “Identify the context”The relevant context can be found in the introductory language in §11.10:

An organization can determine whether context is deemed necessary for the control’s implementation. In this instance, we can extract the context as follows:
Persons using closed systems for electronic records + must + limit system access to authorized individuals + to ensure the authenticity, integrity, and confidentiality of the signed electronic records.
Best practices
Section titled “Best practices”- Begin with the authoritative source rather than a third-party summary.
- Define the scope before drafting controls.
- Read the surrounding provisions before assigning a responsible party or interpreting a mandate.
- Preserve source language where it remains clear and testable.
- Add context only when needed to make the control accurate and self-contained.
- Separate obligations according to how they will be assigned, evidenced, and evaluated.
- Revisit the controls when the source changes or new interpretive guidance becomes available.