What auditors expect when they ask for ISO 27001 evidence
When an ISO 27001 audit arrives, the compliance team should be able to hand over a complete, tamper‑evident trail that proves who accessed each system, what commands were run, and that any sensitive data was protected. The artifact set typically includes user‑level access logs, approval records for privileged actions, and proof that data‑masking policies were enforced during the session. If any of those pieces are missing, the auditor will flag a control deficiency and the organization must spend weeks reconstructing the missing information.
Why traditional setups fall short
Most engineering environments rely on a mix of static service accounts, long‑lived SSH keys, and role‑based permissions that are granted once and never revoked. Those mechanisms answer the question “who may connect?” but they do not answer “what did the user actually do?” Session activity is often confined to the host’s syslog, which is not tied to the identity that initiated the connection. Sensitive fields, credit‑card numbers, personal identifiers, API secrets, travel over the wire in clear text because there is no inline data‑masking layer. Finally, approvals for risky commands are handled manually in ticketing systems, leaving no immutable record that the approval was linked to the exact command that later executed.
What the compliance‑first precondition looks like
Organizations that have already federated identities with an OIDC or SAML provider have solved the first piece: they know which user or service account is making a request. They also have network‑level firewalls that restrict which hosts can be reached. What remains missing is a control surface that sits on the actual data path, where every request can be inspected, logged, and, if needed, blocked or approved before it reaches the target system. Without that data‑path enforcement, the organization still lacks the concrete evidence required by ISO 27001 clauses A.12.4 (logging) and A.14.2 (secure development).
How hoop.dev generates ISO 27001 evidence
hoop.dev is a Layer 7 gateway that sits between the authenticated identity and the infrastructure resource. Because all traffic flows through the gateway, hoop.dev can enforce a set of guardrails and simultaneously capture the artifacts auditors demand.
- Session recording. hoop.dev records each protocol interaction, SQL statements, SSH commands, Kubernetes exec calls, in a replayable format. The recordings are stored separately from the target host, ensuring the evidence cannot be altered by a compromised node.
- Just‑in‑time approvals. When a request matches a high‑risk policy (for example, a DROP TABLE on a production database), hoop.dev pauses the operation and routes it to an approver. The approval decision, the approving identity, and the exact command are all logged together.
- Inline data masking. Sensitive response fields are filtered in‑flight. The mask configuration is part of the policy, so the audit log shows the original value was redacted while the downstream system never sees the unmasked data.
- Identity‑driven access control. The gateway validates the OIDC token, extracts group membership, and enforces per‑user, per‑resource policies. Because the credential used to talk to the backend is held only by the gateway, the user never sees it.
- Immutable audit trail. Every decision, including allow, block, mask, and approve, is written to an append‑only log that can be exported for audit. The log includes timestamps, source IP, and the identity that initiated the request.
All of these outcomes are produced because hoop.dev is the only component that sits in the data path. The identity federation and network segmentation that exist beforehand do not provide any of the above capabilities on their own.
Mapping hoop.dev artifacts to ISO 27001 controls
ISO 27001 requires concrete evidence for several control families. The following table shows how hoop.dev’s outputs satisfy those requirements: