ISO 27001 and AI: Mapping Information Security Controls to Governance

ISO 27001 and AI: Mapping Information Security Controls to Governance

ISO 27001 does not ask whether your team likes AI. It asks whether your organization can identify risk, enforce controls, and produce evidence that those controls operate as intended. That is where many AI projects get exposed. The model may work, but the organization cannot show how requests are screened, how tool use is constrained, how provider choices are governed, or how incidents would be reconstructed later. Keeptrusts helps because it turns those questions into runtime controls and exportable evidence.

Use this page when

• You are translating information security control objectives into concrete AI governance controls.
• You need a control mapping that engineers can implement and auditors can inspect.
• You want to connect policy chains, event exports, and signed evidence instead of treating ISO work as a document-only exercise.

Primary audience

• Primary: Compliance officers, security architects, and platform engineers
• Secondary: Technical Leaders preparing for AI control reviews

The problem

Organizations often approach ISO 27001 and AI from the wrong direction. They start with a list of control statements, then try to write prose proving the controls must be happening somewhere. Auditors are rarely satisfied by that for long. AI systems create fast-moving risks at runtime: prompt injection, sensitive-data disclosure, unsafe tool execution, abuse spikes, and provider-routing mistakes. If those risks are only discussed in policy documents, the control environment is weak.

The other mistake is expecting one governance feature to satisfy every control family. Access control, operational monitoring, change discipline, incident evidence, and third-party risk are related, but they are not the same. A useful mapping needs separate control points. For AI systems, that usually means a request boundary, a tool boundary, an event and export boundary, and a provider boundary.

The solution

The practical mapping is to align ISO-style control objectives with Keeptrusts runtime surfaces rather than with generic “AI safety” language.

For access and authorized behavior, use Tool Validation, Tool Security, and Agent Firewall. These give you declared tool allowlists, serialized request scanning, exact-match allow and deny rules, action caps, and transaction thresholds.

For information protection, use Prompt Injection Detection, DLP Filter, PII Detector, and Data Routing Policy. Those controls address the core AI risks of adversarial instruction, structured identifiers, custom secret patterns, and provider eligibility.

For monitoring and evidence, keep Audit Logger in the chain so the runtime records that audit logging is active, then use kt events and Tutorial: Exporting Compliance Evidence to package the real decision stream. Where the review requires tamper-evident proof, Regulated Execution adds DSSE-signed evidence with SHA-256 digest chains.

That mapping is stronger than a paper matrix because every row ties back to an implemented product surface. It also matches the way engineers actually work: a control is only useful when someone can lint it, deploy it, test it, and export evidence from it.

Implementation

The most useful starting point is not a monster template. It is a small baseline chain that clearly expresses your governance intent and creates evidence for later review.

pack:
  name: iso-ai-governance-baseline
  version: 1.0.0
  enabled: true

providers:
  targets:
    - id: compliant-openai
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true

policies:
  chain:
    - prompt-injection
    - dlp-filter
    - pii-detector
    - data-routing-policy
    - tool-validation
    - tool-security
    - agent-firewall
    - audit-logger

policy:
  prompt-injection:
    use_embedding: true
    detection:
      embedding_threshold: 0.78
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  dlp-filter:
    blocked_terms:
      - board acquisition room
      - internal pricing model
    action: block

  pii-detector:
    action: redact
    redaction:
      marker_format: label
      include_metadata: true

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    on_no_compliant_provider: block
    log_provider_selection: true

  tool-validation:
    declared_tools:
      - knowledge_lookup
      - web_search
    allow_undeclared: false

  tool-security:
    analysis_mode: local

  agent-firewall:
    blocked_tools:
      - shell_command
      - delete_database
    max_actions_per_window: 3
    max_actions_per_session: 12

  audit-logger: {}

That baseline gives you a usable control story: hostile prompts block, custom secret phrases block, structured identifiers redact, non-compliant providers are excluded, undeclared tools fail, unsafe tool requests are scanned, dangerous actions are denied, and the chain is visible in the event record.

From there, add evidence collection as an operating routine:

kt policy lint --file iso-ai-governance-baseline.yaml
kt events export --since 30d --format json --output iso-review-window.json
kt export-jobs create --from "2026-05-01T00:00:00Z" --to "2026-05-31T23:59:59Z" --format json

That is how a control mapping stops being theoretical. You can point an auditor to the chain design, the live decision stream, and the evidence export procedure in the same review.

Results and impact

The immediate benefit is that ISO discussions become operational. Instead of arguing abstractly about whether AI is “covered” by security controls, the team can point to the exact Keeptrusts surfaces that enforce access, protect data, constrain third-party routing, and create review evidence.

The longer-term benefit is audit speed. When controls are already implemented as a policy chain and evidence export is part of normal operations, review cycles stop depending on manual reconstruction. That lowers preparation time and makes remediation more targeted because gaps are attached to a specific control, not to a vague program objective.

Key takeaways

• ISO 27001 mapping for AI works best when each control objective points to an implemented gateway or evidence surface.
• Keep data protection, tool governance, provider governance, and evidence generation as separate control families.
• Audit Logger marks audit logging as active, while kt events and export workflows provide the actual reviewable records.
• Use Regulated Execution when the review requires DSSE-signed evidence and digest chains.
• Start with a small baseline chain and expand only where risk or regulation requires it.

Next steps

• Policy Controls Catalog
• Tutorial: Building Custom Policy Chains
• Tutorial: Exporting Compliance Evidence
• Regulated Execution