Episode 42 — Causal Tools: DAGs as a Way to Explain “What Drives What”
In Episode forty two, titled “Causal Tools: D A G s as a Way to Explain ‘What Drives What,’” we take causal thinking and give it a practical structure you can carry into exam scenarios and real decision rooms. Many analysis mistakes happen not because someone cannot compute a statistic, but because they never made their assumptions explicit about what influences what. A causal graph gives you a disciplined way to lay those assumptions out so you can see where bias can enter, where a control variable helps, and where it quietly harms. That structure matters on the exam because scenario questions often hide the real challenge in the relationships between variables, not in the math. Once you can translate a story into a causal picture, you stop guessing and start reasoning.
A directed acyclic graph, or D A G, is a specific kind of causal graph used to represent directional cause paths without loops. “Directed” means the connections have arrows, so the graph encodes an assumed direction from cause to effect rather than a vague association. “Acyclic” means you cannot start at one variable, follow arrows, and return to the same variable, which rules out feedback loops in a single diagram and keeps the logic clean. The point is not that feedback never exists in reality, but that a single D A G captures a simplified causal story for a specific question at a specific time scale. When you see a D A G in exam language, it is essentially an argument about how the world works, written as a diagram instead of a paragraph.
Before we continue, a quick note: this audio course is a companion to the Data X books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
In a D A G, nodes represent variables, and arrows represent your assumptions about causal direction between those variables. A node could be something like “training completed,” “phishing click rate,” “incident volume,” or “asset criticality,” and the node is meant to stand for a measurable concept even if measurement is imperfect. An arrow from one node to another means you believe changes in the first can produce changes in the second, at least in the context you are modeling. That does not mean the relationship is proven, only that it is the causal claim you are evaluating, which is why the diagram is most useful before you run any model. The exam often rewards this mindset because it shows you understand that modeling is downstream of assumptions, not a substitute for them.
One of the main reasons to draw a D A G is to identify confounding paths that create spurious associations between variables you care about. A confounding path is a route through the graph that links your treatment or predictor to your outcome in a way that is not the causal effect you want, often because a third variable influences both. When that path is open, you can observe a strong association even if the treatment has no real impact, because the confounder is pushing both variables in the same direction. In business and security settings, a classic example is when “team maturity” affects both “control adoption” and “incident rates,” making the control look powerful even if maturity is the true driver. Seeing that path visually helps you understand why simple comparisons can mislead, which is exactly the kind of reasoning exam scenarios test.
The backdoor criteria is a concept used to decide what to control for, and you do not need heavy formalism to use it correctly in exam contexts. Conceptually, it tells you to block the non causal paths that connect your treatment to your outcome through shared causes, while leaving the true causal path intact. You block a backdoor path by conditioning on certain variables, meaning you account for them so they cannot distort the estimated relationship. The reason this matters is that “control for everything” is not a safe rule, because some variables create bias when controlled, and others are irrelevant noise that only adds variance. The exam often expects you to choose a control set that reflects causal logic rather than enthusiasm for including more columns.
To make this practical, imagine a straightforward business scenario and describe a D A G verbally, because you may not get to draw anything on the exam. Suppose a company deploys multi factor authentication, spelled m u l t i factor authentication, and wants to know whether it reduces account compromise. You might say that “multi factor authentication adoption” points to “account compromise rate,” because the control is intended to change the outcome, and you might add that “user role criticality” points to both “adoption” and “compromise rate” if high value roles are prioritized and also targeted. You could also include “security awareness participation” pointing to both, if engaged teams both adopt faster and behave more safely. Even without a picture, that verbal structure clarifies the causal story and prepares you to reason about what must be accounted for.
A common trap, both on the exam and in practice, is controlling for a collider, which can introduce bias unexpectedly. A collider is a variable that has two arrows pointing into it, meaning it is an effect of two separate causes, and conditioning on it can open a path that was previously closed. In plain terms, you can create an association between two variables that were otherwise independent, simply because you selected or adjusted on a variable that sits downstream of both. For example, if “incident investigation intensity” is influenced by both “true incident severity” and “team reporting culture,” controlling for investigation intensity can distort relationships and make reporting culture appear to cause severity. The D A G helps you spot these structures, and the exam loves them because they separate causal thinkers from people who rely on generic modeling habits.
Mediators are another important structure, and they require careful interpretation because they often represent mechanism rather than nuisance. A mediator sits on the causal pathway from treatment to outcome, meaning the treatment affects the mediator, which then affects the outcome. If you control for a mediator, you may remove part of the very effect you are trying to estimate, which can be appropriate only if your goal is a direct effect that excludes that mechanism. In security terms, a training program might reduce incidents partly by reducing risky clicks, so “click behavior” could be a mediator between “training” and “incidents.” Treating that mediator as a nuisance variable to be adjusted away can lead you to conclude training does little, when in fact you erased its main pathway. The exam expects you to recognize that mediators explain how an effect happens, not merely clutter to be removed.
Once you can recognize confounders, colliders, and mediators, you are ready to decide on adjustment sets that estimate treatment effects more reliably. An adjustment set is the group of variables you condition on to block backdoor paths without blocking the causal effect you want to measure. In many exam scenarios, you are effectively choosing between “adjust for the confounder” and “adjust for something that seems related but is actually harmful,” and the D A G logic guides that choice. You want to include common causes of both treatment and outcome, and you want to avoid variables that are effects of the treatment, effects of the outcome, or colliders that link otherwise separate causes. When you explain your choice in words, the strongest answers sound like causal reasoning rather than feature shopping.
This has a direct connection to feature selection when you are doing causal modeling rather than pure prediction. In predictive work, you can include any variable that improves accuracy, even if it is downstream of the outcome or reflects leakage, because prediction is judged by performance on new data. In causal work, the goal is different, because you are trying to estimate what would change if you intervened, and that requires features that support valid comparisons rather than features that merely correlate. A D A G helps you see that some variables should be excluded even if they are strong predictors, because they can encode effects of the treatment or selection processes that bias estimates. On the exam, this shows up when a tempting variable seems “obviously useful,” but the correct reasoning is that it contaminates the causal estimate. The disciplined move is to choose features that represent confounders and baseline context, not consequences.
Another critical point is that D A G assumptions are hypotheses, not proven facts, and you should communicate them that way. The arrows in a D A G are claims about the data generating process, and in real work those claims should be informed by domain knowledge, process understanding, and sometimes qualitative evidence. The diagram is valuable precisely because it makes those claims explicit, so others can challenge them, refine them, or propose alternative structures that change what should be controlled. On the exam, you are not being asked to prove the arrows, but to reason consistently given the causal story in the scenario and to avoid contradictions like treating an effect as a cause. When you remember that the diagram is a hypothesis, you stay appropriately cautious and you avoid overstating what observational data can establish.
Because the graph is explicit, it also becomes a powerful tool for explaining why some data fields must be included, even when stakeholders would rather ignore them. If a variable is a confounder, leaving it out means you are mixing causal effects with selection and context, which can lead to misleading conclusions about what worked. For instance, if “asset criticality” influences both “control deployment priority” and “incident likelihood,” then criticality is not an optional extra column, it is part of the minimum context needed for a fair comparison. The same logic applies to “exposure level,” “user privilege,” or “business unit risk,” depending on the scenario, because these often shape both treatment assignment and outcomes. The exam cares because it wants you to justify data needs based on causal necessity rather than convenience. When you can say, in plain language, that a field is required to block a bias path, you demonstrate mature causal reasoning.
At this point, it helps to keep a short memory anchor that you can apply under time pressure: arrows show assumptions, paths show bias risks. The arrows remind you that you are not merely describing correlations, you are asserting a direction that must match the scenario and the logic of intervention. The paths remind you that bias is often not about a single variable, but about how variables connect, especially through confounding routes or through accidental openings created by conditioning on the wrong node. When you scan a causal story with that anchor in mind, you naturally look for shared causes that must be adjusted for and for tempting variables that might be colliders or mediators. This is exactly the kind of mental checklist that improves exam accuracy because it keeps you from making confident but structurally wrong choices. The anchor is simple, but it turns a vague story into a disciplined causal argument.
To conclude Episode forty two, imagine you are given a short scenario and you need to build a verbal D A G and then name one confounder, because that is the habit the exam is trying to cultivate. Take a claim like “deploying endpoint detection reduced ransomware events,” and translate it into arrows where “endpoint detection deployment” points to “ransomware events,” while asking what might influence both deployment and events. A plausible confounder in many organizations is “asset exposure,” because highly exposed systems are prioritized for detection and are also more likely to face ransomware attempts, which can make deployment appear more effective or less effective depending on direction and measurement. Once you name that confounder, you can explain why it must be included in an adjustment set to block the bias path and support a more reliable estimate of impact. That simple move, building the causal story and naming a confounder, is how you turn graphs into better answers and better decisions.
