ISO/IEC 27701 AI Controls Mapping at the HTTP Request Boundary

ISO published ISO/IEC 27701:2025 in October 2025 as the second edition of its Privacy Information Management System standard. The 64-page document specifies requirements for PII controllers and processors and can operate as an independent management system standard. ISO's primary ISO/IEC 27701 page provides the edition and scope. An AI controls mapping should connect that management system to the moment PII enters an HTTP request bound for a model.

I map each requirement through five objects: risk, control, owner, enforcement point, and evidence. On a reviewer's desk, one row should connect a customer-support use case to its purpose rule, approved processor route, test result, exception status, and signed decision sample. A control library without that chain is a filing cabinet with clean labels and empty folders.

The mapping starts with processing scope

The first control object is an inventory of AI applications, agents, model endpoints, HTTP routes, PII categories, business purposes, processor relationships, and owners. Assign a stable system ID to every flow. Record the organization’s controller or processor role for that use case and preserve the approval date for the October 2025 standard edition used in the mapping.

Discovery should cover direct model APIs, embedded assistants, and vendor features that invoke models behind a SaaS interface. Identity-provider application lists, procurement records, network observations, and expense data provide separate discovery signals. Reconcile them on a defined cadence.

A useful architecture diagram shows the authenticated principal, application, policy decision point, approved model routes, evidence store, and trust boundaries. The reviewer should be able to place a finger on the arrow where customer PII leaves organizational control.

Identity and purpose become request attributes

Authentication supplies a caller identity. The mapped privacy control needs more: role, delegated authority, declared purpose, application ID, relevant data-subject context, and the model route requested. Static service credentials collapse several people and agents into one principal, which weakens accountability.

Purpose values should be machine-evaluable. A support summarizer may process a case record under an approved support purpose. A recruiting assistant may require a separate rule, owner, and evidence set. Applications permitted to assert each purpose belong in an allowlist; the policy point resolves the value and records it with the request.

For an August 2026 sample, select one authorized request and one request carrying an expired or unauthorized purpose. The evidence package should show the identity assertion, purpose catalog entry, policy version, decision, and named owner. That turns an abstract purpose-limitation principle into an operating control.

Data handling maps to permit, redact, and deny

Prompt-level classification is the enforcement point for PII entering an LLM request. Define the categories, detection methods, confidence thresholds, redaction fields, denial conditions, approved processor routes, and handling for attachments. Apply a corresponding response policy because a model or connected retrieval source may return PII absent from the original prompt.

The control outcome should be deterministic under a named policy version. Permit data allowed for the declared purpose and destination. Redact defined fields when the remaining content still supports the business task. Deny a request when the route or use falls outside policy. Store enough classification metadata to prove the action while minimizing copied PII in the evidence repository.

Test a scanned document, copied table, misspelled name, mixed-language transcript, and agent-generated follow-up. Five awkward samples expose more than a slide saying sensitive data is monitored.

Processor routes need explicit authorization

Each external model route should map to an approved processor relationship, permitted purposes, PII categories, region or deployment constraints, retention treatment, and accountable owner. Use stable route identifiers. Restrict policy changes and preserve the approval trail.

The application declares its destination, then the policy point verifies that route before transmission. A support use case approved for one model endpoint should fail closed when it targets an unapproved endpoint. Record the denial with identity, purpose, route ID, policy version, and timestamp.

The ISO 27701 mapping also needs the governance artifacts beyond the gateway: processor assessments, contract references, subprocessor review, retention commitments, and privacy-owner approval. DeepInspect can enforce an approved route on HTTP AI traffic. Procurement and privacy teams own the decision that places the route on the approved list.

Retention and deletion require downstream proof

Map separate retention periods for decision metadata, prompt content, response content, embeddings, caches, consent or notice artifacts, incident records, and exceptions. Minimize stored content when a hash, classification, and decision record can prove operation of the control. Restrict and log retrieval whenever content remains available.

Deletion testing should cross application stores, model-provider storage, vector databases, caches, and the audit repository. Use one synthetic data subject and record the request date, systems queried, records found, actions completed, exceptions, and reviewer sign-off. A screenshot of an empty search result is a concrete start, provided the search method and system ID travel with it.

I think “temporary” privacy exceptions without an expiry timestamp should be treated as failed controls on the day they are approved. That opinion will annoy a change advisory board. It also prevents six-month-old bypasses from becoming invisible configuration.

The control matrix needs operational evidence

A working mapping can use the following columns:

| Control area | Enforcement or operating point | Owner | Evidence | |---|---|---|---| | AI processing inventory | Discovery and approval workflow | Privacy owner | Inventory, diagram, review date | | Identity and purpose | HTTP AI policy decision | Application and security owners | Identity assertion, purpose, decision record | | PII classification | Prompt and response inspection | Security owner | Classifier result, policy version, action | | Processor route | Pre-transmission route policy | Privacy and procurement owners | Approved route, contract reference, decision | | Retention and deletion | Connected data stores | Data owner | Schedule, deletion test, exception record | | Incident response | Evidence retrieval workflow | Incident and privacy owners | Query, signed records, exercise result |

Sample permitted, redacted, and denied requests quarterly. Add event-driven tests after a model, processor, data-category, or policy change. Record population, selection method, expected result, observed result, remediation owner, and closure date so a second reviewer can reproduce the sample.

DeepInspect

DeepInspect supplies enforcement and evidence for the HTTP AI rows in this mapping. It sits between authenticated users or agents and LLM APIs. The application provides identity and purpose context; DeepInspect evaluates role, prompt classification, route, model authorization, and policy before forwarding the request. Broader ISO 27701 governance, including processor contracting, consent, rights handling, endpoint controls, and management review, stays with the accountable organizational owners.

Every permit, redact, and deny decision produces a tamper-evident record with identity, route, classification, policy version, outcome, and timestamp. Those records connect the control matrix to reproducible request samples and make policy exceptions visible during review.

Book a technical deep dive at deepinspect.ai.