> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist.md).

# 7.3 The security team checklist

A keep-it-by-your-desk checklist across identity, runtime, browser, desktop, supply chain, cloud, data, and audit controls.

{% hint style="info" %}
Use this checklist at intake, the pilot gate, expansion approval, and recertification. A control passes only when it has a named owner, reproducible evidence, and a current test date.
{% endhint %}

*Last reviewed: August 18, 2026*

## What security teams need to know about the AI security checklist

This is the evidence-backed version of the launch checklist. Adapt the required rows to the deployment model, data class, and risk tier in [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md). A skipped row needs a documented rationale. An exception needs an owner and expiry date.

Run the checklist again after an incident, a material vendor or architecture change, a new data class, a change in ownership, or an expansion in autonomy.

## AI security checklist evidence record

Keep these fields with every control decision:

| Field          | Required entry                                                                                  |
| -------------- | ----------------------------------------------------------------------------------------------- |
| Applies?       | Yes or no, with a reason when the control does not apply                                        |
| Status         | Pass, fail, exception, or not tested                                                            |
| Owner          | One accountable person or function                                                              |
| Evidence       | Link to an export, policy, log sample, test result, contract term, or other reproducible record |
| Last tested    | Date the control was last verified, not only configured                                         |
| Exception      | Risk owner, compensating controls, approval, and expiry date                                    |
| Review trigger | Next scheduled review and any event that forces an earlier review                               |

## Common AI security checklist failures

* The checklist is completed once and never recertified.
* Rows are marked as passed without evidence or a recent test.
* Chat, coding agents, desktop agents, hosted agents, and API applications are assessed as if they have the same control plane.
* A provider-wide setting is assumed to cover every surface and authentication path.
* Exceptions have no accountable owner or expiry date.
* Incident responders cannot revoke the agent, connector, credential, task, and published output separately.

## AI security controls checklist

### Governance & rollout

| Check                                                                                                                                           | Typical owner                  | Minimum evidence                             | Handbook |
| ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | -------------------------------------------- | -------- |
| Every AI product, surface, deployment model, authentication path, and environment is in the inventory                                           | AI governance lead             | Inventory export or register                 | 7.1, 7.4 |
| Each entry records a business owner, technical owner, risk tier, permitted data classes, and deployment model                                   | AI governance lead             | Completed inventory fields                   | 7.1, 7.4 |
| Approved and prohibited uses are documented by cohort, surface, data class, and action type                                                     | Security + legal               | Approved-use standard and user communication | 7.1      |
| The pilot gate verifies the required controls and records a go, hold, or stop decision                                                          | Security lead                  | Pilot test record and sign-off               | 7.2      |
| Expansion requires evidence that pilot defects are closed or accepted                                                                           | Security lead + business owner | Remediation tracker and expansion approval   | 7.2      |
| Security, identity, endpoint, data, platform, legal, procurement, and incident-response responsibilities are assigned                           | AI governance lead             | Current RACI                                 | 7.1, 7.3 |
| Exceptions record a risk owner, compensating controls, approval, and expiry date                                                                | Security lead                  | Exception register                           | 7.3      |
| User training covers permitted data, approvals, connectors, output review, and incident reporting before access is granted                      | AI governance lead + security  | Training record and scenario check           | 7.1, 7.2 |
| A tested exit plan covers stopping work, revoking access, ownership transfer, export, deletion, artifacts, schedules, and billing               | AI governance lead + platform  | Exit exercise and deletion evidence          | 7.1, 5.6 |
| Controls are recertified at least quarterly and after incidents, major vendor changes, new data classes, autonomy changes, or ownership changes | Control owners                 | Review calendar and completed review records | 6.7      |

### Identity

| Check                                                                                                                                   | Typical owner             | Minimum evidence                                   | Handbook |
| --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- | -------------------------------------------------- | -------- |
| Managed user surfaces use SSO where supported; unsupported login paths and exceptions are recorded                                      | Identity lead             | IdP configuration and authentication test          | 1.1      |
| SCIM or a documented joiner, mover, and leaver process removes access within the agreed service level                                   | Identity lead             | Provisioning configuration and deprovisioning test | 1.1      |
| Roles or groups restrict high-risk capabilities such as code execution, agents, connectors, browser use, publishing, and administration | Identity lead + security  | Role export and sampled entitlement review         | 1.2      |
| Personal-account use is blocked where tenant restrictions are supported; other surfaces have a tested detection and remediation path    | IT + network security     | Restriction configuration or detection test        | 1.3      |
| Shadow accounts, unmanaged organizations, and accounts on verified domains are discovered and consolidated or removed                   | Identity lead             | Discovery results and remediation log              | 1.4      |
| Agents and other non-human identities have dedicated identities, named owners, narrow scopes, and revocation paths                      | Platform engineering      | Non-human identity inventory and revocation test   | 1.5      |
| API keys, service accounts, workspace tokens, and project credentials are inventoried, vaulted, scoped, and rotated                     | Platform engineering      | Credential inventory and rotation record           | 1.6      |
| Human approval is required before autonomous systems perform actions outside the approved baseline                                      | Security + business owner | Approval policy and sampled allow or denial events | 1.7      |

### Supply chain & extensibility

| Check                                                                                                                           | Typical owner                   | Minimum evidence                                         | Handbook |
| ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------- | -------------------------------------------------------- | -------- |
| Every enabled connector or app has an intake approval recording owner, scopes, data classes, actions, and connected system      | Security + app owner            | Intake register entry and scope export                   | 2.1, 2.7 |
| Local and remote MCP servers are inventoried, authenticated where applicable, and reviewed before enablement                    | Platform engineering            | Server inventory and assessment                          | 2.2      |
| An MCP gateway or equivalent managed restrictions enforce the approved server and tool policy                                   | Platform engineering            | Gateway or managed-policy export and blocked-server test | 2.3      |
| Skills and instruction bundles are reviewed for hidden instructions, tool use, data access, and update behavior                 | Security                        | Review record with content hash or version               | 2.4      |
| Plugins, marketplaces, and extensions are restricted to approved sources and reviewed after material updates                    | Security + endpoint             | Allowlist and versioned review record                    | 2.5      |
| Hooks and lifecycle scripts are inventoried; untrusted, unsigned, or unowned scripts are blocked                                | Platform engineering            | Hook inventory and execution-policy test                 | 2.6      |
| The supply-chain register records the owner, source, version, permissions, review date, and next review trigger                 | Security                        | Complete supply-chain register                           | 2.7      |
| Signed packages, trusted distribution channels, version pinning, and update behavior are verified where supported               | Endpoint + platform engineering | Signature or provenance check and update test            | 2.8      |
| SaaS agent builders are reviewed for templates, connections, collaboration, publishing, and agent transfer or deletion          | Security + app owner            | Builder configuration and publishing test                | 2.9      |
| Hosted-agent frameworks, SDKs, models, tools, containers, and other dependencies have owners and an advisory and update process | Platform engineering            | Dependency inventory and update record                   | 2.10     |

### Runtime, sandbox & autonomy

| Check                                                                                                                                      | Typical owner                   | Minimum evidence                                       | Handbook |
| ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------- | ------------------------------------------------------ | -------- |
| The isolation model is documented for each local and hosted execution path                                                                 | Platform engineering            | Architecture note and configuration export             | 3.1      |
| Coding-agent sandbox and approval settings are centrally enforced where the provider supports managed configuration                        | Platform engineering            | Managed configuration and sampled client check         | 3.1, 3.2 |
| Writes, commands, network actions, credential use, and other high-impact actions require approval beyond the approved baseline             | Security                        | Approval policy and allow or denial events             | 1.7, 3.2 |
| Network egress is denied or restricted by default according to risk, and allowed destinations are owned and tested                         | Network security                | Egress policy and test result                          | 3.3      |
| Browser and internet access are enabled only for approved cohorts and sensitive internal sites have additional protection                  | Security + endpoint             | Role policy, site controls, and blocked-site test      | 3.4      |
| Computer-use and desktop-control capabilities are disabled unless required; enabled workflows have action boundaries and endpoint controls | Security + endpoint             | Capability policy and action test                      | 3.5      |
| Scheduled and background tasks have narrow identities, bounded runtime, rate and spend limits, stop conditions, and reviewable outputs     | Platform engineering            | Task configuration and stop-control test               | 3.6      |
| Remote dispatch, mobile triggers, remote sessions, and SSH paths are authenticated, attributable to an initiator, and revocable            | Platform engineering + identity | Authentication path, event sample, and revocation test | 3.7      |
| Local filesystem access is limited to approved roots; sensitive, home, credential, and cloud-synced paths are denied unless required       | Endpoint + security             | Path policy and denied-access test                     | 3.8      |
| Hosted triggers are authenticated and protected against replay; the control plane is outside the agent's writable runtime                  | Platform engineering            | Trigger tests and architecture evidence                | 3.9      |
| Hosted agents use task-scoped, short-lived credentials issued through a broker or vault where feasible                                     | Platform engineering + identity | Credential policy and active-run revocation test       | 3.9, 4.7 |
| Hosted-agent workloads isolate tenants and tasks, use managed secrets, restrict egress, and limit spend, rate, duration, and actions       | Platform engineering            | Runtime configuration and boundary tests               | 3.9      |
| Hosted tasks have a tested kill switch that stops work and revokes active credentials, sessions, and downstream access                     | Platform engineering + IR       | Kill-switch exercise record                            | 3.9, 5.6 |

### Data protection & residency

| Check                                                                                                                                             | Typical owner                     | Minimum evidence                                     | Handbook |
| ------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | ---------------------------------------------------- | -------- |
| Every approved surface has a tested DLP enforcement or evidence path; exclusions and unsupported paths are documented                             | Data protection                   | Test prompts, alerts, and coverage matrix            | 4.1      |
| Data classes are mapped to allowed products, surfaces, connectors, actions, and deployment models                                                 | Data protection                   | Class-to-tool matrix                                 | 4.2      |
| Processing, storage, support, log, backup, and subprocessor regions are verified for each surface and plan                                        | Compliance + privacy              | Contract terms, settings, and regional test evidence | 4.3      |
| Retention is configured per surface; regulated data is limited to surfaces with a proven retention posture                                        | Compliance                        | Retention export and deletion test                   | 4.4      |
| Zero Data Retention eligibility and exclusions are recorded by endpoint, feature, and session type                                                | Compliance + platform engineering | Provider terms and endpoint configuration            | 4.4      |
| Training and data-use terms are confirmed for each product, plan, workspace, and authentication path                                              | Compliance                        | Contract, admin setting, or provider term            | 4.5      |
| Knowledge bases, embeddings, vector stores, memory, fine-tuning and evaluation datasets, caches, backups, and exports have lifecycle owners       | Data protection + platform        | AI data-store inventory and lifecycle records        | 4.4      |
| Source permission changes and deletion requests propagate to retrieval indexes, generated artifacts, and downstream copies or gaps are documented | Data protection + app owner       | Permission and deletion propagation tests            | 4.4, 4.6 |
| Cross-app transfers, generated files, live artifacts, links, publishing, and downstream sharing are in the data-flow review                       | Data protection + app owner       | Data-flow diagram and sharing test                   | 4.6      |
| Secrets and credentials are blocked or scrubbed from prompts, tool parameters, logs, traces, and agent configuration                              | Security engineering              | Secret-scanning and redaction test results           | 4.7      |

### Threats & incident response

| Check                                                                                                                                               | Typical owner                      | Minimum evidence                          | Handbook |
| --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- | ----------------------------------------- | -------- |
| Prompt-injection scenarios have been exercised against untrusted content and connected tools                                                        | Security testing                   | Test report and remediation record        | 5.1      |
| Exfiltration through connectors, tools, files, URLs, browser actions, and generated artifacts has been tested                                       | Security testing + data protection | Exfiltration test report                  | 5.2      |
| Vulnerabilities and supply-chain advisories for enabled clients, SDKs, extensions, servers, and runtimes are tracked and remediated                 | Vulnerability management           | Advisory and patch record                 | 5.3      |
| Memory poisoning, data poisoning, spoofed tool results, SSRF, replay, approval races, and denial-of-wallet are covered in design review and testing | Security architecture + testing    | Threat model and abuse-case tests         | 5.4, 5.5 |
| Tool poisoning, identity confusion, permission inheritance, and confused-deputy scenarios are covered in design review and testing                  | Security architecture              | Design review and abuse-case tests        | 5.4      |
| High-risk workflows are red-teamed before expansion and after material changes                                                                      | Security testing                   | Scoped red-team report                    | 5.5      |
| The incident runbook covers revoking users, agent identities, connectors, credentials, remote tasks, sessions, and published artifacts              | IR lead                            | Current runbook and containment checklist | 5.6      |
| Incident responders have exercised the containment path and can identify required evidence by surface                                               | IR lead + security operations      | Tabletop or technical exercise record     | 5.6, 6.6 |
| Each material workflow has a current threat model covering data, identity, tools, runtime, users, outputs, and trust boundaries                     | Security architecture              | Approved threat model                     | 5.7      |

### Observability, audit & evidence

| Check                                                                                                                                               | Typical owner                              | Minimum evidence                                   | Handbook |
| --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | -------------------------------------------------- | -------- |
| Audit coverage and known gaps are documented per product, surface, authentication path, and execution location                                      | Security operations                        | Coverage matrix and tested event samples           | 6.1      |
| Telemetry uses a versioned schema with normalized timestamps, source identifiers, correlation IDs, model and policy versions, targets, and outcomes | Security operations + platform engineering | Schema and representative event samples            | 6.2      |
| Delivery latency, completeness, source health, sampling, clock drift, parser failures, and retention are measured and reconciled                    | Security operations                        | Telemetry SLO and reconciliation report            | 6.2, 6.6 |
| Agent telemetry records the required identifiers, actions, approvals, tool activity, outcomes, and errors                                           | Security operations + platform engineering | Telemetry schema and event samples                 | 6.2      |
| Prompt, response, and tool-content capture follows a documented content, redaction, access, and retention policy                                    | Security operations + privacy              | Collector configuration and redaction test         | 6.2      |
| All available audit and compliance sources are collected; coverage, retention, and exclusions are tested and recorded                               | Security operations                        | Collection configuration and reconciliation report | 6.3      |
| Usage, adoption, model, token, task, and spend analytics are reviewed for anomalies and unowned activity                                            | FinOps + security operations               | Review report and follow-up record                 | 6.4      |
| SIEM detections are selected from approved threat scenarios, tested with representative events, and linked to response runbooks                     | Security operations                        | Detection test and runbook link                    | 6.5      |
| Every enabled surface has a tested evidence path for the investigation questions it must answer                                                     | Security operations + compliance           | Scripted-action reconciliation report              | 6.6      |
| Review records show quarterly recertification and out-of-cycle reviews after defined trigger events                                                 | AI governance lead                         | Review history                                     | 6.7      |

## Anthropic checklist implementation notes

Inventory Anthropic surfaces separately: Claude Web, Claude Mobile, Claude Desktop (Chat / Cowork / Code), Claude Code, Claude Design, Claude in Chrome, Claude Tag, Claude for Microsoft 365, and the Anthropic API & Agent Platform. They can share an organization but differ in endpoint exposure, execution location, available controls, and evidence.

Within Claude Desktop (Chat / Cowork / Code):

* **Chat** uses the managed Claude workspace and connector policy, while the desktop installation adds endpoint, local file, local MCP, and extension considerations.
* **Cowork** may run remote research tasks or use local folders, apps, browser actions, and computer use. Record the execution path for each approved workflow. Anthropic currently excludes Cowork and its Microsoft 365 add-ins from audit logs, the Compliance API, and data exports, so test the available OpenTelemetry feed and downstream application evidence before production.
* **Code** brings the Claude Code agent into the desktop. Apply local repository, shell, filesystem, network, approval, and managed-settings controls in addition to desktop deployment controls.

Claude Code also runs through the CLI, IDE integrations, and hosted or remote workflows where enabled. Treat each path separately:

* **CLI and IDE:** local operating-system identity, repository trust, shell, filesystem, credentials, MCP servers, hooks, sandboxing, and egress are the primary boundaries.
* **Desktop Code:** the same local agent risks apply, plus app deployment, updates, local extensions, and desktop permissions.
* **Hosted or remote tasks:** review remote environment isolation, secrets, repository access, egress, retention, spend, task termination, and server-side logs.
* **Remote dispatch:** preserve initiator attribution and test session and task revocation.

Claude Design should appear in the product inventory when enabled, with its input assets, generated outputs, sharing behavior, retention, and audit evidence reviewed. Claude Tag belongs in the hosted-agent column, including Slack scope, service accounts, Access bundles, retained memory, spend limits, Agent Proxy egress, and evidence across Claude, Slack, and connected systems. Managed Agents belongs under the Anthropic API & Agent Platform; apply API project, SDK, dependency, hosted-runtime, retention, and observability controls rather than creating a separate workforce-app category.

### Anthropic documentation

* [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans)
* [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claudes-capabilities)
* [Getting started with local MCP servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop)
* [Claude Code settings](https://code.claude.com/docs/en/settings)
* [Configure Claude Code permissions](https://code.claude.com/docs/en/permissions)
* [Claude Code security](https://code.claude.com/docs/en/security)
* [Claude Code data usage](https://code.claude.com/docs/en/data-usage)
* [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage)
* [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview)
* [Monitor Claude Cowork activity with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry)
* [Work across Microsoft 365 apps with Claude](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps)
* [Configure OpenTelemetry for Claude's Office agents](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents)
* [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview)
* [API and data retention](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention)
* [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access)
* [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data)
* [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit)

### Applicable Harmonic guide

* [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide)

## OpenAI checklist implementation notes

Inventory OpenAI as ChatGPT Web, ChatGPT Mobile, ChatGPT Desktop (Work / Codex), Codex, and the OpenAI API Platform. Keep the ChatGPT workspace, local Codex clients, Codex cloud, and API organization or project controls separate even when the same person uses them.

Within ChatGPT Desktop (Work / Codex):

* **Work** is an agentic workspace that can research, create files and sites, use connected apps, and, where enabled, interact with the local computer. Review connected-app scopes, local permissions, browser or computer-use boundaries, generated artifacts, publishing, and the gap between message evidence and action evidence.
* **Codex** runs coding-agent workflows from the desktop. Apply repository trust, sandbox, approvals, filesystem, network, MCP, plugin, hook, and managed-configuration controls.

Codex also runs in the CLI, IDE extension, web or cloud tasks, and remote workflows:

* **CLI and IDE:** local repository, shell, filesystem, credentials, MCP, hooks, sandbox, approvals, and egress are the main boundaries.
* **Desktop Codex:** add desktop deployment, update, local application, plugin, and endpoint controls.
* **Web or cloud tasks:** review environment isolation, repository access, cloud secrets, egress, retention, spend, task termination, and hosted evidence.
* **Remote dispatch:** preserve initiator attribution and test task, session, and credential revocation.

For the OpenAI API Platform, inventory organizations, projects, service accounts, API keys, model and tool access, data controls, rate and spend limits, and logs. Treat the Responses API and Agents SDK as application and hosted-agent components. Agent Builder is a low-code builder in transition and is scheduled for shutdown on November 30, 2026; new and migrated workflows need an owned target architecture and migration date.

The Enterprise Compliance API covers messages and responses across Chat, Work, and ChatGPT-authenticated Codex, but not Work files, actions, or tool calls. API-key-authenticated Codex follows API organization and project settings and does not appear in ChatGPT Compliance API exports. Keep a separate evidence row for each path.

### OpenAI documentation

* [RBAC](https://help.openai.com/en/articles/11750701-rbac)
* [Admin controls, security, and compliance in apps](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-in-apps-enterprise-edu-and-business)
* [Moving to the new ChatGPT desktop app](https://help.openai.com/en/articles/20001276)
* [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275)
* [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq)
* [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256)
* [Sites in ChatGPT](https://help.openai.com/en/articles/20001339)
* [Computer Use](https://learn.chatgpt.com/docs/computer-use)
* [Chat and file retention policies in ChatGPT](https://help.openai.com/en/articles/8983778-chat-and-file-retention-policies-in-chatgpt)
* [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing)
* [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security)
* [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration)
* [Codex governance](https://developers.openai.com/codex/enterprise/governance)
* [Agents SDK](https://developers.openai.com/api/docs/guides/agents)
* [Agent Builder](https://developers.openai.com/api/docs/guides/agent-builder)
* [Workspace Agents](https://developers.openai.com/workspace-agents)

### Applicable Harmonic guides

* [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide)
* [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice)

## Frequently asked questions about the AI security checklist

### When should the checklist run?

Run it at intake, the pilot gate, production expansion, and quarterly recertification. Run it earlier after incidents, material vendor or architecture changes, new data classes, autonomy changes, or ownership changes.

### Should every row be required?

No. The deployment model, data class, and risk tier determine which rows apply. A skipped row needs a rationale. A required control that is not met needs a time-bounded exception or a rollout stop.

### What counts as evidence?

Prefer reproducible evidence: configuration exports, policy files, event samples, reconciliation reports, contract terms, and test results. Screenshots and attestations are fallbacks when the provider offers no export, and they should be reviewed more often.

### Who maintains the checklist?

One security owner should maintain the checklist structure. Identity, platform, endpoint, data, privacy, legal, procurement, incident response, and business owners remain accountable for the evidence in their domains.

## Applicable regulations and frameworks

| Governance page                                     | Relationship to this article                                                                                              |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| G.1 Map your controls to NIST AI RMF and CSF 2.0    | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.                     |
| G.3 DORA and AI resilience in financial services    | Conditional: for a DORA-regulated workflow, this supports risk-based rollout, control validation, and recovery readiness. |
| G.5 SANS Critical AI Security Guidelines mapping    | This article implements relevant SANS Deployment Strategies and GRC guidance.                                             |
| G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy.                           |
| G.8 ISO/IEC 42001 AI management system              | This article supports ISO/IEC 42001 AIMS preparation through readiness evidence for operating the management system.      |

*G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.*

## Related handbook guidance

* [7. Rollout & Operations](/handbook/7.-rollout-and-operations.md)
* [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan.md)
* [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md)
* [G.6 Write an AI Acceptable Use Policy that holds up](/reference/governance-and-frameworks/g.6-write-an-ai-acceptable-use-policy-that-holds-up.md)
* [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.