ISO 27001 Compliance for Self-Hosted Models

When an auditor walks through a self‑hosted environment and sees a complete, immutable audit trail of who accessed what, when, and under which policy, the iso 27001 audit is essentially done. The evidence package includes session recordings, approval logs, and masked data extracts that prove compliance without exposing secrets.

Why iso 27001 matters for self‑hosted deployments

iso 27001 requires organizations to demonstrate that access to information assets is controlled, monitored, and reviewed. Controls such as A.9.2 (user access management), A.12.4 (logging and monitoring), and A.15.1 (supplier relationships) all hinge on reliable artifacts. In a self‑hosted model the responsibility for generating those artifacts lies entirely with the team that runs the infrastructure.

Current gaps in typical self‑hosted setups

Most teams start with a shared service account or a static SSH key that lives on the bastion host. Engineers log in directly to databases, Kubernetes clusters, or internal HTTP services using that credential. The process looks simple, but it creates several compliance blind spots:

• The shared credential masks the individual identity, so the system cannot tell which user executed a command.
• Teams do not record session activity, making replay or forensic analysis impossible.
• Sensitive fields, passwords, personal identifiers, credit‑card numbers, stream back to the client in clear text.
• Emergency access is granted by copying the shared secret, leaving no approval trail.

These gaps mean that, even if the organization has a well‑designed identity provider (the Setup layer that decides who may start a session), the downstream request reaches the target directly without any enforcement point. The audit log remains incomplete, masking never happens, and the team cannot prove that a just in time approval was obtained.

How hoop.dev creates audit‑ready evidence

hoop.dev inserts a Layer 7 gateway between the identity provider and the target resource. Because the gateway is the only place the traffic passes, it becomes the data path where enforcement can be applied.

After a user authenticates via OIDC or SAML, hoop.dev validates the token, extracts group membership, and then proxies the connection. While the request flows through the gateway, hoop.dev can:

• Record every session. hoop.dev captures each command, query, or API call and stores it for replay. This satisfies the logging requirement of iso 27001.
• Apply inline data masking. hoop.dev redacts sensitive response fields before they reach the client, ensuring that auditors can see that data protection controls are active without exposing the raw values.
• Require just in time approval. hoop.dev triggers a workflow for high‑risk operations that must be approved by an authorized reviewer before the command is forwarded.
• Enforce command‑level blocking. hoop.dev rejects dangerous statements such as DROP DATABASE, reducing the blast radius of accidental or malicious actions.

All of these outcomes happen because hoop.dev sits in the data path; removing the gateway would eliminate the evidence entirely. The Enforcement outcomes exist only because hoop.dev is the enforcement point.

Mapping hoop.dev capabilities to iso 27001 controls

iso 27001 does not prescribe a specific tool, but it does require demonstrable evidence. The following mapping shows how hoop.dev’s features align with the standard’s clauses:

• A.9.2.1 – User registration and de‑registration. hoop.dev logs the exact moment a token is accepted and the identity that presented it.
• A.9.2.3 – Management of privileged access rights. hoop.dev’s just in time approval ensures that elevated privileges are granted only after explicit review.
• A.12.4.1 – Event logging. hoop.dev’s session recordings and command‑level logs provide a complete, immutable event trail.
• A.12.4.3 – Administrator and operator logs. hoop.dev records who performed administrative actions and the exact payload.
• A.14.1.2 – Secure development policy. hoop.dev’s inline masking demonstrates that sensitive data never appears in logs or client responses.

Because the gateway deploys inside the same network segment as the target, hoop.dev stores the logs outside the process that executes the commands, satisfying the requirement for separation of duties.

Getting started with hoop.dev for iso 27001 evidence

The first step is to deploy the gateway using the official getting‑started guide. The deployment includes an OIDC configuration that ties the gateway to your existing identity provider. Once the agent runs next to your database, Kubernetes cluster, or HTTP service, you register the resource in hoop.dev’s console. From that point onward, hoop.dev automatically records, masks, and subjects every connection to the approval policies you define.

For deeper guidance on policy design, masking rules, and approval workflows, see the learn section. The documentation provides examples of iso 27001‑aligned policies without exposing any configuration details.

FAQ

Do I need to change my existing client tools?
No. hoop.dev works with standard clients such as psql, kubectl, or SSH. Your scripts and automation continue to function because the gateway presents the same wire‑protocol.

How long does hoop.dev retain session recordings?
You configure retention in the gateway’s policy store, aligning the period with your iso 27001 evidence‑retention schedule.

Can I back‑fill audit data for periods before hoop.dev was deployed?
hoop.dev cannot recreate history that was never captured. However, you can import existing log files into the same storage bucket to keep a unified audit archive.

By placing enforcement in the data path, hoop.dev turns a self‑hosted deployment from a black box into a transparent, auditable system that satisfies iso 27001’s evidence requirements.

View the open‑source repository on GitHub to explore the code, contribute, or fork the project for your own compliance pipeline.