Not firewalls. People holding permissions they should never have had — a contractor who kept access, a role with the keys to everything, a login nobody remembers. Enforcer reads who can do what across your AWS and Kubernetes every day, flags what is out of line, and writes it down. Read-only. Nothing changes without a person’s yes.
A bank customer’s vendor-risk team wants to know how you control access. Today, answering that takes two engineers a week: screenshots of permission screens, an access spreadsheet assembled by hand, a point-in-time picture that proves nothing about the eleven months in between.
And the picture is usually already out of date. Someone opened up a role during an incident and forgot to close it. A contractor rolled off and kept their keys. A quick “temporary” grant became permanent. These are the changes that pass an annual review and burn you in a real one.
Enforcer closes that gap. It checks the real access settings — for each individual user, role, and access rule — against the ISO 27001 requirements every day, and every result becomes a dated, hash-verified record you can hand over instead of assemble.
Every IAM user, role, and permission — read directly from the account. Enforcer flags full-admin access, permissions attached to people instead of groups, and keys that were issued and never used.
The same question, one layer down: the access rules and bindings inside your clusters. Enforcer flags anything that hands out cluster-admin or grants everything with a wildcard.
Cloud and cluster findings roll up together. Each one names the exact user or role, the requirement it failed, and the day it was seen — plain rules, the same answer every time, no AI in the record.
Each of these is one automated check. When it fails, the record names the resource, the ISO requirement, and the date — reproducible, and traceable back to the exact setting.
POL-IAM-NO-ADMIN-001POL-IAM-NO-DIRECT-ATTACH-001POL-K8S-CRB-NO-CLUSTER-ADMIN-001POL-K8S-ROLE-NO-WILDCARD-001POL-IAM-NO-STALE-KEYS-001POL-IAM-PWD-INACTIVE-001These are a handful of the 133 checks Enforcer runs. See a full control matrix.
Every access check maps to a specific ISO 27001:2022 control, so the evidence lines up with the question your auditor is actually asking.
Finding an over-broad role is only useful if it gets fixed. Enforcer can propose and apply the fix — but only behind two separate doors. First, that specific check has to be switched out of watch-only mode. Then a person has to approve that exact change.
The problem, the approval, and the fix are stored as one linked record. A machine handles the busywork. A person keeps the judgment. Nothing touches production unsupervised.
Enforcer reads access settings. It sees that a role has too much power; it does not know why the person was hired or whether their manager signed off. The joiner-mover-leaver process, the access reviews, the approvals — those live in the compliance tool you already have, and they should stay there.
It also does not decide, on its own, whether your team is properly separated. Whether one person can approve their own work is a question about how you organize people, not about a cloud setting. Enforcer gives you the raw material that question depends on — who really holds what — not a verdict on the organizational control itself.
We would rather tell you where the edge is than pretend there isn’t one.
No. Tools like Vanta and Drata answer the access question with a questionnaire and a poll of connected integrations — a summary of what someone said, or what the last poll saw. Enforcer reads the actual permission settings on every AWS user and role and every Kubernetes access rule, and keeps that reading. Keep the tool you have; this is the half it cannot see.
It proves the access-rights controls that separation of duties depends on — that no one holds full administrator power, that permissions are not over-broad, that stale access has been cleaned up. It does not evaluate the organizational control itself (ISO 27001 A.5.3), because whether one person can approve their own work is a process question, not something a cloud setting can answer. We are precise about that line rather than papering over it.
No — not unless you deliberately turn it on. Every check ships in watch-only mode. A fix runs only after you switch that specific check into fix mode and a person approves that exact change. Out of the box, Enforcer cannot change anything in your account.
A read-only role. It reads configuration only — it cannot read the data inside your systems, and the permission list is generated from the exact calls the software makes, so it cannot quietly grow. The full policy is published on our security page.
We don’t know yet, and we won’t claim otherwise. As of today no auditor has reviewed our evidence format. Getting that verdict — in writing — is the thing we are working on now, and we will publish it either way. In the meantime you can download a sample record and check it yourself.
Twenty minutes with the founder, or download a sample record and check the hashes yourself. No sales funnel, no demo that doesn’t exist yet.
Catch unsafe AWS changes the day they happen — every change becomes a dated record, and nothing gets fixed until you approve it.
The same access question one layer down — RBAC, network policy, and namespace isolation, evidenced beside your AWS findings.