How to Prove Your Compliance Actually Works: A Practical Guide to Building Confidence
- Raimund Laqua
- 34 minutes ago
- 8 min read
If you're responsible for compliance, you've probably faced this uncomfortable question: "How do you know you're actually compliant?" Most organizations point to policies, training records, and audit reports. But there's often a nagging gap between having documentation and having genuine confidence that your obligations are truly being met.
This is where Goal Structuring Notation (GSN) and claim trees become game-changers. They're tools borrowed from safety-critical industries like aerospace and nuclear energy that help you build bulletproof arguments proving your compliance approach actually works. Let me show you how this applies to the real world of operational compliance.
The Core Problem: Bridging the Gap Between Obligation and Reality
When a regulator says "you must protect customer data" or a standard requires "annual risk assessments," there's a massive gap between that external demand and what actually happens inside your organization.
Typically, someone writes a policy, IT implements some controls, training gets scheduled, and an auditor eventually checks some boxes. But can you actually prove that these activities fulfill the obligation? Can you show the clear, logical chain from requirement to result? Usually, no. And that's exactly the problem GSN and claim trees solve.
The Lean Compliance Operational Model recognizes that obligations don't magically get fulfilled. Instead, there's a structured flow: external obligations must be transformed into internal promises (commitments that real people make about their own behavior), those promises must be coordinated by programs (governance structures that steer and align), and finally systems (the actual processes, tools, and people) must execute those promises to deliver outcomes.
Understanding this flow is critical because each layer represents a potential point of failure, and each layer needs assurance.
What GSN Brings to the Table
Goal Structuring Notation is simply a visual way to show your argument for why something is true. Think of it like building a legal case, but for compliance. You make a top-level claim like "We comply with ISO 27001," and GSN forces you to systematically break that down into answerable questions.
What strategy are you using to achieve this?
What are the sub-claims that must be true for your top claim to hold?
What evidence supports each sub-claim?
It creates a tree-like diagram where you can't hide gaps or hand-wave difficult questions.
For compliance using the Lean Compliance model, your top goal is always some variant of "We fulfill [specific obligation]." Then you decompose this through the operational layers.
First, you need to prove you have the right promises in place—that someone has actually committed to doing what's needed, and that those commitments cover everything the obligation requires.
Second, you need to show that programs are governing effectively, coordinating these promises and steering systems toward the right outcomes.
Third, you need to demonstrate that systems are actually delivering on those promises reliably and consistently.
Finally, you need to prove that the outcomes you're achieving actually fulfill the original obligation. Each of these becomes a major branch in your GSN tree.
How Claim Trees Provide the Evidence
While GSN shows the structure of your argument, claim trees show the evidence behind it. When applied to the Lean Compliance Operational Model these are evidence that commitments (i.e. promises) where kept.
A claim tree starts with a statement you need to prove and systematically breaks it down into smaller, more specific statements that are easier to prove with concrete evidence. Each branch represents a necessary condition, and each leaf eventually points to a specific piece of evidence that you can touch, verify, and date.
Let's say you need to prove that "Our CISO can reduce information security risks to acceptable levels." This isn't something you can just assert. You need to break it down.
Does the CISO have the necessary skills to identify and evaluate risks? You prove this with certifications, training records, and demonstrated experience.
Does the CISO have authority to implement risk treatments? You prove this with delegation letters and budget approval authority.
Does the CISO have access to the systems and processes needed to actually reduce risk? You prove this with access control matrices and evidence of control implementations.
Has risk actually been reduced? You prove this with metrics showing risk levels before and after interventions, incident data, and independent assessments.
Notice how each question demands specific, verifiable evidence. No hand-waving is allowed.
Getting the Outcome Right: Beyond Procedural Compliance
Here's where many compliance programs go wrong, and it's worth pausing on this point. When ISO 27001 requires "conducting regular information security risk assessments," the procedural view focuses on the activity: did someone complete a risk assessment document? Did they do it on schedule? Does it have all the required sections? Auditors check boxes, the assessment report goes in a folder, and everyone moves on.
But that completely misses the point. The operational view asks a fundamentally different question: are information security risks actually being managed to acceptable levels? The risk assessment isn't the goal—it's a means to an end. The real obligation is about achieving a state of managed risk, where threats are identified, evaluated, and addressed through appropriate controls that either reduce the likelihood of bad things happening or cushion the organization against their effects when they do.
This shift in perspective changes everything about how you structure your assurance argument. Your top-level goal shouldn't be "We conduct annual risk assessments." It should be "Information security risks are maintained at acceptable levels." Now your promises need to reflect actual risk management activities: someone promises to identify emerging threats, someone promises to evaluate their potential impact, someone promises to implement controls that reduce risk, someone promises to monitor whether those controls are working, and someone promises to adjust when they're not. The risk assessment becomes one tool in this broader promise network, not the end goal itself.
A Real-World Example in Action
Let's walk through a practical scenario using this outcome-focused approach. Suppose you need to comply with ISO 27001's risk management requirements. Following the operational model, you first identify what outcome the obligation actually demands: information security risks must be managed to levels acceptable to the organization and its stakeholders. This means risks are identified, assessed, treated, and monitored on an ongoing basis.
Now you identify what promises are needed to achieve this outcome. Your CISO might promise to maintain an accurate inventory of information assets and their associated risks, updating it quarterly and whenever significant changes occur. Your Information Security team might promise to implement and maintain controls that reduce identified high and medium risks below the organization's risk appetite threshold. Your IT operations team might promise to monitor security controls continuously and alert the security team when controls fail or degrade. Your business unit leaders might promise to accept documented residual risks for their areas of responsibility. Notice how these promises focus on achieving the state of managed risk, not just completing assessment documents.
Now you build your GSN argument with the top goal stating "Information security risks are maintained at acceptable levels." Your strategy is to demonstrate this through the operational model layers. This creates sub-goals: proving that your promises collectively cover all aspects of risk management (identification, assessment, treatment, monitoring), showing that your ISMS program effectively coordinates these risk management activities and ensures nothing falls through the cracks, demonstrating that your GRC system and security tools enable reliable execution of risk treatments, and finally evidencing that risk levels are actually being maintained within acceptable bounds over time.
For each of these sub-goals, you build claim trees. Consider the promise to implement controls to reduce risk. You create a claim tree that breaks this down: high-priority risks must be identified and prioritized, appropriate controls must be selected based on cost-benefit analysis, those controls must be implemented with sufficient coverage and strength, controls must be tested to verify they actually work, and the reduction in risk must be measurable. To prove this, you gather evidence: your risk register showing identified risks with severity ratings, treatment plans documenting which controls address which risks, implementation records showing when controls went live, penetration test results demonstrating control effectiveness, and trend data showing risk scores declining after controls were implemented.
The claim tree for monitoring is equally important. You need to prove that controls don't just exist but continue working over time. This requires evidence of continuous monitoring systems generating alerts, incident response logs showing how alerts are handled, metrics showing control uptime and effectiveness, and regular reviews that catch degradation before it matters.
The difference between this approach and a procedural approach is critical: procedural compliance might show you completed an assessment last year, but operational compliance shows you're actively managing risk right now, today, with evidence that the state of risk is known and capable of being controlled in the future.
Why This Approach Transforms Compliance
Using GSN and claim trees forces you to think systematically in ways that traditional compliance approaches don't. You can't hide gaps in your compliance approach when you have to draw out the complete argument from obligation to outcome. Every link in the chain must be justified, and every justification must point to evidence. This becomes especially powerful when you realize that most compliance failures don't happen because people are malicious or lazy; they happen because promises weren't clearly made, coordination broke down between teams, or systems simply couldn't deliver what was assumed.
The outcome focus also protects you from the trap of performative compliance. It's easy to produce a beautiful risk assessment document that satisfies an auditor but does nothing to actually reduce risk. When your GSN goal is "risks are managed" rather than "assessment is conducted," you're forced to prove actual risk reduction. Your evidence can't just be the assessment document—it needs to be declining incident rates, reduced exposure to critical threats, faster detection and response times, and stakeholder confidence that risks are under control. This is compliance that actually makes the organization safer, not just better documented.
The approach also makes compliance conversations dramatically more productive. Instead of debating whether you're "compliant" or arguing about interpretation, you can point to specific claims and evidence. When auditors ask if you're managing risk, you can walk them through your reasoning: here are the promises made, here's how programs coordinate them, here's how systems execute them, and here's the evidence that risk is actually being reduced. When executives want assurance, you can show them exactly where confidence comes from—not "we did an assessment" but "here's how we know our risks are under control." When something fails, you can trace back through the GSN to find exactly which promise broke, which program oversight was missing, or which system capability was insufficient.
Perhaps most importantly, this methodology creates real assurance that evolves with your organization. Traditional compliance creates static documentation that's outdated the moment it's finished. GSN and claim trees are designed to be continuously maintained. When obligations change, you update the top-level goal and trace down to see which promises need adjustment. When new threats emerge, you update your risk management promises and prove you can address them. When systems evolve, you update the system capability claims.
Your assurance case becomes an actual reflection of your compliance posture—and more importantly, your actual security posture—not a dusty binder on a shelf.
Getting Started
You don't need to boil the ocean to start using this approach. Pick one critical obligation your organization struggles to demonstrate compliance with. But here's the crucial step: reframe that obligation as an outcome, not an activity. Don't write "We conduct risk assessments." Write "Risks are managed to acceptable levels." Don't write "We provide training." Write "Staff make secure decisions in their daily work." This outcome framing immediately clarifies what really matters.
Then identify the key promises that need to exist for that outcome to be achieved. For each promise, ask yourself if you can actually prove it's deliverable and being kept. Build claim trees for the most critical or questionable promises, and honestly assess what evidence you have versus what you're assuming. You'll quickly discover where your real gaps are—and importantly, you'll discover whether you're just checking boxes or actually achieving the outcomes your obligations demand.
The goal isn't perfection from day one. The goal is building a structured, evidence-based approach to compliance that gives you genuine confidence and provides clear answers when stakeholders ask that uncomfortable question: "How do you know you're actually compliant?" With GSN and claim trees overlaid on the Lean Compliance operational model, focusing relentlessly on outcomes rather than activities, you'll finally have a good answer. More importantly, you'll know that your compliance efforts are actually making your organization better, not just better documented.
If you are interested in learning more about GSN you can download the GSN Community Standard Version 3:
For more information about the Lean Compliance Operational Model and related methodologies, visit our website here.
