Compliance Matrix

This document explains how PhronEdge maps governance enforcement to the regulations that matter for regulated enterprises. Every policy build produces cryptographic evidence you can hand to an auditor.

The full control library, enforcement point mapping, and per-industry framework resolution is available to registered customers and commercial deployments.

The resolution model

PhronEdge does not ship with a hard-coded list of frameworks. Applicable regulations are resolved per deployment from four inputs:

1.Your HQ jurisdiction (where your company is headquartered)
2.Your deployment jurisdictions (where agents serve users)
3.Your industry vertical (insurance, finance, healthcare, defense, telecommunications, manufacturing, retail, general)
4.The data classifications you process (PUB, INT, PII, PHI, SPC, FIN, CON, RST)

The Brain computes the full applicable regulation set on every policy build. A German insurer processing PII gets a different framework stack than a US healthcare provider processing PHI. This matches how regulators think. GDPR does not apply because you use a governance tool. It applies because you are processing personal data of EU residents.

What you get on every policy build

Every phronedge policy deploy or Policy Builder submission returns a compliance summary:

JSON

{
  "status": "compliant",
  "signed_artifact": {
    "frameworks": ["GDPR", "EU AI Act", "ISO 42001", "NAIC AI Bulletin", "..."],
    "controls_required": 30,
    "controls_met": 30,
    "policy_hash": "6b890f03..."
  }
}

30 controls are evaluated on every policy build. They span governance, identity, data handling, behavioral monitoring, audit logging, and incident response. The exact set required varies by jurisdiction and industry. Controls that fail are returned as a gap report with specific remediation guidance.

Enforcement categories

The 30 controls enforce across six categories. Each category is a specific technical mechanism in the gateway and Brain.

Category	What it does	Example control surface
Pre-execution Gate	Human approval, change review, DPIA	Tier 1 agents require human sign-off on every action
Allowlist	Tool registry, model pinning, credential rotation	Tools not in the signed policy are rejected
Config Enforcement	Data classification, residency, session limits	Credentials carry the signed config; gateway enforces
Real-time Scanning	PII detection, prompt injection, bias monitoring	Every request scanned at Checkpoint 2
Budget and Quota	Token budgets, rate limits	Exceeding budget blocks calls
Automated Monitoring	Audit logging, drift detection, alert SLAs	SHA-256 hash-chained events

The category structure lets your security team reason about the control surface at the right level of abstraction.

The 7 checkpoints and what they enforce

Every tool call passes through 7 checkpoints. Each one enforces multiple regulations simultaneously.

#	Checkpoint	Regulation families enforced
1	Credential Validator	Data integrity, AI Act cybersecurity requirements, audit readiness
2	PII Detector	Personal data protection, special category handling
3	Jurisdiction Router	Cross-border transfer rules, data localization
4	Behavioral Baseline	Operational resilience, anomaly detection
5	Judge	Access control, human oversight, tool governance
6	Data Classifier	Data minimization, purpose limitation
7	Output Constraint	Output governance, PII redaction

Specific regulation citations (e.g., "GDPR Art. 5(1)(f)") appear in the audit event regulation field when a checkpoint blocks a call. Your auditor sees the citation directly in the evidence trail.

Deny conditions

When a checkpoint blocks a call, the audit chain records a structured deny reason. PhronEdge recognizes a canonical set of deny conditions covering credential failures, permission failures, jurisdiction failures, classification failures, behavioral anomalies, and budget exhaustion.

Every TOOL_CALL_BLOCKED event records the specific deny condition, the checkpoint that fired, the regulation that triggered the block, and the policy hash under which the block occurred. This is the level of detail your regulator will ask for.

The full list of deny conditions with internal reason codes is available to registered customers.

Cross-border transfer resolution

Cross-border data transfers trigger additional enforcement. PhronEdge classifies every jurisdiction into one of six regulatory tiers and resolves transfer verdicts using a compatibility matrix.

Jurisdiction tiers

Tier	Label	Examples
E	EU/EEA Strict	Germany, France, Netherlands
A	EU Adequacy	UK, Japan, Switzerland
P	Permitted	United States, Canada, Australia
L	Localization required	China, Russia, Saudi Arabia
H	High Restriction	Export-controlled destinations
R	Enterprise Restricted	Sanctions regimes

Verdict vocabulary

When data moves from a source tier to a destination tier, the Brain resolves one of these verdicts:

FREE - No additional mechanism required
ADEQUATE - Adequacy decision covers the transfer
SCC or SCC + TIA - Standard Contractual Clauses (with Transfer Impact Assessment for special categories)
APPROVED - Requires written governance approval
IN-COUNTRY - Must remain within the jurisdiction
GOV. AUTH. - Requires government authorization
PROHIBITED - Transfer not permitted
BLOCKED - Sanctions regime, no transfer possible

Data classifications influence the verdict. Special categories, confidential data, and restricted data raise the bar or block transfers entirely.

The full transfer matrix and data class escalation rules are evaluated by the Brain on every policy build and cross-jurisdictional tool call. Audit events CROSS_BORDER_DETECTED, SCC_GENERATED, and TIA_GENERATED anchor the resolution.

The complete transfer matrix is available to registered customers.

Industry coverage

PhronEdge recognizes eight industry verticals. Each activates industry-specific framework overlays on top of the jurisdiction-resolved base.

Industry	Code
Insurance	IN
Financial Services	FS
Healthcare	HC
Defense	DF
Telecommunications	TC
Manufacturing	MF
Retail	RT
General	X

Industry overlays add sector-specific controls. Insurance activates NAIC and Solvency II. Financial Services activates DORA, PCI-DSS, SR 11-7, SOX, and GLBA. Healthcare activates HIPAA, HITECH, and FDA requirements. Defense activates ITAR, EAR, CMMC, and FedRAMP.

The complete industry-to-framework mapping is available to registered customers.

Framework coverage

PhronEdge evaluates policies against the major frameworks regulated enterprises need.

Always evaluated when applicable:

GDPR (EU) 2016/679
EU AI Act 2024
UK GDPR
Schrems II (C-311/18)
ePrivacy Directive
NIS2 Directive
ISO 42001 (AI Management System)
NIST AI Risk Management Framework
SOC 2 Type II
OWASP LLM Top 10
OWASP Agentic Security

By industry:

Financial: DORA, Basel III, MiFID II, PSD2, SR 11-7, GLBA, SOX, PCI-DSS v4.0
Healthcare: HIPAA, HITECH, FDA 21 CFR Part 11, MDR
Insurance: NAIC AI Model Bulletin, Solvency II, EIOPA Guidelines
Defense: ITAR, EAR, CMMC 2.0, FedRAMP High, DFARS
Other: CCPA/CPRA, FCC CPNI, Machinery Regulation 2023

The exact framework set for your deployment is computed by the Brain and returned in the signed policy artifact.

Worked example: Germany, Insurance

A German insurance company signs a policy with:

HQ jurisdiction: DE
Industry: IN
Data classifications: PII, FIN
Deployment jurisdictions: DE, AT, CH

The Brain resolves applicable frameworks:

From jurisdiction (tier E): GDPR, EU AI Act, ePrivacy Directive, Schrems II, NIS2, eIDAS 2.0

From industry (Insurance): NAIC AI Model Bulletin, Solvency II, EIOPA AI Guidelines

From data classifications (PII, FIN): GDPR Art. 4, 6, 9, 25, PCI-DSS v4.0, PSD2

Always evaluated: ISO 42001, NIST AI RMF, OWASP Agentic Security

Transfer verdicts for this deployment:

Source	Destination	Verdict
DE (E)	AT (E)	FREE
DE (E)	CH (A)	ADEQUATE
DE (E)	US (P)	SCC + TIA
DE (E)	CN (L)	PROHIBITED

If a policy attempts a transfer from DE to CN for PII data, the Brain refuses to sign. If a call at runtime crosses from DE to US, the gateway resolves SCC + TIA, logs CROSS_BORDER_DETECTED and SCC_GENERATED, and requires the appropriate mechanism.

Full worked examples for US/Healthcare, UK/Finance, and other deployment profiles are available to registered customers.

Evidence for an audit

Every enforcement action produces an audit event. Every audit event is ECDSA-signed and SHA-256 chained. The chain is independently verifiable with only the public key.

At the conceptual level, the evidence mapping works like this:

Regulation area	Evidence PhronEdge produces
Integrity of processing	ECDSA signature on every credential, verified at every call
Records of processing	Hash-chained audit log of every governance decision
Security of processing	Tamper-evident chain, vault integrity checks
Data minimization	`permitted_tools` allowlist in signed credential
Cross-border transfers	`CROSS_BORDER_DETECTED`, `SCC_GENERATED`, `TIA_GENERATED` events
Risk management	Risk tier assignments, `AGENT_QUARANTINED` events
Human oversight	Tier 1 agents, `human_approval_required` blocks
Record-keeping	Complete chain exportable via CLI or Console
Accuracy and robustness	Credential validation on every call, `CREDENTIAL_REJECTED` events
Audit controls	PII Detector events, output constraint events
System monitoring	Observer dashboard, alert events
Tamper evidence	Chain break detection, `VAULT_INTEGRITY_BROKEN` events

Specific regulation-to-event-type citations appear in the Console and in the audit export. The full mapping is available to registered customers.

Producing evidence for an audit

Two ways to produce audit evidence.

CLI export

Shell

phronedge chain events --agent claims-investigator --limit 10000 > audit.json
phronedge chain verify > chain-integrity.txt
phronedge export rego --agent claims-investigator -o policy.rego
phronedge policy status > policy-status.txt

Four files. The signed policy. Executable OPA rules. Every governance decision for the agent. Cryptographic proof that nothing was modified.

Console export

From the Observer, open any agent and use the audit export feature. The Console produces the same four artifacts, packaged, timestamped, and signed.

The audit pack is itself a signed artifact. A regulator can verify its authenticity before examining the contents.

Independent verification

Every exported artifact includes a phronedge_signature. An auditor with only the public key (fetched from /.well-known/phronedge/{tenant}/keys.json) can verify any of them without contacting PhronEdge.

See Signing and Verification for the complete independent verification example.

What this means for the CISO

A signed policy is your governance deliverable. For every control your regulator asks about:

1.PhronEdge enforces at a specific checkpoint in a documented pipeline
2.The enforcement produces a specific, regulation-cited audit event
3.The event is cryptographically signed and chain-linked
4.Your auditor can independently verify the signature and the chain

Nothing is claimed. Everything is produced. That is the distinction that wins a regulated enterprise review.

Getting the full detail

The full control library (30 controls with article-level citations), the complete transfer matrix (every source-destination verdict with escalation rules), the full industry framework mapping, and detailed regulation-to-event evidence tables are available to registered customers. Contact sales for commercial access.

Next steps

Threat model. What PhronEdge protects against and what it does not
Signing and verification. ECDSA proofs for every artifact
Console guide. Running a policy review and exporting audit packs
CLI reference. The four commands that produce audit evidence
Deployment runbook. Compliance verification cadence

Previous

Deployment Runbook

Next

Signing & Verification