When an iso 27001 audit asks for evidence, you hand over a tidy collection of immutable session logs, approval trails, and masked data extracts that prove every access was authorized and recorded. The auditor can see, in a single view, who did what, when, and that sensitive fields were protected, satisfying the standard’s requirements for access control, auditability, and data confidentiality.
In practice most teams build this picture from ad‑hoc shell histories, manually copied screenshots, and occasional log exports. Those artifacts often miss timestamps or cannot be tied back to a verified identity. The result is a fragile audit packet that forces auditors to chase missing pieces, and it leaves the organization exposed to questions about the integrity of the evidence.
Why traditional evidence collection falls short for iso 27001
ISO 27001 expects a systematic, repeatable process for proving that only authorized subjects can reach critical resources, that every action is recorded, and that sensitive data is protected at rest and in motion. When teams rely on disparate logs, they typically miss three fundamentals:
- Centralization: Teams store logs in different silos, database audit tables, SSH syslog, Kubernetes audit events, making correlation painful.
- Integrity: Without a trusted boundary, a compromised host can tamper with its own logs before they are shipped.
- Visibility of controls: Teams rarely capture approvals, masking rules, and just‑in‑time grants alongside the raw traffic, so auditors cannot verify that guardrails were actually enforced.
These gaps mean the organization can answer “who accessed what” but cannot prove that the answer was generated by an immutable, policy‑driven system.
The missing piece: a unified, enforceable data path
The standard’s control set is clear: identity must be verified, the request must travel through a point where policy can be applied, and the outcome must be recorded. The missing piece for many environments is a single gateway that sits between the identity provider and the target infrastructure. The gateway is the only place where you can reliably enforce masking, command blocking, and approval workflows, and also capture an audit‑ready record of every byte that passes through.
Even when you have strong identity (OIDC, SAML, service‑account tokens), that setup alone does not guarantee that the request will be examined or that the evidence will be immutable. The data path must be the enforcement boundary; otherwise the controls remain “soft” and auditors will flag them.
hoop.dev as the identity‑aware gateway for iso 27001 evidence
hoop.dev implements exactly the data‑path requirement described above. First, it relies on an external identity provider (OIDC or SAML) to decide who the request is, this is the setup layer that authenticates the user or automated agent. Second, hoop.dev runs a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH hosts, and HTTP services. Because every packet flows through this gateway, hoop.dev becomes the only place where enforcement can happen.
From that position hoop.dev provides the enforcement outcomes that ISO 27001 auditors need:
- Session recording: hoop.dev records each session in a centrally managed store, so auditors can replay the exact commands and responses.
- Inline masking: hoop.dev redacts sensitive fields (credit‑card numbers, personal identifiers) in real time, and the gateway logs the masking policy that was applied.
- Just‑in‑time approval: When a risky command is detected, hoop.dev routes it to a designated approver; the approval decision and timestamps become part of the audit trail.
- Command blocking: hoop.dev rejects dangerous statements before they reach the target, and the block event joins the audit log.
- Policy provenance: The system defines all guardrails in a central configuration that the gateway reads on each connection, ensuring consistent enforcement.
Because the gateway holds the credentials for the target resources, the user never sees them, satisfying the principle of least privilege while still enabling full auditability.
What artifacts hoop.dev generates for auditors
When you hand over the evidence package, hoop.dev supplies a ready‑made collection that maps directly to ISO 27001 Annex A controls:
- Immutable session logs: Timestamped, identity‑tagged recordings of every interaction; hoop.dev stores them in a location that is append‑only and not directly writable by other processes.
- Approval workflow records: hoop.dev records who approved, what operation was approved, and when, and it links these records to the corresponding session.
- Masking rule logs: hoop.dev logs the definition of each masked field, the rule version, and the redaction event for every response.
- Access policy snapshots: hoop.dev captures the exact configuration that governed the connection at the time of the session.
- Connection metadata: hoop.dev records source IP, target host, protocol, and the OIDC token claims that identify the requester.
hoop.dev exports all of these artifacts in standard formats (JSON, CSV) that you can import into audit management tools, making the hand‑off to the audit team frictionless.
Getting started with hoop.dev
To build the required data path, start with the quick‑start deployment that runs the gateway and an agent in Docker Compose. The setup authenticates users via OIDC, registers a PostgreSQL connection (or any supported target), and enables masking and approval out of the box. You can find detailed steps in the getting‑started guide, and the learn section describes the broader feature set. Because hoop.dev is open source, you can self‑host the gateway behind your own network perimeter and retain full control over the audit data.
Frequently asked questions
Does hoop.dev replace existing logging solutions?
No. hoop.dev complements them by providing a single, policy‑driven source of truth for access‑related events. You can still forward the logs to a SIEM for long‑term retention.
Can I use hoop.dev with existing identity providers?
Yes. hoop.dev acts as a relying party for any OIDC or SAML provider, so you keep your current IdP and simply configure the gateway to trust its tokens.
How does hoop.dev ensure the audit data cannot be altered?
hoop.dev writes each session and policy change to an append‑only store that only the gateway process can write. Because the gateway is the sole writer, tampering would require compromising the gateway itself, which is a much tighter security boundary than scattered host‑level logs.
By placing enforcement and evidence generation in a single, identity‑aware data path, hoop.dev gives you the concrete artifacts auditors demand for iso 27001 compliance.
Explore the open‑source repository on GitHub to dive deeper into the implementation details and contribute to the project.
