What does "reassess the delta" mean?

It means deriving reassessment scope from a computed difference between two immutable architecture versions, instead of rebuilding the authorization package because the system changed. The diff between versions produces the set of controls the change actually touches. Controls outside that set keep the evidence, determinations and authorization context already established for them.

Why not just reassess everything?

Because it is enormously expensive and it produces a perverse incentive. When any system change triggers a full reassessment, the rational program response is to change the system less — which makes the security process the reason engineering cannot improve the system. Full reassessment is also less accurate in practice, because an assessor re-running hundreds of unchanged controls under deadline gives each one less attention than a scoped reassessment would.

Does the change impact report change my controls automatically?

No. The report is advisory. It never alters a control, an assessment, a determination or a package. It answers the question of what a change appears to affect, and a person decides what to do about it. A system that silently re-scoped your assessment would be making an authorization decision, and machines do not get to make those.

Why do architecture versions need to be immutable?

Because an assessment result is only meaningful against a specific system state. If the architecture version an assessment was performed against can be edited afterwards, the result no longer describes anything definite. Content-hashing the published version means an assessment can name the exact state it examined, and a diff between two versions is a statement about two known things rather than two moving targets.

Concept

Reassess the delta instead of rebuilding the package.

When a system changes, only some of the authorization stops being true. Working out which part is arithmetic if the architecture is versioned, and a meeting if it is not.

Immutable versions
Content-hashed
Advisory, never automatic

Ref: D-01
Kind: Problem
Trigger: any system change

The default is a rebuild, and the default is wrong.

Something changes. A component moves. A connection is added. A dependency picks up a critical CVE. An implementation is improved. Somebody now has to answer four questions, by hand, from memory:

What actually changed?
Which controls does it affect?
What has to be reassessed?
Which documentation is now stale?

When those cannot be answered confidently, the safe move is to reassess everything. It is defensible and it is enormously expensive, and it teaches the program a lesson nobody intended.

Full reassessment on every change makes security the reason engineering cannot improve the system.

That is the real cost. Not the assessor hours — the architectural decisions quietly deferred because nobody wanted to trigger the paperwork. A process that discourages improving a system is not making that system safer.

system / authorization boundary published 19 AUG 2026 · 14:02Z

v6 sha256:4c1e…8ab2

v7 sha256:9f3a…d071

changed: 4 components · 1 connection · 1 data flow
reassess: AC-4
SC-7
SC-8
CA-3
CA-9
SC-13

controls in scope of the change
preserved: 289 controls unchanged — evidence, determinations and assessment history retained

Assessments stay bound to the architecture version they were performed against. Publishing a new version never moves that binding.

Ref: D-02
Kind: Mechanism
Basis: structured diff
Authority: the practitioner

How the scope is derived.

Six steps, of which exactly one is a judgment call — and that one belongs to a person.

01 Publish the architecture as a version The boundary, trust zones, components, connections, data flows and interconnections are captured as structured facts and published. The version is immutable and content-hashed, so it cannot be quietly edited after an assessment was performed against it.
02 Let the system change A component moves to a different trust zone. A connection is added. A data flow changes direction. Engineering does what engineering does, and the working set diverges from the last published version.
03 Compute the diff Compare two versions and get a structured change list: what was added, removed or altered, and to which object. This is arithmetic, not judgment, and it does not depend on anyone remembering what they did in March.
04 Derive the affected controls Each change category relates to controls. Moving a component across a trust boundary bears on boundary protection and access control. Adding an interconnection bears on the agreements and the flows behind them. The relationship is stated, inspectable and the same every time.
05 Scope the reassessment The output is a report: how many changes, how many affected controls, across which families, at what highest impact. It is advisory. It never alters a control, an assessment or a package — a person decides what to reassess.
06 Keep everything the change did not touch The controls outside the scope keep their evidence, their determinations and their authorization context. Nothing is discarded because something else moved. That is the entire economic argument.

Ref: D-03
Kind: Evidence

What the report looks like.

CertiField's Architecture Change Impact report comparing published version 27 to the current working set. It reports 8 changes, 18 affected controls and a highest impact of High, with a table listing each change, the object it touched, its category and the controls related to it. — Eight changes, eighteen controls that may warrant review across eleven control families, and the specific controls each individual change touches. The report never alters a control, an assessment or a package. Architecture · RMF Impact

Note what the report does not say. It does not say those eighteen controls have failed, or that they must be reassessed, or that the authorization is invalid. It says these eight changes relate to these eighteen controls, and here is the relationship for each one. What to do with that is a practitioner's call, and the report exists to make that call informed rather than to make it for them.

Ref: D-04
Kind: Requirement

Why immutability is not a design flourish.

The whole mechanism rests on being able to name two definite states. That requirement propagates further than it first appears.

An assessment names a version

An assessment result describes a specific system state. Bound to a content-hashed version, it keeps describing that state forever. Bound to "the architecture", it describes whatever the architecture happens to be when someone asks.

A diff needs two fixed points

If either version can be edited after publication, the diff is a statement about two moving targets and the scope it produces cannot be defended.

Staleness becomes detectable

When a control's most recent assessment names version 24 and the system is on version 27, that control's currency is a computed fact rather than a hunch.

The history is the audit trail

A sequence of published versions is a record of how the system evolved, which is exactly what a reviewer asking "when did this change?" needs and what a mutable model cannot provide.

Ref: D-05
Kind: Limits

Where this does not help.

If the architecture is not modeled, there is nothing to diff. The mechanism requires someone to have described the boundary as structured facts. That is real work and it is the price of admission.
If the model is wrong, the scope is wrong. A diff over an inaccurate architecture produces a confident answer to the wrong question. The model has to be maintained honestly.
Not every change is architectural. A policy change, a personnel change or a new information type affects controls without touching the boundary, and those still need a person.
A frozen system gains nothing. If the architecture has not moved since the last authorization, the delta is empty and this machinery is dead weight.

See the change impact report Architecture and change impact

Next step

See what your RMF process looks like when the package keeps up with the system.

Request a demo Explore the product