Control Dependency Governance requires that organisations formally record, validate, and maintain the dependency relationships between governance controls — where one control assumes, requires, strengthens, or weakens another. A governance framework with hundreds of controls inevitably contains controls that depend on one another: AG-001 (Operational Boundary Enforcement) is a precondition for nearly every other control; AG-007 (Governance Configuration Control) underpins all controls that rely on versioned configuration artefacts. Without formal dependency governance, these relationships remain implicit, creating the risk that disabling, degrading, or failing to implement one control silently undermines others. The dependency graph MUST be a versioned, validated artefact that is consulted during implementation planning, conformance assessment, and incident analysis.
Scenario A — Untracked Dependency Causes Cascading Non-Conformance: An organisation implements AG-022 (Behavioural Drift Detection) for its customer-facing agent, achieving Score 3 conformance with independent adversarial testing. However, the drift detection system relies on behavioural baselines that are stored and versioned through the mechanism governed by AG-007 (Governance Configuration Control). When the operations team migrates the configuration store to a new platform, the migration introduces a 72-hour gap during which baseline versions are not immutable. During this window, the drift detection system updates its baselines using corrupted telemetry data from a deployment error. The baselines shift silently. Drift detection continues to report "no drift" because the corrupted baselines are now the reference. The dependency between AG-022 and AG-007 was never formally recorded, so the migration team did not consult the governance team about the impact on drift detection.
What went wrong: The dependency AG-022 → AG-007 was implicit. The migration team had no way to discover that their change to the configuration store affected drift detection integrity. Consequence: 6 weeks of false-negative drift detection, undetected behavioural change in the customer-facing agent resulting in 1,247 non-compliant customer interactions, regulatory notification required under GDPR Article 33, £180,000 in remediation and notification costs.
Scenario B — Circular Dependencies Block Implementation: An organisation attempting to implement controls AG-153 (Control Efficacy Measurement) and AG-056 (Independent Validation) discovers that its implementation of AG-153 requires AG-056 outputs to calibrate efficacy metrics, while AG-056 requires AG-153 outputs to scope validation activities. Neither team can proceed because each is waiting for the other's outputs. The circular dependency was not detected during planning because no dependency graph existed. After 4 months of stalled implementation, both teams independently create stub implementations that satisfy their respective inputs — but neither stub provides meaningful data. Both controls pass conformance assessment at Score 2 while providing no actual governance value.
What went wrong: A circular dependency existed between the two controls' implementations (not their logical definitions). Without a dependency graph that distinguishes logical dependencies from implementation dependencies, the circular relationship was invisible until it blocked progress. Consequence: 4 months of implementation delay, two controls at Score 2 providing no governance value, £210,000 in wasted implementation effort.
Scenario C — Weakening Relationship Not Recorded Produces False Assurance: An organisation implements AG-158 (Standard Evolution and Emergency Update) with an aggressive auto-update mechanism that applies standard changes within 24 hours. The same organisation has AG-219 (Control Taxonomy Governance) implemented with quarterly review cycles. When AG-158 triggers an emergency taxonomy restructuring, the auto-update modifies the taxonomy before the quarterly review can validate the change. The rapid update weakens AG-219's change-control guarantees, but this weakening relationship is not recorded in any dependency register. Conformance assessment reports both controls as Score 2, concealing the fact that AG-158's implementation actively undermines AG-219's integrity.
What went wrong: The weakening relationship (AG-158 implementation can weaken AG-219 guarantees under specific conditions) was not recorded. Dependency governance would have required documenting this relationship and implementing safeguards. Consequence: Quarterly taxonomy review rendered ineffective by uncontrolled emergency updates, false assurance in conformance reports.
Scope: This dimension applies to every organisation that implements two or more controls from the Agent Governance Standard. Even a minimal implementation of two controls may involve a dependency — for example, any control that relies on versioned configuration depends on AG-007. The scope covers four relationship types: (1) "requires" — Control A cannot function without Control B being implemented; (2) "assumes" — Control A's design assumes Control B is present and functioning, but can operate in a degraded mode without it; (3) "strengthens" — implementing Control A increases the effectiveness of Control B; (4) "weakens" — under specific conditions, Control A's implementation can reduce the effectiveness of Control B. The scope extends to implementation-level dependencies (where one control's technical implementation depends on another's infrastructure) as well as logical dependencies (where one control's governance objective assumes another's objective is met).
4.1. A conforming system MUST maintain a formal dependency register recording all known dependency relationships between implemented controls, specifying the relationship type (requires, assumes, strengthens, weakens) and the nature of the dependency.
4.2. A conforming system MUST validate the dependency register against the actual implementation on at least a quarterly basis, verifying that required dependencies are satisfied and that weakening relationships have documented mitigations.
4.3. A conforming system MUST perform a dependency impact assessment before any control is modified, disabled, or decommissioned, identifying all controls that depend on the affected control and evaluating the impact on their effectiveness.
4.4. A conforming system MUST reject or flag for senior governance review any change that would break a "requires" dependency — i.e., disabling or degrading a control on which another implemented control depends.
4.5. A conforming system MUST include dependency relationship verification in conformance assessments, confirming that each control's required dependencies are implemented and effective at the time of assessment.
4.6. A conforming system SHOULD represent dependencies as a directed graph enabling automated cycle detection, impact analysis, and topological ordering for implementation planning.
4.7. A conforming system SHOULD generate automated alerts when telemetry indicates that a dependency source control (the control depended upon) has degraded below its required effectiveness level.
4.8. A conforming system MAY implement dependency strength scoring — quantifying the degree to which one control depends on another, enabling prioritised impact analysis when a control degrades.
Governance frameworks do not consist of independent controls. Controls interact — they assume one another, reinforce one another, and under certain conditions undermine one another. These interactions are a form of coupling, and like all coupling in complex systems, they must be managed explicitly or they will produce unexpected failures.
The Agent Governance Standard contains controls that form long dependency chains. AG-001 (Operational Boundary Enforcement) is a precondition for most other controls — if agents cannot be bounded, monitoring, logging, and drift detection have no reference frame. AG-007 (Governance Configuration Control) is depended upon by every control that stores configuration in a versioned artefact. AG-219 (Control Taxonomy Governance) is depended upon by every control that relies on correct applicability classification. These chains create transitive exposure: a failure in AG-007 can propagate through every control that depends on versioned configuration.
Without explicit dependency governance, three failure modes are predictable. First, cascading non-conformance: disabling or degrading one control silently undermines multiple dependent controls. Second, implementation ordering errors: teams attempt to implement controls before their prerequisites are in place, leading to stub implementations that pass assessment but provide no value. Third, false assurance: conformance assessments evaluate controls in isolation, missing the fact that a control scored at 3 is ineffective because its prerequisite is scored at 0.
Dependency governance makes these relationships visible, trackable, and assessable. It is a meta-governance function — governance of the governance framework's internal structure.
The dependency register should be implemented as a directed graph where nodes are controls and edges are typed dependency relationships. Each edge should record: the source control (the control that depends), the target control (the control depended upon), the relationship type (requires, assumes, strengthens, weakens), a description of the specific dependency, and for "weakens" relationships, the conditions under which weakening occurs and the mitigation in place.
Recommended patterns:
Anti-patterns to avoid:
Basic Implementation — The organisation has documented a dependency register listing all known relationships between implemented controls. The register specifies relationship types and dependency descriptions. Dependency impact is assessed manually before control changes. The register is reviewed quarterly. Dependencies are validated manually during conformance assessments by checking that prerequisite controls are implemented.
Intermediate Implementation — The dependency register is maintained as a directed graph in a machine-readable format. Automated cycle detection, transitive dependency resolution, and impact analysis are available. Conformance assessments automatically verify dependency satisfaction — controls with unmet "requires" dependencies are capped at Score 1. Dependency data is integrated with change management: control changes trigger automated impact reports listing all affected dependent controls. Degradation alerts propagate through the dependency graph.
Advanced Implementation — All intermediate capabilities plus: dependency relationships are validated continuously through automated testing that verifies not just logical dependency but implementation-level dependency (e.g., confirming that the drift detection service can actually reach the configuration API it depends on). Weakening relationships are monitored with specific test cases that detect when weakening conditions are active. The dependency graph is independently audited annually. Dependency strength scoring enables prioritised remediation when multiple dependencies are affected simultaneously.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Dependency Register Completeness
Test 8.2: Dependency Version Immutability
Test 8.3: Impact Assessment Enforcement
Test 8.4: Cascading Dependency Break Detection
Test 8.5: Circular Dependency Detection
Test 8.6: Conformance Score Capping for Unmet Dependencies
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 17 (Quality Management System) | Supports compliance |
| ISO 42001 | Clause 8.2 (AI Risk Assessment) | Supports compliance |
| NIST AI RMF | GOVERN 1.2, MANAGE 2.3 | Supports compliance |
| SOX | Section 404 (Internal Controls) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Supports compliance |
| DORA | Article 5 (ICT Risk Management Governance) | Supports compliance |
Article 9 requires a risk management system that identifies risks and implements mitigation measures. Control dependency governance ensures that mitigation measures do not have untracked dependencies on one another — a mitigation that depends on another mitigation that is not implemented provides no actual risk reduction. Dependency governance is the mechanism by which the organisation verifies that its risk mitigation architecture is internally consistent.
Clause 8.2 requires AI risk assessment to consider the interdependencies between controls within the AI management system. AG-220 provides the structured mechanism for recording and validating these interdependencies, ensuring that risk assessments account for cascading failures where one control's degradation undermines others.
SOX auditors assess internal controls as a system, not as isolated mechanisms. A control that depends on another control that is deficient is itself deficient — this is the concept of "compensating controls" in SOX auditing. AG-220 provides the dependency map that auditors need to trace control relationships and evaluate systemic control effectiveness. Without it, the auditor must independently discover dependencies — a process that is incomplete and inconsistent.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Organisation-wide — affects the integrity and reliability of the entire governance framework |
Consequence chain: Without dependency governance, disabling or degrading one control can silently undermine multiple other controls without detection. The immediate failure mode is cascading non-conformance — a chain of controls that appear individually compliant but are collectively ineffective because a shared dependency is unmet. The downstream consequence is false assurance: conformance reports show high scores while actual governance effectiveness is degraded. The ultimate business consequence surfaces during incidents, when the organisation discovers that controls it relied upon were ineffective because their prerequisites were not in place. In regulated sectors, this maps to systemic control failure — a finding that the governance framework as a system was inadequate, not merely that an individual control failed.
Cross-references: AG-219 (Control Taxonomy Governance) provides the control set within which dependencies are tracked. AG-007 (Governance Configuration Control) is a frequently-depended-upon control whose health affects many others. AG-153 (Control Efficacy Measurement) provides the effectiveness metrics that dependency validation consumes. AG-222 (Conformance Profile Governance) must account for dependencies when defining conformance profiles. AG-056 (Independent Validation) should include dependency verification in its validation scope.