Uncontrolled function calls can silently expose sensitive data, jeopardizing ISO 27001 compliance.
Modern applications increasingly rely on remote function execution – from serverless endpoints to micro‑service RPCs. Each call carries credentials, input parameters, and output that may contain personally identifiable information or proprietary secrets. When a call is made without real‑time visibility, the organization loses the ability to prove who invoked what, when, and whether the response was inspected. ISO 27001 auditors expect a complete audit trail, evidence of data protection, and proof that privileged operations are approved before execution.
Most teams address this gap with periodic log aggregation or post‑mortem reviews. Logs are collected after the fact, often filtered, and may miss transient errors or masked fields. The setup typically includes an identity provider that authenticates the caller and a static credential stored on the function host. That arrangement decides who may start a request, but it does not enforce any guardrails on the data path. The request still reaches the function directly, leaving no opportunity to block risky parameters, mask sensitive output, or require human approval.
ISO 27001 evidence from function calling
To satisfy ISO 27001, an organization must capture continuous evidence of access control, data handling, and auditability. The control point must sit where the request flows, not merely at the authentication layer. By placing a gateway in the data path, every invocation can be inspected, recorded, and, if necessary, altered before it reaches the target function. The gateway also provides a single source for approval workflows, ensuring that privileged calls are reviewed in real time.
hoop.dev fulfills this architectural requirement. It acts as a Layer 7 identity‑aware proxy that sits between callers and the function endpoint. Identity is still handled by an OIDC or SAML provider, which decides whether a request may begin. The gateway then becomes the only place enforcement can happen. It records each session, applies inline masking to response fields that match policy, and can pause execution for a just‑in‑time approval step.
Setup: identity and provisioning
The initial step is to configure an OIDC or SAML identity source – for example, Azure AD, Google Workspace, or Okta – and to map groups to access policies. This setup determines who is allowed to request a function and what level of privilege they receive. While essential, this step alone does not guarantee auditability or data protection; it merely authenticates the caller.
The data path: hoop.dev as the enforcement boundary
Once the identity is verified, hoop.dev forwards the request through its proxy layer. Because the gateway intercepts the wire‑protocol traffic, it can apply three categories of enforcement outcomes:
- Session recording: hoop.dev logs the full request and response payload, timestamps, and caller identity, creating an audit record for ISO 27001 auditors.
- Inline masking: Sensitive fields such as credit‑card numbers or social security numbers are redacted in real time before they are stored or displayed, satisfying the standard’s data‑protection requirements.
- Just‑in‑time approval: If a call matches a high‑risk pattern – for example, a bulk data export – hoop.dev pauses execution and routes the request to an approver, ensuring that privileged actions are explicitly authorized.
All of these outcomes exist only because hoop.dev occupies the data path. Removing the gateway would eliminate the ability to record, mask, or approve calls, leaving the organization without the evidence required by ISO 27001.
Evidence generation for ISO 27001
ISO 27001 Annex A controls demand proof of:
- Access control (A.9) – who accessed which function and when.
- Cryptographic protection (A.10) – that sensitive data is protected in transit and at rest.
- Audit and monitoring (A.12) – that logs are complete, can be reviewed for integrity, and are retained for the required period.
hoop.dev supplies each of these items automatically. The recorded session logs provide the access‑control trail. Inline masking enforces cryptographic‑level protection by ensuring that sensitive data never leaves the gateway in clear form. Because the gateway stores logs separate from the function host, the audit trail can be independently verified for integrity. Together, these artifacts form the continuous evidence set that ISO 27001 auditors expect.
Getting started with hoop.dev
To adopt this model, follow the getting started guide to deploy the gateway and register your function endpoint. The guide walks you through configuring OIDC authentication, defining masking policies, and enabling approval workflows. For deeper details on policy language and audit‑log retention, explore the learn section of the documentation.
FAQ
How does hoop.dev help with ISO 27001 audit logs?
hoop.dev records every function invocation, including caller identity, request parameters, and masked responses. These logs are stored outside the function host, providing an audit trail that can be reviewed for integrity and that aligns with ISO 27001’s audit‑monitoring requirements.
Does hoop.dev replace existing IAM solutions?
No. hoop.dev relies on your existing OIDC or SAML provider to authenticate callers. It adds a layer of enforcement on the data path, but it does not manage user accounts or credentials itself.
Is hoop.dev open source?
Yes. The gateway is MIT licensed and the source code is available on GitHub. Explore the repository to contribute or customize the solution for your environment.
