ISO/IEC 27701 AI Compliance Checklist for the Request Boundary
ISO/IEC 27701:2025 turns privacy management into operational work for AI systems. This checklist covers inventory, identity, purpose, prompt classification, processor routes, retention, incident response, testing, and request-level evidence, with a clear boundary between privacy governance and HTTP AI enforcement.
ISO published the second edition of ISO/IEC 27701 in October 2025. The 64-page standard specifies requirements for establishing, implementing, maintaining, and continually improving a Privacy Information Management System for PII controllers and processors. ISO's primary page for ISO/IEC 27701:2025 identifies the edition and scope. For AI systems, privacy management becomes visible in each HTTP request carrying a customer record, interview transcript, support case, or account number to a model.
I use a practical test for this checklist: pick one request at 09:17 and retrieve its identity, purpose, data classification, processor route, policy version, outcome, and retention treatment. A polished privacy policy cannot supply that evidence. The control work lives in named systems with owners, test dates, and records.
1. Inventory each AI processing flow
Create a register of applications, agents, model providers, HTTP routes, PII categories, declared purposes, and owners. Give every flow a stable identifier. The October 2025 edition applies to PII controllers and processors, so record the organization's role for each use case and the relationship with every external model provider.
Include embedded assistants and SaaS features that call a model behind their interface. Procurement records, identity-provider applications, network observations, and expense data provide useful discovery inputs. A square labeled “AI” on a data-flow diagram hides the details an assessor needs. Show the authenticated user or agent, calling application, policy point, model endpoint, evidence store, and each trust boundary.
Evidence: approved inventory, data-flow diagram, owner list, processor register, and discovery report dated within the current review cycle.
2. Bind identity and purpose to every request
Authentication identifies the caller. Privacy control also needs the caller's role, delegated authority, declared purpose, system ID, and relevant data-subject context. A static API key often identifies only the application. Pass verified identity context with the model call and resolve it at the policy decision point.
Define purpose values that engineering systems can evaluate. A support assistant can summarize a case under an approved support purpose. A general coding assistant should be denied access to a production customer table. Purpose values need an owner, approver, expiry or review date, and a list of applications allowed to assert them.
Evidence: identity schema, purpose catalog, approval records, negative test using an unauthorized purpose, and decision samples tied to named identities.
3. Classify prompts and responses before release
Run prompt-level classification before an HTTP request reaches the model. Document PII categories, detection methods, confidence thresholds, redaction actions, denial actions, and approved destinations. Test attachments, copied tables, scanned documents, and mixed-language text because regulated information often sits beyond the first prompt line.
Response inspection deserves its own rule set. A model can return PII retrieved through an approved tool or context source even when the original prompt contains none. The August 2026 control owner should test permit, redact, and deny outcomes under the same policy version and preserve the observed result.
Evidence: classifier configuration, policy version, test corpus, expected outcomes, observed outcomes, remediation owner, and completion date.
4. Control model and processor routes
Maintain an allowlist of model endpoints and processor routes for each purpose and data category. Record regional restrictions, contractual commitments, subprocessors, approved retention behavior, and the owner who accepted the route. Policy should deny an unapproved destination before transmission.
The application must identify the route it intends to use, while the enforcement layer verifies that request against policy. A free-text destination chosen by the caller provides weak assurance. Use stable route IDs and restrict who may create or modify them.
Evidence: approved route register, processor assessment, contract reference, route-policy export, change history, and a denied request to an unapproved endpoint.
5. Minimize content and enforce retention
Store the least content required to prove the control. Decision metadata may establish identity, classification, route, policy version, and outcome without preserving a full prompt. When prompt or response content must be retained, restrict access, encrypt the store, log retrievals, and connect the record to the applicable retention schedule.
Deletion needs an operational path across application logs, model-provider stores, vector databases, caches, and audit repositories. Run a dated deletion test using one synthetic data subject. A green row in a spreadsheet means little if a copied transcript remains inside a downstream index.
Evidence: retention schedule, minimization rationale, access records, deletion workflow, test result, exception log, and corrective-action ticket.
6. Prepare incident and rights-response evidence
Privacy incidents involving AI need request-level reconstruction. Preserve the identity, delegated user where relevant, system and route IDs, purpose, classification, policy version, action, timestamp, and a tamper-evident reference. Keep application administrators away from the evidence write path where feasible.
Use the same identifiers to support internal investigation and data-subject response processes. The privacy team should be able to locate AI processing associated with a person without searching raw prompts by hand. Test that retrieval path before an incident, with legal and privacy owners reviewing the result.
Evidence: incident procedure, retrieval query, sample result, evidence-access log, response owner, and exercise date.
7. Assign owners, exceptions, and review dates
Every checklist row needs one accountable owner, an operating team, review cadence, evidence location, failure response, and approval status. Separate privacy-policy approval from daily gateway administration. Exceptions require a reason, scope, compensating control, approver, expiry date, and closure test.
Run a quarterly sample plus event-driven testing after a model change, processor change, new PII category, material incident, or policy update. Select permitted, redacted, and denied requests. I would rather show an assessor three failed tests with dated remediation than a perfect dashboard built from samples nobody can reproduce.
Evidence: responsibility matrix, review calendar, exception register, sample method, findings, and signed closure records.
DeepInspect
DeepInspect covers the HTTP AI request boundary inside this checklist. It sits between authenticated users or agents and LLM APIs, evaluating identity, role, purpose context, prompt classification, route, model authorization, and policy before forwarding a request. Consent collection, processor contracting, data-subject rights administration, endpoint protection, and the broader Privacy Information Management System remain with their respective owners.
Each permit, redact, and deny decision produces a tamper-evident record containing the policy version and enforcement outcome. Those records give the ISO 27701 control owner a reproducible sample for request authorization, route control, data minimization, incident reconstruction, and exception testing.
Book a technical deep dive at deepinspect.ai.