One posture. Every framework.

The Duplication

Consider an organization that must comply with CMMC Level 2, FedRAMP, SOC 2 Type II, and ISO 27001. Each framework requires access control. CMMC practice AC.L2-3.1.1 requires limiting system access to authorized users. FedRAMP requires NIST 800-53 control AC-2 (Account Management) with FedRAMP-specific parameters. SOC 2 criterion CC6.1 requires logical and physical access controls. ISO 27001 control A.8.2 requires privileged access rights management. These are not four different security requirements. They are four different expressions of the same underlying requirement: manage who has access to what. The organization implements one set of access controls. It operates one identity provider. It enforces one set of privilege policies. But it assesses that implementation four times, collects evidence four times, writes narratives four times, and presents the results to four different assessors in four different formats.

The duplication extends beyond individual controls. Each framework requires a system description, an authorization boundary definition, a risk assessment, an incident response plan, a change management process, a vulnerability management program, and an evidence collection methodology. These organizational controls are largely identical across frameworks. The incident response plan that satisfies CMMC practice IR.L2-3.6.1 also satisfies NIST 800-53 control IR-1, FedRAMP's IR-1 requirement, SOC 2 criterion CC7.3, and ISO 27001 control A.5.24. But because each framework assessment is treated as an independent project, the incident response plan is reviewed, updated, and formatted separately for each. The same document is repackaged four times. The same control owner answers the same questions from four different assessors. The same evidence is collected into four different repositories.

The scale of duplication shows up in any published cross-walk. Lay the four catalogs side by side and the list of distinct requirements looks enormous. Trace each requirement back through the NIST 800-53 derivation chain and the number of unique underlying security capabilities is far smaller: most requirements in one framework restate a requirement another framework already carries, differing in wording and parameter values rather than in substance. An organization that treats each framework independently assesses the full sum. An organization that recognizes the structural overlap assesses the unique set once, then handles the framework-specific differences as parameter adjustments. The gap between those two programs is engineering time, compliance analyst effort, and assessor cost that produces no additional security value. None of that spend hardens anything.

The Problem

Multi-framework duplication is not just an efficiency problem. It creates inconsistency. When the same control is assessed independently for different frameworks, the assessments often produce different results. The CMMC team rates access control as "implemented" because the policy exists and IAM roles are configured. The FedRAMP team rates the same access control as "partially implemented" because the automated account review mechanism required by the FedRAMP-specific parameter for AC-2 is not operational. The SOC 2 auditor evaluates the same access control over a twelve-month operating period and identifies three months where access reviews were not completed on schedule. The ISO 27001 assessor evaluates the same capability and notes that privileged access is not reviewed at the frequency specified in the organization's own policy. Same control. Same infrastructure. Four different assessments. Four different conclusions. None of them wrong. All of them incomplete.

Siloed assessment teams compound the inconsistency. In many organizations, CMMC compliance is managed by the security team, SOC 2 is managed by the compliance or legal team, FedRAMP is managed by a dedicated authorization team, and ISO 27001 is managed by the quality or operations team. Each team maintains its own evidence repository, its own assessment schedule, its own relationship with its assessor, and its own understanding of what "implemented" means for the controls they manage. When the security team remediates a gap discovered during CMMC preparation, the remediation is not automatically reflected in the SOC 2 evidence repository. When the FedRAMP team updates a control narrative to address an assessor finding, the CMMC narrative for the same control is not updated. Drift between framework assessments accumulates silently. The organization maintains four separate, increasingly divergent descriptions of the same security posture.

The financial cost of duplication is substantial but often invisible because it is distributed across multiple budgets. Assessment fees are the most visible: each framework assessment carries its own engagement cost. But assessment fees represent a fraction of the total. The larger cost is internal: engineering hours spent collecting duplicate evidence, compliance analyst hours spent writing duplicate narratives, management hours spent in duplicate governance reviews, and the opportunity cost of security engineers maintaining compliance artifacts instead of improving security posture. Every hour that repeats work already done for another framework produces no unique security value, and in a siloed program the repeated share dominates. None of it includes the tooling bought per framework, or the security improvements deferred because the team was busy re-collecting evidence it already held.

The Derivation Chain

The duplication problem has a structural answer because the frameworks themselves are structurally related. NIST Special Publication 800-53 revision 5 defines a comprehensive catalog of security and privacy controls organized into control families. This catalog is the root of the compliance framework tree for United States federal and defense requirements. Every other major US compliance framework either selects controls from this catalog directly, derives requirements from it through a published mapping, or maps to it through an intermediary. The derivation chain works in layers. At the root sits NIST 800-53, the comprehensive control catalog. FedRAMP selects baselines from this catalog and adds program-specific requirements and parameters. One layer above, NIST 800-171 derives its security requirements from the 800-53 Moderate baseline. CMMC Level 2 adopts the 800-171 control set; the published cross-walk is its identity. At each layer, the derivation is documented, traceable, and maintained by the issuing authority.

Organizations that do not understand the derivation chain treat each framework as an independent body of requirements. They miss the structural relationships that connect CMMC practices to NIST 800-171 requirements to NIST 800-53 controls to FedRAMP baselines. They miss the bridging mechanisms that connect international frameworks like ISO 27001 through the NIST Cybersecurity Framework. They miss the published cross-walks that map SOC 2 Trust Service Criteria to NIST controls. Without this understanding, every framework appears to be a standalone compliance program requiring standalone effort. The derivation chain is not approximate. It is published, deterministic, and maintained by the framework authorities themselves. NIST publishes the mappings between 800-53 and 800-171. NIST publishes the control baselines that FedRAMP selects from. The AICPA publishes the mapping between SOC 2 Trust Service Criteria and NIST frameworks. These are not interpretive alignments created by consultants. They are structural relationships published by the organizations that created the frameworks.

In the Redoubt Forge design, that tree is the data model. The mapping engine in Rampart is specified around five mapping strategies, each recorded on the mapping it produces: native, for a framework assessed in its own terms; via 800-53, for the derivation chain itself; via CSF, for frameworks that bridge through the NIST Cybersecurity Framework; cross-walk, for published mappings like the AICPA's SOC 2 criteria; and AI-suggested, for control pairs no authority has mapped. Strategy records how a mapping was derived. A separate fidelity axis records how authoritative that derivation is: authoritative, published, derived, or AI-suggested. An AI-suggested mapping counts toward posture only after a named human confirms it; the design refuses to score a guess. Every mapping carries its full resolution path as data: requirement identifier to Control Correlation Identifier to 800-53 control to target practice. The reference data behind those strategies is itself enumerated in the design as eight named sources, the DISA CCI list and the published framework cross-walks among them, entering as signed registry rows. Framework catalogs enter the same way, ingested from the issuing authorities' own machine-readable formats, NIST OSCAL among them.

AC-2 Example

NIST 800-53 control AC-2 (Account Management) requires organizations to define and manage system accounts, including establishing conditions for group and role membership, specifying authorized users, and requiring approvals for account creation. This single control appears across frameworks under different names with different parameters. In CMMC Level 2, it manifests as practice AC.L2-3.1.1 through the NIST 800-171 derivation (requirement 3.1.1: "Limit information system access to authorized users, processes acting on behalf of authorized users, or devices"). In FedRAMP, AC-2 appears directly as a required control with program-set parameter values: fixed review frequencies for accounts, stricter frequencies for privileged accounts, and automated handling of inactive accounts. In SOC 2, the same underlying capability maps to CC6.1 under the Common Criteria category. In ISO 27001:2022, it maps to control A.8.2 (Privileged Access Rights).

The security implementation for AC-2 is singular. The organization operates one identity provider. It configures one set of role-based access policies. It runs one access review process. It collects one set of access logs. The technical reality is one implementation. But in a siloed compliance program, this single implementation generates five separate assessment activities: one for CMMC, one for FedRAMP, one for SOC 2, one for ISO 27001, and one for the underlying NIST 800-53 authorization if the organization maintains an ATO. Five assessors ask five sets of questions about the same access controls and receive five separately compiled evidence packages. The parameter differences between frameworks are real but narrowly scoped. FedRAMP fixes review frequencies. CMMC requires "periodic" review without fixing one. SOC 2 requires demonstration of operating effectiveness over the audit period. ISO 27001 requires adherence to the organization's own stated policy frequency. These are not different controls. They are different parameter values applied to the same control.

The design resolves that chain as recorded data rather than as analysis repeated per assessment. A DISA STIG check enters through its Control Correlation Identifier, the join key DISA publishes for exactly this purpose, and lands on AC-2; the derivation chain carries the same satisfaction to CMMC practice AC.L2-3.1.1; a published cross-walk carries it to SOC 2 CC6.1 and onward to ISO 27001 A.8.2. Each mapping row in the Rampart schema states its extent as well as its path: full when the source satisfies the target requirement entirely, partial with a required note naming what is not covered, and a partial mapping never carries full posture weight. Posture itself is held per framework and per control, and its recorded basis is the set of satisfying mappings, never a bare verdict; an assessor who asks why a control reads satisfied is answered with the mappings that satisfy it. The organization implements to the strictest parameter across its frameworks. It proves once. Every framework reads the proof through its own baseline.

Evidence Compounding

The first framework an organization tackles requires full effort: every control must be assessed, every defense must be implemented or documented, every evidence artifact must be collected, and every narrative must be written from scratch. If that first framework is CMMC Level 2, the organization assesses every practice, implements the required security controls, collects evidence for each, and writes narratives describing how each practice is satisfied. The second framework builds on the first. If the organization next pursues FedRAMP, a large share of the controls it encounters overlap with work already completed for CMMC through the NIST 800-53 derivation chain. The incremental effort is the controls that do not overlap, plus parameter adjustments for controls that overlap but carry stricter FedRAMP-specific values.

Without automation, evidence cannot compound. The access review completed for CMMC sits in the CMMC evidence repository. The FedRAMP team does not know it exists or where to find it. Even if they find it, they cannot determine whether it satisfies FedRAMP's stricter parameter requirements without manual analysis. The compounding effect is theoretically available in every multi-framework program. In practice, it is realized only when a system can trace evidence through the derivation chain automatically, evaluate it against each framework's parameters independently, and surface the results in a unified view. Without that system, each framework team operates independently, collecting overlapping evidence into separate repositories, unaware that the work has already been done. The theoretical overlap produces zero actual efficiency because no mechanism connects the evidence streams across frameworks.

The design makes compounding the default rather than the exception. Sentinel is designed to collect evidence once from connected infrastructure, and the design's evidence fabric carries it through a collection-to-satisfaction pipeline rather than into a per-framework folder. When a satisfaction mapping lands, the mapping engine's cross-framework coverage recompute is specified to advance every framework the derivation chain reaches from that evidence, not just the framework the collection was aimed at: one access review reaches CMMC AC.L2-3.1.1, FedRAMP AC-2, SOC 2 CC6.1, and ISO 27001 A.8.2 through their recorded mappings. Freshness is structural. Every mapping carries a freshness horizon, the design's instantiation of belief expiry, and when the horizon passes on a load-bearing mapping the control flips to other-than-satisfied and a re-observation demand issues; stale evidence never silently satisfies. Readiness itself is specified as an answer that carries its proof: a readiness projection states the per-state counts it was computed from, satisfied through unassessed, and anchors to a citable event sequence. Its scoring parameters are signed data in the design, never code.

Overlay Composition

Frameworks do not exist in isolation. They are modified by overlays: additional requirements that adjust, extend, or constrain the base framework for a specific context. DISA SRGs add implementation guidance and verification checks to NIST 800-53 controls for specific technology categories. DISA STIGs further refine SRG requirements for specific products and versions. CIS Benchmarks overlay platform-specific hardening requirements onto the same control families. FedRAMP adds parameters and additional requirements to the 800-53 baseline. DoD Impact Levels (IL2, IL4, IL5, and IL6; the issuing authority retired IL3 into IL4) add progressively stricter data handling and isolation requirements. Each overlay modifies the base framework in a specific, documented way. The base control remains the same. The overlay changes how it must be implemented, what evidence is required, or what parameter thresholds apply in a particular context.

Manual overlay stacking creates conflicts. When an organization applies a DISA STIG overlay, a CIS Benchmark overlay, and FedRAMP parameter requirements to the same base NIST 800-53 control, the three may specify different values for the same parameter: one a floor, another a stricter floor, a third an exact value. Without a deterministic way to compose them, the organization must manually identify every parameter conflict across every overlay for every control in every framework. For an organization with four frameworks and three overlay types across its whole control set, that combinatorial analysis is prohibitive. Organizations either resolve conflicts on an ad hoc basis (introducing inconsistency) or apply the strictest parameter globally (which may violate the specific requirements of an overlay that mandates a particular value rather than a minimum).

The Redoubt Forge design treats overlays as grammar, not judgment. The overlay registry carries 25 rows: static overlays beside three instance families whose counts re-derive at each ingest, 200+ DISA STIGs, 6 DISA SRGs, and 26 CIS Benchmarks, every row naming its issuing authority and its base framework. An overlay speaks three operations against that base: ADD introduces a requirement the base does not carry, MODIFY changes an implementation requirement for an existing control, and PARAMETER sets a specific value such as a review frequency. The grammar deliberately has no remove. An overlay may add and may tighten, never silently drop, and authoritative removal stays with the framework that owns the control. Where an authority publishes a pre-resolved baseline beside its profile, the design draws the published artifact and keeps local resolution as the fallback, because resolution is normatively defined and a conformant resolver is deterministic. Conflicting derivations get no silent winner: the affected control is marked contested in Rampart and resolution machinery engages. And walking an obligation back is never quiet. Overlay activation is entitlement-gated; deactivation is specified as a human-only ruling, because removing an overlay removes the obligations being failed, and readiness must never rise by an anonymous hand.

Adding Frameworks

Adding a new compliance framework to an existing program should be an incremental operation. The organization already has a security posture. It already collects evidence. It already maintains control narratives and assessment records. A new framework introduces its own control structure, its own parameter requirements, and its own assessment methodology. But if the new framework derives from the same NIST 800-53 root as the existing frameworks, the majority of its controls map to controls already assessed. The incremental effort consists of three categories: controls that are genuinely new (not present in any existing framework), controls that overlap but require stricter parameters (requiring implementation adjustments), and controls that overlap completely (requiring no additional work beyond activating the mapping).

Without a derivation engine, each new framework adds full effort. The compliance team must manually analyze every control in the new framework, determine which existing controls it maps to, identify parameter differences, assess gap coverage, and build a remediation plan. This analysis takes weeks for a framework of any real size. The team must then collect evidence for the new framework's assessment, even though most of the required evidence already exists in the repositories maintained for other frameworks. They must write narratives formatted for the new assessor, even though the underlying implementations are the same ones described in existing narratives. Each new framework adds nearly linear cost because the manual process cannot use the structural overlap that the derivation chain provides. Organizations defer new frameworks not because the security work is prohibitive, but because the compliance overhead of adding another independent assessment program is prohibitive.

The design carries the catalog so the organization does not. The framework registry holds 18 frameworks as 25 rows, nothing folded: CMMC levels, NIST 800-171 revisions, SOC 2 types, and RMF and FISMA each carried as their own row, every row naming its issuing authority, source format, and update cadence. Registry rows are signed reference data, and catalogs are ingested from the authorities' machine-readable publications on the cadence each row declares, with change detected by digest and a failed ingest falling closed to the last good catalog. Activating a framework is specified as a birth, not a project: a posture row is born for every control in the resolved tailored baseline and a recompute is queued, and where live mappings derived from evidence already held meet a control's requirement, that control reads satisfied from the first recompute. The readiness projection states, from its first computation, which controls the derivation chain has already answered and which remain unassessed. Framework change rides the same machinery under the design's release-day law: when an authority publishes a new version, the diff is computed with affected controls, evidence, and org deltas known on release day, migration plans generated, and recomputes queued for every affected org and control, and only those. The tenth framework costs a fraction of the first because the posture underneath was built once, rooted in the NIST 800-53 catalog every subsequent framework draws from.

The Result

The economics of multi-framework compliance invert when duplication is eliminated. The effort that reaches a first framework certification builds the security posture, evidence infrastructure, and control narratives that support every subsequent framework in the derivation chain. The second framework requires incremental effort for its unique controls and parameter adjustments. The third framework adds less. The fourth framework adds less still. The effort curve flattens because the underlying security posture is framework-agnostic: it was built from the comprehensive NIST 800-53 catalog, and every framework that derives from that catalog inherits the work already completed. The organization does not pursue four compliance programs. It maintains one security posture and expresses it through four framework lenses. The distinction is fundamental. Four programs multiply cost. One posture divides it.

The assessment experience is designed to change in parallel. Instead of separate evidence packages prepared for separate assessors on separate timelines, the design holds one evidence stream and renders every assessment as a projection of it: a CMMC assessment, a SOC 2 operating-effectiveness period, and a FedRAMP parameter check are lenses over the same record, not packages assembled beside it. An assessor who needs a fixed target gets a sealed snapshot, anchored to a citable event sequence and digest-sealed, while the team keeps working live; both views project from the same log, which is why the answer survives the engagement. Integrity is structural rather than asserted: the architecture chains each org's events under SHA-256 and seals signed checkpoints over them, so evidence authenticity is independently verifiable instead of resting on the assembler's word. The evidence is not assembled for an assessment. In this design it is the byproduct of the defended system itself.

Citadel is the designed vantage over all of it: an aggregated command dashboard with continuous posture as its base layer, assessments as an overlay, and cards prioritized by role, never hard-filtered, so one view carries the organization's posture expressed through every active framework at once. The charter of Rampart states the division of labor plainly: it interprets security state against frameworks and renders posture, findings, POA&Ms, and documents from truth other parts of the design collect, with every assessment, readiness score, and compliance document a projection of continuous state, never a point-in-time construction. Readiness projections and snapshot digests are specified to export as machine-verifiable attestation through Alliance, so what an organization proves inward it can prove outward. The duplication is gone from the model, not merely trimmed from the workflow. One security posture, computed from actual defenses, projected into every framework the organization needs: the founding conviction of the design is that compliance proofs are generated as a byproduct of real security, and every framework is a projection of one defended implementation. The fourth framework at a fraction of the first. The tenth at less.