The walk we already take
Anyone who has built a security plan for a resource team knows the moment. You reach a control the team doesn't implement themselves, such as identity, logging, backup, or physical access to the data center, and the honest answer is "central IT does that."
So you step through. You find the common control service provider, ask how the control is implemented, look at the evidence, and come back with enough to write the control into the team's plan.
Do that for every inherited control and you have traced a dependency tree. The team's resource is the root, the services it relies on are the branches, and those services' own vendors often sit beneath them. We rarely call it a tree and almost never draw it, but every cyber risk professional walks it. (The other D&D is a coincidence, although mapping an inheritance chain by hand does feel a little like a dungeon crawl.)
The walk is good practice. The problem is what we bring back from it.
What the walk leaves behind
What we bring back is a copy. The provider's implementation, as it stood on the day we asked, gets written into the team's plan. From then on nothing connects the two. The plan holds a snapshot, and the service carries on changing.
In a single plan that is a manageable weakness, because the next review will catch it. But common control services exist because many teams use them. One identity service can sit under hundreds of plans, each holding its own snapshot, each taken on a different day by a different person.
So the structure we walked as a tree looks different from the provider's side. It is a graph, with a great many edges pointing at one node, and none of those edges were recorded anywhere.
Drift nobody caused
We usually talk about configuration drift as something going wrong: an unauthorized change, or a setting that slid away from its baseline. Security controls are part of the configuration, and they drift the same way. The uncomfortable version is the one where nothing went wrong at all.
Suppose a provider stops implementing a control that others rely on. Perhaps they shorten log retention, or hand a function to a different vendor. They take the change through change management and update their own documentation. Every step is done properly.
Several hundred plans across the organization still describe the old state. The provider has no list of who depends on them, and the dependent teams have no reason to look.
The change can go either way, and the two cases fail differently:
- A control is removed or weakened. Dependent plans now attest to something that no longer exists. This is false assurance, and it tends to surface during an audit or an incident.
- A control is added. This sounds harmless, but dependent plans now understate their coverage. A new provider control can also bring a new responsibility for the consumer, one that nobody downstream knows they have picked up.
In both cases the documentation is accurate where the change happened and wrong everywhere that depends on it. More care in the manual walk doesn't fix this, because the walk only runs in one direction. The consumer can reach the provider. Nothing lets a change at the provider reach the consumer.
Automating the tedious
Federated Cyber Risk (FCR) shares the five principles of participation that run through all the Federated Cybersecurity methodologies, and two of them bear directly on this problem. The first is Automating the Tedious: the work people dread gets done automatically.
Dependency tracking qualifies. Stepping through to every provider, for every inherited control, in every plan, is the part of security planning nobody looks forward to. In FCR the provider documents once what their service delivers to its customers. A team's plan then inherits those controls from the service instead of restating them, and the dependency is recorded as part of doing the work.
It would be easy to stop there and count the hours saved. The more important result is what the record makes possible. An inherited control is now a reference to the provider's inventory, not a copy of it, and every plan that holds that reference is known. The edges of the graph exist, so a change finally has something to travel along.
Knowledge at the point of decision
The second principle is Knowledge at Point of Decision: insight delivered when it can be acted on, not buried in reports.
From a dependent team's point of view, a provider's updated documentation is a report they will never read. FCR doesn't ask them to read it. When a provider's control inventory changes, every plan that inherits from it is marked as drifted and gets what we call a Cheese Flag, named for the old question of who moved the cheese.
The flag sits on the dependent team's own plan, at the control that changed. It tells them that something they rely on is no longer what their plan says it is.
On the left, each plan walked to the provider once and kept a copy, so only the provider knows the control changed. On the right, the recorded dependency carries the change to every plan.
That turns drift from a discovery into a task. The team reviews the change, re-inherits the control, and deals with what it means for them: a gap to fill, a new responsibility to take on, or nothing at all. The provider can see which of their consumers are in sync and which are not. Nobody had to remember to ask.
The logic is the same at every level of the tree. Wherever one node inherits from another, a change at the source belongs in front of whoever depends on it.
Checking your own tree
None of this asks you to believe anything new. We already know the dependency trees are there, because we walk them. What matters is whether the walk leaves behind anything a change can follow.
Three questions will show where your own program stands:
- If a common control provider changed a control tomorrow, could you list the plans that depend on it?
- Would the teams behind those plans find out, and how long would it take?
- When a plan says a control is inherited, is that a pointer to the provider's current state, or a description of how it looked on the day someone asked?
If the answers are yes, quickly, and a pointer, your program already has drift in hand. If they aren't, the trees are still there. They aren't recorded anywhere a change can find them.