Compliance, baked into every policy push.
25 frameworks. 210 firewall-applicable controls. Advise or enforce on every policy push — so a rule that would break a control is caught before it ever reaches a firewall.
25 framework packs. 210 firewall-applicable controls.
Hand-authored against Enforza's native policy model and cross-validated against the source regulations and the recognised control catalogues — not a generic checklist bolted on the side.
- 25 framework packs
- 210 firewall-applicable controls
- 2 modes — advise or enforce
Cross-platform standards
The frameworks most teams are measured against.
- CIS Controls v8
- PCI DSS v4
- ISO/IEC 27001:2022
- NIST SP 800-53 r5
- NIST CSF 2.0
CIS Cloud Foundations
Per-provider cloud benchmarks.
- CIS AWS Foundations
- CIS Azure Foundations
- CIS GCP Foundations
- CIS Oracle Cloud Foundations
Healthcare & SaaS
US healthcare and service-organisation reporting.
- HIPAA Security Rule
- SOC 2 (Type II)
US Government & Defense
Federal authorisation and the defence supply chain.
- FedRAMP Moderate
- NIST SP 800-171 r3
- CMMC Level 2
European Union
EU operational-resilience and network-security law.
- DORA
- NIS2 Directive
United Kingdom
The NCSC baseline.
- UK Cyber Essentials v3.1
APAC financial regulators
Regional banking and financial-services mandates.
- MAS TRM (Singapore)
- APRA CPS 234 (Australia)
- HKMA TM-G-1 (Hong Kong)
- RBI Cyber Security Framework (India)
Cloud & container
Shared-responsibility and Kubernetes coverage.
- CSA Cloud Controls Matrix v4
- CIS Kubernetes Benchmark v1.10
Adversary-driven & opinionated
Threat-mapped mitigations and Enforza's own hygiene baseline.
- MITRE ATT&CK Mitigations
- Enforza Best Practices (33 checks)
Coverage includes a 33-check Enforza Best Practices hygiene pack, default-on for new tenants.
Compose, attach, and check on every push.
Compliance is part of the publish flow, not a separate audit step. Build a guardrail set once, attach it to a policy, and every push is checked against it.
-
Compose a guardrail set
Pick whole framework packs, cherry-pick individual controls, or both. Build the set that matches what your auditors actually ask for — reuse it across every policy.
-
Attach it: advise or enforce
Attach the set to a policy in advise mode (warn and surface violations) or enforce mode (block the publish). The same guardrails apply whether you run GitOps or the console.
-
Checked on every push
Every policy push is checked against the attached set. An enforce violation is blocked before any firewall sees the rule — and the rejection lands as an audit event automatically.
What a check looks like on push.
Here are five controls from the curated Enforza Best Practices pack, evaluated against a policy at publish time. Most pass; one is advised; one is blocked in enforce mode — rejected before any firewall sees the rule.
prod-egress-v14 · Enforza Best Practices ·
enforce - EBP-002 Every section defaults to drop Inbound, through and outbound all default-deny with explicit allows. Pass · control satisfied
- EBP-007 No insecure legacy protocols No allow rule names telnet, FTP, TFTP or other cleartext services. Pass · control satisfied
- EBP-006 Broad egress must carry an L7 matcher Outbound allow to 0.0.0.0/0 is scoped by hostname / FQDN — no bare-port passthrough. Pass · control satisfied
- EBP-003 No public inbound without an L7 matcher Inbound allow from 0.0.0.0/0 has no hostname rule — scope it to a bastion range or attach a hostname matcher. Advise · caught · warned
- EBP-008 Management & database ports must restrict source A database port is accepted from 0.0.0.0/0 — restrict the source to a bastion or VPN range. Block · publish rejected
- Pass
- Advise
- Block
Every policy push is checked against the attached set — an enforce violation is blocked before any firewall sees the rule.
Illustrative example. The Enforza Best Practices pack ships 33 such hygiene checks; the controls shown carry the real control IDs.
Caught before it ships. Auditable after.
The point of advise-or-enforce is to move compliance left — out of the post-incident audit and into the moment a rule is written.
-
Caught before it ships
A rule that would break a control is flagged or blocked at publish time — not discovered in an audit months later, or after it has already loosened a firewall.
-
Auditable by default
Every check, every advise warning and every enforce block is recorded. You can show an auditor what was evaluated, what failed, and that the failing change never reached production.
-
Honest coverage signal
Each control carries a confidence rating. Controls genuinely outside a firewall's scope — endpoint posture, identity, application-layer auth — are marked low confidence with the reason why, so you see honest coverage, not inflated green ticks.
-
Same guardrails, either workflow
Compliance is not a console-only feature. GitOps and the Cloud Controller console run the same advise-or-enforce checks against the same packs — your choice of workflow never changes what gets enforced.
Common questions
Which compliance frameworks does Enforza cover?
Enforza ships 25 framework packs covering 210 firewall-applicable controls. They include cross-platform standards (CIS Controls v8, PCI DSS v4, ISO/IEC 27001:2022, NIST SP 800-53 r5, NIST CSF 2.0), CIS Cloud Foundations for AWS, Azure, GCP and Oracle, healthcare and SaaS (HIPAA Security Rule, SOC 2 Type II), US Government and Defense (FedRAMP Moderate, NIST SP 800-171 r3, CMMC Level 2), EU law (DORA, NIS2), UK Cyber Essentials v3.1, APAC financial regulators (MAS TRM, APRA CPS 234, HKMA TM-G-1, RBI), CSA Cloud Controls Matrix v4, CIS Kubernetes Benchmark, MITRE ATT&CK mitigations and the Enforza Best Practices pack.
What is the difference between advise and enforce mode?
Advise mode warns: violations are surfaced on the policy so your team can see and act on them, but the publish still goes through. Enforce mode blocks: a violation stops the publish, and the rule never reaches a firewall. You choose the mode per attached guardrail set, so you can run new packs in advise while you bring policies into line, then switch to enforce.
Does an enforce violation actually block a deploy?
Yes. In enforce mode, a violation is caught at publish time and the publish is rejected before any firewall receives the policy — the failing rule is never applied. The rejection is recorded as an audit event automatically. This works whether the policy comes from a GitHub pipeline or the console.
Can I pick individual controls or build custom guardrail sets?
Yes. You compose guardrail sets from whole framework packs, cherry-picked individual controls, or a mix of both, and attach the set to a policy. You build the set that matches your obligations and reuse it across policies, rather than being forced to take an entire framework all-or-nothing.
How do you handle controls a firewall cannot fully enforce?
Each catalogued control carries a confidence rating. Controls that genuinely sit outside a firewall's scope — endpoint posture, identity and access, application-layer authentication — are marked low confidence with a stated reason. You see an honest coverage signal in the picker instead of green ticks that overclaim what a network firewall can prove.
Where do the compliance checks run?
Checks run as part of the policy publish flow, before the policy is handed to any firewall — no traffic and no inspection happens on the firewall host for compliance. The same advise-or-enforce checks apply across both ways of running Enforza: policy-as-code through a GitHub pipeline, or the Cloud Controller console.
Stop non-compliant rules before they ship.
25 frameworks, 210 firewall-applicable controls, advise or enforce on every policy push — the same guardrails whether you run GitOps or the console. Start free, no card.