# Compliance As A Living Graph: Mapping Standards To What SG/Sentinel Actually Deploys

**version** v0.27.58
**date** 18 May 2026
**from** Human (project lead)
**to** Architect, Strategy, Security, Compliance, @Dev
**type** Arch / strategy brief

---

## What This Is

The eleventh brief in the SG/Sentinel series, and one the voice memo described as something it has been trying to do for a long time: **mapping compliance standards to what the platform actually deploys, as a living graph, where compliance posture is dynamically enabled or disabled by the specific rules in effect.**

The core idea: take the major compliance and security standards (GDPR, ISO 27001, OWASP Top 10, OWASP AI, and others), build graph-based versions of them, and map them against what SG/Sentinel and the platform actually do. The result is a dynamic, deployment-specific answer to the question: **in this particular setup, with these particular rules enabled, what is my compliance posture, what attack trees am I blocking, what does my threat model look like?**

This is a departure from the checkbox model of compliance. The voice memo was emphatic: **this is not the typical checkbox exercise.** Compliance here is tied to what is actually deployed and how it is configured, not to a list of claims. If there is no WAF in front of the product, certain compliance properties are genuinely not met; because the data is encrypted, certain properties are met for free. The compliance posture is a real, computed function of the actual deployment.

This brief covers the living-compliance-graph concept, the dynamic posture model, the platform-inherent versus Sentinel-added properties, the per-deployment view, the business-value proposition, and the build approach (LLM-generated graphs, multi-party checking, community verification).

## The Core Idea: Compliance Mapped To Reality

The voice memo's central insight: **the graph of compliance should be mapped to what is actually deployed.** Compliance is not a document that claims conformance; it is a computed property of the running system.

The voice memo gave concrete examples:

- **No WAF in front of the product means breaking certain compliance requirements.** Several standards require traffic filtering, logging, and protection that a WAF provides. Without it, those requirements are genuinely unmet.
- **Encrypted data means certain compliance properties for free.** Because the platform encrypts everything (zero-knowledge), data-protection requirements that other systems struggle with are met by construction.

So the compliance posture is real: it reflects what the system actually does. Add a WAF (SG/Sentinel), and the compliance posture improves in specific, mappable ways. Change a rule, and the posture changes. **Compliance becomes a live readout of the deployment, not a periodic audit claim.**

The voice memo named the question precisely: **"when you look at GDPR, ISO 27001, and other security practices, the interesting question is what settings do I have where suddenly I am more or less compliant?"** The answer is computed from the actual configuration, not asserted.

## Graph-Based Versions Of The Standards

The mechanism: **build graph-based versions of the major standards**, so each standard's requirements become nodes in a graph that can be mapped to platform capabilities and rules.

The voice memo named the candidate standards: **GDPR, ISO 27001, OWASP Top 10, OWASP AI, and a handful of others (five, six, or seven standards that exist right now).**

For each standard, the graph-based version represents:

- The requirements as nodes
- The relationships between requirements
- The mapping from each requirement to the platform capabilities or rules that satisfy it
- The current status of each requirement (met, partially met, unmet) for a given deployment

This connects directly to the evidence-graph and semantic-graph work from the developer-friendliness brief and the MyFeeds evidence-pack direction. **The compliance graph is another semantic knowledge graph, this one representing standards and their satisfaction status.** The same graph infrastructure that holds the evidence graph can hold the compliance graph.

The voice memo: **"if we create a graph version of GDPR, ISO 27001, OWASP Top 10, OWASP AI, whatever, five or six or seven standards, the interesting question is what is the status of those standards that the platform currently supports, and that gets enabled or disabled depending on specific rules."**

## Dynamic Compliance Posture

The most powerful aspect: **compliance posture is dynamic, changing as rules are enabled or disabled.**

Because SG/Sentinel's behaviour is entirely defined by its rules (the rules-are-everything principle from the rules-engine brief), and because compliance is mapped to what the rules do, **enabling or disabling a rule changes the compliance posture in a computable, visible way.**

| Action | Compliance Effect |
|--------|-------------------|
| Enable a logging rule | Satisfies logging/audit requirements in several standards |
| Enable a rate-limiting rule | Satisfies availability/DoS-protection requirements |
| Enable a request-validation rule | Satisfies input-validation requirements |
| Disable a rule | Removes the compliance properties it provided |
| Add an encryption-enforcement rule | Strengthens data-protection posture |

This makes compliance a live dial. You can see, for a given deployment, exactly which rules contribute to which compliance requirements, and you can see what would happen to your posture if you changed them. **Compliance becomes something you can reason about and adjust, not just attest to once a year.**

This connects to the rules engine's per-rule version control and the deployment-phase model. A production bundle of rules has a specific, computable compliance posture. Promoting rules through dev/main/prod changes the posture in tracked ways. **The compliance posture is a property of the rule-set, computed from the rules in effect.**

## Platform-Inherent Versus Sentinel-Added Properties

The voice memo drew a useful distinction: **the platform itself already provides some compliance properties; SG/Sentinel adds more, dynamically.**

| Source | Compliance Properties |
|--------|----------------------|
| **Platform-inherent** | Encryption at rest and in transit (zero-knowledge); data-protection by construction; access control via Simple Tokens; audit trails via vault commits |
| **Sentinel-added** | Traffic filtering; WAF protection; logging and monitoring; rate limiting; bot protection; the dynamic rule-based properties |

The platform-inherent properties come for free from the architecture: because everything is encrypted and zero-knowledge, a whole class of data-protection requirements is satisfied by construction. The Sentinel-added properties are dynamic: they depend on which rules are deployed.

The voice memo: **"you have the platform in itself that should have some of these analysis, but more importantly, you have the dynamic part."** Both contribute to the compliance graph; the platform properties are stable, the Sentinel properties are dynamic.

This is a strong combined story: **the platform gives you data-protection compliance for free (encryption, zero-knowledge), and Sentinel gives you traffic-protection compliance dynamically (the rules). Together they cover a large fraction of what the major standards require.**

## The Per-Deployment View

A crucial nuance the voice memo named: **the compliance view is per-deployment, and may be configurable per setup or per user.**

Different deployments have different rules, different configurations, and therefore different compliance postures. The compliance graph answers, for a specific deployment: **in this particular setup, with these particular rules, what is my compliance status?**

The voice memo: **"in this particular deployment, in this particular setup that I have, what are the rules that are being impacted by these standards, and what are the attack trees that we're blocking, what is the threat model, what is the compliance stuff that we are doing?"**

This per-deployment view ties together several threads from the series:

- **The rules in effect** (from the rules engine)
- **The attack trees being blocked** (mapped to MITRE ATT&CK, from the research brief)
- **The threat model** (the AppSec analysis)
- **The compliance posture** (this brief)

All of these are computed for the specific deployment. The voice memo's framing connects directly to the research brief: the ATT&CK techniques Sentinel blocks, the threat model it implements, and the compliance requirements it satisfies are all views of the same underlying reality: what the deployed rules actually do.

The configurability matters: this view might not be available to all users, or might be available to all, but should at least be available in some setups. It is a powerful capability that some deployments (regulated industries, enterprise customers) will value highly.

## The Business Value Proposition

The voice memo was explicit that this goes straight to business value: **it shows the business benefit of putting this technology in front, in a way the checkbox model never can.**

The conventional security-tool sale is a checkbox: "do you have a WAF? yes/no." The compliance-graph model is richer: **"here is exactly which compliance requirements this deployment satisfies, which attack trees it blocks, and how that maps to GDPR, ISO 27001, and the OWASP standards, computed from what is actually running."**

The voice memo: **"this goes straight to the business benefit. What is the business benefit of putting this technology in front, and more importantly, the way it is configured? This is not just about the product as a checkbox; it is to do with the way it is deployed."**

The differentiators:

| Checkbox Compliance | Living-Graph Compliance |
|---------------------|-------------------------|
| "We have a WAF" | "Here are the 47 specific requirements our deployment satisfies" |
| Claimed, attested | Computed from actual configuration |
| Static, annual | Dynamic, live |
| Generic | Per-deployment specific |
| Trust us | Validate it; get third-party confirmation |

This is a genuinely differentiated value proposition. It is also honest: it shows what is and is not satisfied, which builds trust precisely because it is not a blanket claim. **The compliance graph turns security from a cost (the checkbox you pay for) into a demonstrable, validatable business asset.**

This connects to the de-commoditising and business-value threads from the week: the compliance graph is part of the shield's value. It is not just that Sentinel protects you; it is that Sentinel can show you, precisely and dynamically, how it protects you in the terms the standards use.

## Third-Party Validation

The voice memo named an important credibility mechanism: **get third-party validation that they confirm and agree with the compliance mapping.**

Because the compliance posture is computed and specific (not a vague claim), it can be validated. A third party (an auditor, a security firm, the community) can check: does this deployment actually satisfy these requirements? does the mapping hold? **The specificity that makes the compliance graph useful also makes it validatable.**

The voice memo: **"you can start to validate this, you can start to get third-party validations on, do they confirm, do they agree with this?"**

This is the opposite of checkbox compliance, which is hard to validate because it is vague. A precise, computed, per-deployment compliance graph invites validation, and validation builds trust. The community-verification angle (below) is part of this.

## The Build Approach: LLM-Generated, Multi-Party-Checked, Community-Verified

The voice memo described how to build the graph-based standards: **use an LLM to generate the graph-based versions, have a couple of others check them, and get the community to verify.**

The build pipeline:

1. **LLM generates the graph-based version** of each standard (GDPR, ISO 27001, OWASP Top 10, OWASP AI, etc.), turning the standard's text into a structured graph of requirements.
2. **Multiple parties check** the generated graph (other LLMs, human reviewers) for accuracy.
3. **The community verifies** the graph-based standards, building trust and correctness through open review.

This is the LLM-heavy-at-development-time pattern from the rules-engine brief, applied to compliance standards. The LLM does the heavy lifting of turning dense standards documents into structured graphs; humans and the community verify.

The voice memo suggested this might live in a separate repo: **a graph-based version of the standards and their guidance, possibly its own repository.** This makes sense: the graph-based standards are reusable infrastructure, valuable independently of any one deployment, and a natural candidate for open-source release and community maintenance (like the OWASP standards themselves).

This connects to the vault model: **the graph-based standards could be a vault (or a set of vaults), version-controlled, community-verifiable, composable.** A standard-as-a-vault fits the platform's patterns perfectly, and it connects to the articles-as-vaults and evidence-packs-as-vaults directions from earlier in the week.

## The Compliance-To-Standards Mapping Opportunity

The voice memo opened with an idea worth capturing separately: **can we map compliance to specific standards just by adding the WAF on top?** Several standards (it mentioned PCI-DSS-style requirements and others) require specific activities that a WAF provides. So adding SG/Sentinel could directly satisfy specific named requirements in specific standards.

This is a concrete, sellable proposition: **"adding SG/Sentinel satisfies requirements X, Y, Z of standard S."** For standards that explicitly require WAF-like protection (PCI-DSS requirement 6.4.2, for instance, requires a WAF or equivalent), Sentinel directly ticks named boxes, and the compliance graph shows exactly which ones.

The voice memo noted this is probably a topic in itself, and it is: the detailed mapping of which standard requirements each capability satisfies is substantial work. But it is high-value work, because it turns Sentinel from "a security tool" into "the thing that satisfies these specific named requirements in these specific standards."

## How This Composes With The Series

| Brief | Relationship |
|-------|--------------|
| Research brief | The ATT&CK mapping and standards compatibility this builds on |
| Developer-friendliness brief | The semantic-graph infrastructure the compliance graph uses |
| Rules-engine brief | The rules whose presence/absence determines compliance posture |
| Interactivity brief | The deployment phases that change the posture in tracked ways |
| Time brief | The detection capabilities that satisfy monitoring requirements |
| Principles brief | The "make the site hostile" protections that satisfy security requirements |
| **This compliance brief** | **The mapping of all of it to the standards, as a living graph** |

The compliance graph is, in a sense, the business-facing view of the whole series. Everything Sentinel does (block attacks, log traffic, validate requests, protect data) maps to compliance requirements. The compliance graph makes that mapping explicit, dynamic, and validatable. **It is how the technical work becomes a business proposition.**

## What This Asks For

Concrete next steps:

1. **Build graph-based versions of the priority standards** (GDPR, ISO 27001, OWASP Top 10, OWASP AI) using LLM generation.
2. **Establish the multi-party checking and community-verification process** for the graphs.
3. **Map platform-inherent properties** to the standards (encryption, zero-knowledge, access control, audit).
4. **Map Sentinel rules to compliance requirements** (which rule satisfies which requirement).
5. **Build the dynamic posture computation** (given a rule-set, compute the compliance posture).
6. **Build the per-deployment compliance view** (this setup, these rules, this posture).
7. **Connect to the ATT&CK and threat-model views** (the unified per-deployment picture).
8. **Map specific WAF-requiring standard requirements** to Sentinel (the tick-the-named-box opportunity).
9. **Enable third-party validation** of the computed posture.
10. **Consider the standards-as-vaults** approach (version-controlled, community-verifiable, possibly a separate repo).

Estimated effort: building the graph-based standards is a focused LLM-assisted project (weeks); the mapping and dynamic-posture computation build on the rules engine and evidence graph; the per-deployment view is a TUI/reporting layer on top.

## What This Does Not Try To Be

Deliberate scope limits:

- **Not a checkbox-compliance product.** The whole point is that it is computed from reality, not attested.
- **Not a legal compliance guarantee.** It maps capabilities to requirements; legal compliance involves more than technical controls.
- **Not a replacement for auditors.** It supports and is validated by third parties; it does not replace them.
- **Not all standards at once.** Start with the priority five to seven; expand over time.
- **Not automatic certification.** It shows posture; certification is a separate process the posture supports.

## Honest Risks

Three risks:

**Risk 1: The compliance mapping could be wrong or overclaim.** An incorrect mapping (claiming a requirement is satisfied when it is not) is worse than no mapping. Mitigation: multi-party checking; community verification; third-party validation; conservative claims; show partial and unmet, not just met.

**Risk 2: Graph-based standards generated by LLM could contain errors.** LLMs can misread dense standards. Mitigation: human review; community verification; treat the LLM output as a draft to be checked, not authoritative; version the graphs so corrections are tracked.

**Risk 3: Compliance is legally sensitive; overclaiming has consequences.** Telling a customer they are GDPR-compliant when they are not is a serious problem. Mitigation: frame as "these technical controls map to these requirements," not "you are compliant"; legal review of the claims; clear scoping of what the mapping does and does not assert.

## Open Questions

| Question | Notes |
|----------|-------|
| Which standards first? | GDPR, ISO 27001, OWASP Top 10, OWASP AI; expand later |
| Standards-as-vaults in a separate repo? | Probably; reusable, community-verifiable infrastructure |
| How is the dynamic posture computed? | From the rule-set manifest mapped to requirement nodes |
| Per-deployment view available to all users or some? | Configurable; valuable for regulated/enterprise deployments |
| How conservative should the claims be? | Very; show partial and unmet; never overclaim |
| How is third-party validation structured? | Auditors and community check the computed posture |
| Legal review of the compliance claims? | Required before any customer-facing compliance assertion |
| Connection to PCI-DSS-style explicit WAF requirements? | High-value; map specific named requirements to Sentinel |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 18 May | `v0.27.58__research-brief__sentinel-learning-from-standards-and-services.md` | The ATT&CK mapping and standards compatibility this extends to compliance |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-developer-friendliness-and-evidence-graph.md` | The semantic-graph infrastructure the compliance graph uses |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-rules-engine.md` | The rules whose presence determines compliance posture |
| 18 May | `v0.27.58__arch-brief__sg-sentinel-interactivity-and-deployment-phases.md` | The phases that change posture in tracked ways |
| 18 May | `v0.27.58__arch-brief__edge-security-and-logging-layer-principles.md` | The protections that satisfy security requirements |
| 17 May | `v0.27.55__strategy-brief__myfeeds-b2b-research-briefings-as-evidence-packs.md` | The semantic-graph and standards-as-vaults patterns |
| 17 May | `v0.27.55__article__de-commoditising-the-commodity.md` | Compliance graph as part of the shield's demonstrable value |
| 16 May | `v0.27.45__strategy-brief__appsec-mini-tools-on-top-of-vaults.md` | The threat-model view that joins the compliance view |
| 16 May | `v0.27.45__dev-brief__nova-and-agentcore-poc-fastapi.md` | LLM generation of the graph-based standards |

---

## Acceptance Criteria

| # | Criterion | Verification |
|---|-----------|-------------|
| 1 | Graph-based versions of the priority standards exist | GDPR, ISO 27001, OWASP Top 10, OWASP AI as graphs |
| 2 | Multi-party checking and community verification process is established | Graphs are verified, not just generated |
| 3 | Platform-inherent properties are mapped to requirements | Encryption, zero-knowledge, etc. mapped |
| 4 | Sentinel rules are mapped to compliance requirements | Each rule's compliance contribution known |
| 5 | Dynamic posture computation works | Given a rule-set, the posture is computed |
| 6 | The per-deployment compliance view works | This setup, these rules, this posture |
| 7 | The view joins ATT&CK, threat-model, and compliance | Unified per-deployment picture |
| 8 | Specific WAF-requiring standard requirements are mapped | Named requirements ticked |
| 9 | Third-party validation is possible | The posture is validatable |
| 10 | Claims are conservative (partial and unmet shown, not just met) | No overclaiming |
| 11 | Standards-as-vaults approach is evaluated | Version-controlled, community-verifiable |

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).