ISO 27001 for Computer Use

When an iso 27001 audit closes, the evidence package for computer use is a tidy collection of immutable logs, approved access records, and masked data traces that prove every command was authorized and no sensitive data leaked.

Auditors ask for concrete artifacts that answer three questions: who accessed which system, what they did while connected, and whether any protected information was exposed. In practice teams often rely on shared passwords, ad‑hoc SSH keys, or privileged service accounts that bypass logging entirely. Even when basic syslog is enabled, the logs rarely capture the exact command line, the user who issued it, or the outcome of a query. Without a single control point that can inspect traffic, organizations cannot demonstrate the granular accountability required by iso 27001 control A.9.2 (user access management) or A.12.4 (event logging).

Why auditors need concrete artifacts for iso 27001

ISO 27001 expects the following evidence for computer use:

• Identity proof that each session started with a verified, least‑privilege credential.
• Just‑in‑time approval records that show a manager or security officer authorized any elevated operation.
• Command‑level audit trails that capture the exact input and output of each interaction.
• Inline masking logs that prove sensitive fields (credit‑card numbers, personal identifiers) were redacted before reaching the user.
• Immutable session recordings that can be replayed for forensic analysis.

When these artifacts are scattered across disparate systems, AD logs, SSH bastion logs, database query logs, correlating them becomes a manual, error‑prone effort. Auditors then raise findings for “insufficient evidence of access control” or “lack of data leakage monitoring.” The root cause is not a missing policy but a missing enforcement point where all traffic can be inspected and recorded.

How hoop.dev generates evidence for iso 27001

hoop.dev provides a layer‑7 gateway that sits between users (engineers, service accounts, AI agents) and the target computer resources. The gateway is the only place where traffic can be inspected, masked, approved, and recorded. The overall flow consists of three logical layers:

1. Setup – identity verification. Users authenticate with an OIDC or SAML provider (Okta, Azure AD, Google Workspace). hoop.dev validates the token, extracts group membership, and decides whether the request may proceed. This step determines *who* the request is, but it does not enforce any command‑level policy.
2. The data path – the gateway. All network traffic to the target computer passes through the hoop.dev proxy. Because the gateway operates at the protocol layer (SSH, RDP, database wire protocol, etc.), it can apply guardrails in real time.
3. Enforcement outcomes – audit, masking, approval, recording. While the request traverses the gateway, hoop.dev records the full session, logs each command with the associated user identity, masks any configured sensitive fields before they are returned, and can pause execution to request a human approval for risky operations. The result is a single source of truth that satisfies the evidence requirements listed above.

Because hoop.dev holds the credential for the target system, the user never sees the secret. The gateway can therefore enforce “the agent never sees the credential” while still allowing just‑in‑time access. Each recorded session is retained for the configured retention period, and the logs are preserved without alteration.

Mapping hoop.dev artifacts to iso 27001 controls

The following table shows how the artifacts produced by hoop.dev align with specific iso 27001 clauses:

• A.9.2.1 – User registration and de‑registration. Identity tokens verified by the gateway prove that only registered users can start a session.
• A.9.2.3 – Management of privileged access rights. Just‑in‑time approvals recorded by the gateway demonstrate that privileged commands were explicitly authorized.
• A.12.4.1 – Event logging. Command‑level logs and session recordings give a complete, chronological record of all activity.
• A.12.4.3 – Administrator and operator logs. The gateway logs operator actions, including approvals and masking events, in a single audit trail.
• A.18.1.4 – Protection of records. Masking logs prove that sensitive data was transformed before exposure, satisfying data‑handling requirements.

By consolidating these controls into one gateway, organizations eliminate gaps that typically appear when logging is delegated to individual servers or third‑party tools.

Getting started with hoop.dev

Deploying hoop.dev is straightforward. The official quick‑start uses Docker Compose to launch the gateway and an agent that lives next to the target computer. Once the container is running, you register the computer as a connection, configure the OIDC provider, and define which fields should be masked. Detailed steps are available in the getting‑started guide. Because hoop.dev is open source and MIT‑licensed, you can host it on‑premises or in a private cloud, keeping the audit data under your own control.

For deeper insight into masking policies, approval workflows, and session replay, explore the learn section. The documentation includes best‑practice patterns for aligning the gateway with iso 27001 evidence requirements.

FAQ

Do I need to replace my existing authentication system?

No. hoop.dev acts as a relying party for your existing OIDC or SAML identity provider. It consumes the token, validates it, and then enforces policies on the data path.

Can hoop.dev be used with legacy systems that only support password authentication?

Yes. The gateway stores the password securely and presents it to the target system on behalf of the user. The user never sees the credential, and all activity is still recorded and masked.

How long are session recordings retained?

Retention is a policy decision you configure when you set up the gateway. hoop.dev stores recordings for the period you define, ensuring they remain available for audit purposes.

Explore the source code and contribution guide on the GitHub repository to get started quickly.

By placing a single, identity‑aware proxy in front of every computer resource, hoop.dev generates the concrete, auditable artifacts that ISO 27001 expects, while keeping the implementation simple and open source.