Why a fourth register needs a reason
Twelve months after one architecture team stood up an assumption register, they had four hundred entries. Architects filed every design decision. Engineers added every integration dependency. Someone transcribed the entire control inventory into assumption language because "control X works" felt like an assumption worth tracking. The register was abandoned the following quarter — not because the concept failed, but because nobody had defined what it was not for.
The register's value is scope discipline. The moment it becomes a mirror of the architecture, it stops functioning as a validation tool and starts consuming the maintenance overhead of three other registers simultaneously. An assumption register documents cross-domain behavioral claims that the architecture depends on but that no single control test can confirm. It does not document controls, standards obligations, funding decisions, or exposure paths from unremediated findings — those belong elsewhere, and filing them here guarantees duplication.
Before standing one up, the honest question is whether the design already carries assumptions that could fail across a boundary without triggering an existing assurance function. If it does, the register has a reason. If the existing control testing program already covers every claim, the register is redundant before the first entry is written.
What belongs in it and what belongs in the control inventory
The sharpest practical distinction: a control inventory records what is deployed and configured; an assumption register records what must remain true across the interaction of multiple controls or systems for the design to hold. "MFA is enforced at the policy decision point" belongs in the control inventory. "MFA enforcement survives an IdP failover to the secondary replica without dropping the session context that the PDP uses for per-request authorization" is an assumption — it spans two systems, a failure mode, and a behavioral claim that no individual control test touches.
Control testing verifies that individual controls operate within their isolated domains, whereas architecture validation asks whether the cross-domain assumptions holding those systems together hold up under stress. Duplication occurs when teams file the same underlying claim in both places using different terminology.
Exposure paths stemming from unremediated findings belong in vulnerability exposure management, which owns attack paths arising from known, unpatched flaws—do not file those here. Similarly, tracking architecture debt and broad validation status reporting belong to executive governance frameworks; the assumption register is an operational validation tool, not a reporting vehicle.
Register boundary table
| Candidate entry | Register it belongs in | Why | What would be duplicated if misfiled | Cross-reference to record |
|---|---|---|---|---|
| "Recording is enabled on the jump host policy" | Control inventory / assurance | This is a statement about a single control's configuration, verifiable by testing the control in isolation | Existing control test evidence | Control test record; assurance finding |
| "No admin path reaches the target without traversing the recorded proxy" | Assumption register | Claims span the PAM proxy, jump host configuration, and any direct-to-target path — no single control owns the interaction | Would duplicate jump host configuration record if filed there | Architecture decision record |
| "Token revocation propagates to all resource servers within session timeout window across IdP, gateway, and downstream APIs" | Assumption register | Claim spans IdP behavior, gateway policy, and API token-handling — no single control owns the interaction | Would duplicate IdP configuration record if filed there | Architecture decision record |
| "Network segmentation design approved pending funding for east-west inspection nodes" | Architecture decision register | This is a funding-gated design decision, not a behavioral assumption under test | Would duplicate the decision register and create a false validation obligation | Architecture decision record |
| "Encryption in transit is required for all data flows crossing tenant boundaries per internal policy" | Standards/policy obligation register | This is a mandatory control requirement, not a behavioral assumption | Would duplicate the policy control mapping and the GRC register | Policy register; applicable control identifier |
| "The authentication service dependency on the directory synchronization job means an undetected sync failure will produce stale group membership at the PDP within one replication cycle" | Assumption register | Cross-system dependency claim with a specific failure mode; spans auth, directory sync, and PDP behavior | Would duplicate dependency map if filed there without the behavioral claim attached | Dependency map |
| "NIST AC-2, as baselined by FedRAMP, requires account management procedures covering account establishment, activation, modification, and termination" (Source: NIST SP 800-53 Rev. 5, https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final) | Standards obligation register | This is a named control with a fixed identifier; assumption registers are for behavioral claims, not compliance mappings | Would duplicate the compliance control mapping in the GRC system | Compliance register; authorization package |
The minimum fields an entry needs
Bloat usually enters through optional fields that teams populate inconsistently and then report against. A register that can function with seven fields is more likely to survive a staffing change than one requiring twelve. The minimum set that makes an entry actionable:
Assumption ID — a sequential identifier that can be cross-referenced from architecture decision records and dependency maps without ambiguity.
Statement — the behavioral claim in a single sentence, written so it can be falsified. "The secondary authentication path maintains equivalent policy enforcement to the primary path" is testable. "Authentication is resilient" is not.
Scope boundary — which systems, domains, or trust boundaries the claim spans. This field is what separates an assumption register entry from a control inventory line. If the scope boundary field names only one system, the entry probably belongs elsewhere.
Validation status — one of: unassigned, untested, tested-held, tested-failed, or retired. No scoring, no maturity weighting. Adding numeric confidence scores creates false precision that reviewers mistake for objective measurement rather than engineering judgment; explicit categories establish a clean binary that is straightforward to audit.
Unassigned applies to entries lacking a designated test owner; these feed the testing gap inventory and must not be collapsed into untested, which denotes an assigned owner who has simply not yet executed. Tested-held entries must record the date the determination was made because the retest cadence lives in the test plan rather than the register—without an explicit timestamp, a held result never expires and cannot be challenged in subsequent review cycles.
Held-as-of date — populated only when validation status is tested-held; records when the held determination was made. Blank for all other statuses.
Assumption owner — the named individual or named role accountable for the design claim, typically the architect or system owner whose design the assumption supports. "Platform team" is not an owner. When an organizational change removes the person named in the field, the entry should trigger a review — stale ownership is one of the faster paths to a register that nobody acts on. A designated backup should be recorded alongside the primary.
Test owner — the named individual or named role accountable for designing and executing a validation activity that can produce evidence. May be in a different function from the assumption owner.
These two owner fields are required, not optional. Separating them is the mechanism that keeps validation independent enough to be credible, and both must be populated before an entry can leave unassigned status.
Recording the owner of the assumption and the owner of the test
These are two different people, and conflating them produces a validation program where the architect who made an assumption is also the one confirming it held. The assumption owner is accountable for the design claim. The test owner is accountable for designing and executing a validation activity that can produce evidence.
NIST SP 800-53A Rev. 5 defines depth and coverage as attributes of the assessment method — how rigorously a test is conducted and how broadly it applies — not as attributes of the control being assessed (Source: NIST SP 800-53A Rev. 5, https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final). The same principle applies to assumption validation: while the test owner decides the testing method and rigor, adjudicating whether the evidence warrants retiring or holding an entry belongs to an independent design authority. An assumption owner must never evaluate evidence against their own claim; preserving this structural separation is what keeps the validation credible.
Keeping it smaller than the architecture
The register in the opening example failed because the filing criterion was "this feels like an assumption." Every design decision involves assumptions; filing all of them produces a register that is structurally identical to the architecture itself.
The practical filter is consequence specificity. An entry earns a place in the register only when three conditions hold simultaneously: the claim spans more than one system or control domain, an existing assurance activity would not catch a failure before it occurs rather than merely flagging it after the fact, and the architecture's threat model or degraded-mode resilience design directly depends on the claim remaining true. Miss any one of those conditions, and the entry belongs in an existing inventory or nowhere at all.
The second condition deserves emphasis. The question is not whether an alert would fire within some window after a failure — for identity paths where session context can be dropped in minutes, detection latency is itself the exposure. An assumption whose failure is detectable by monitoring but not caught by a prior assurance activity before that failure can become breach-enabling still belongs here. The relevant question is: Would an existing assurance activity test this claim before it fails, rather than notice the failure afterward? If the honest answer is yes, the assumption is already covered. If the answer is no, it has a place here.
The third condition is broader than it might appear. Many resilience assumptions — directory sync staleness, IdP failover behavior, degraded-mode policy enforcement — sit outside the formal threat model but are still load-bearing for the design. Limiting the filter to threat model claims alone would exclude them.
Applying this filter at intake — before an entry is written, not during a quarterly review — keeps the register below a size where it can be actively governed. A register that grows faster than it retires entries is accumulating unmaintained claims, which is worse than having no register because it creates the appearance of coverage.
When an entry should be retired
Retirement is not the same as passing a test. An entry can be retired for four distinct reasons, each requiring different evidence:
Assumption validated and control implemented: the behavioral claim has been tested, held, and a permanent control now enforces the condition continuously — and that control can itself be tested independently of the cross-domain interaction it governs. The assumption is no longer load-bearing as a design claim because enforcement is direct and verifiable in isolation. If the new control is itself a cross-domain behavioral claim dressed in control language, the assumption has not been retired; it has been relabeled, and the entry should remain open against the underlying claim. File the control; close the entry only when the independence condition is satisfied.
Assumption superseded by design change: the architecture changed, and the claim no longer describes the system. Leaving the entry active creates a false validation obligation against a design that no longer exists.
Assumption migrated: the claim turned out to belong in a different register — a dependency map, a control inventory line, or a standards obligation. Migrate with a cross-reference; do not duplicate.
Assumption determined out of scope: the threat model changed, and the failure mode the assumption guards against is no longer in scope. Document the decision and the authority who made it.
The assessment planning discipline in NIST SP 800-37 Rev. 2 requires that scope be documented at the plan level, covering what is being assessed and what procedures apply (Source: NIST SP 800-37 Rev. 2, https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final). Assumption register retirement follows the same logic: scope decisions should be documented with enough specificity that a successor can reconstruct why an entry was closed without re-interviewing the original architect.
The duplication test
Before filing any entry, run it against these four questions. A "yes" to any one of them redirects the entry:
- Does this entry describe a control's existence or configuration? → Control inventory.
- Does this entry describe whether a control operated as designed during a specific period? → Control testing and assurance records.
- Does this entry describe an attack path from a specific unremediated finding? → Vulnerability exposure management scope.
- Does this entry describe a decision that is pending funding or approval rather than a behavioral claim under test? → Architecture decision register.
If all four answers are no, the entry is a candidate for the assumption register. Write the statement so it can be falsified, assign two distinct owners, and apply the consequence-specificity filter before committing it. Entries lacking an assigned test owner should be designated as unassigned and tracked in the testing gap backlog until an owner is named.
A register with thirty well-scoped entries that the team actively tests and retires is operationally more useful than one with four hundred entries that nobody can act on. Scope discipline is the design decision the register makes about itself.
Sources
- NIST SP 800-37 Rev. 2: https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final
- NIST SP 800-53 Rev. 5: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
- NIST SP 800-53A Rev. 5: https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final
