I would not approve an AI purchase until the required checks are complete, named owners have signed off and the remaining risk is acceptable. That means checking what the system can access, how it uses data and whether you can stop it - not just reading supplier promises.
I use this checklist to cover:
- Scope and privacy: define permitted uses, map data flows and complete a DPIA where needed.
- Access and data protection: test user and agent permissions, encryption, secrets, training restrictions and deletion.
- Logs and testing: trace actions, test alerts and check for prompt injection, data leaks and approval bypass.
- Incident response: agree supplier notification within 24 hours of awareness and test shutdown, recovery and fallback.
- Contract and exit: secure audit rights, at least 30 days’ notice of material changes, usable exports and deletion terms.
- Approval and review: separate pilot from production, record the decision and reassess after changes, incidents and at renewal.
My rule: missing mandatory checks block approval. Pilot approval is not permission to go live.
::: @figure 
{Enterprise AI Procurement: Security Approval Gates}
:::
Check Access Controls and Data Protection
Once the scope is approved, check who can access the system and how data is protected during use.
Limit User Access and Agent Permissions
Test authentication and authorisation separately: who can sign in, and what can each identity do? Require enterprise SSO where supported, MFA for privileged accounts, role-based access and least privilege. Include both employee and non-human identities. Check tenant isolation and confirm that development, test and production environments are separate. Record a named owner, purpose and review date for every service account, alongside joiner, mover and leaver controls.
Give agents scoped credentials that you can revoke. Check their read, write, execution and workflow-trigger permissions in every connected tool. Keep secrets out of prompts and require human approval for high-impact actions.
Test the live configuration - not just the vendor’s documentation. Check both allowed and blocked actions, including prompt injection, cross-tenant access and calls made after credentials are revoked. Record whether cached tokens or queued jobs still work once access is disabled.
Required evidence: the access-control matrix, SSO/MFA configuration, identity and environment documentation, agent permission model, current permission snapshots, recent access-review records and access-test results.
Approval owners: identity and access management approves authentication and account lifecycle controls; security architecture approves isolation and agent permissions; the business process owner approves permitted actions.
With access controls checked, verify that encryption, credential handling and data use match the contract.
Check Encryption, Credentials and Data Use
Compare the deployed settings with the contract, architecture and data-flow map. Check encryption in transit and at rest across APIs, storage, caches, embeddings, backups and logs. Establish who controls the encryption keys and how rotation, revocation and recovery work. Store API credentials in an approved secrets manager and use separate credentials for each environment.
Confirm the contract’s default position on model training, any opt-in route, subprocessors and human-review rules. Verify where processing actually takes place and which transfer safeguards apply, rather than relying on the advertised hosting region.
Test deletion across live data, caches, embeddings and backups. Define backup-expiry periods and test restores.
Required evidence: the deployment-specific encryption specification, key-management policy, credential rotation test, data-processing agreement, applicable transfer safeguards, training-use terms and deletion/restore test results.
Approval owners: information security approves encryption and secrets controls; the data owner approves permitted data use; legal approves contractual and transfer terms; platform architecture validates implementation, with privacy advice where personal data is involved.
Verify Audit Logs, Monitoring and Security Tests
After checking access and encryption, confirm that the system leaves an audit trail investigators can use.
Check Audit Log Coverage and Protection
Before approving the purchase, require logs that support investigation, monitoring and shutdown. These must cover authentication, authorisation, administration, configuration changes, data access, exports, API calls, prompt and output records, agent tool calls, retrieved sources, privilege changes, safety triggers and shutdowns.
Each event should record a timestamp with time zone, system/model version, tenant, identity, action, target, result and correlation ID. Record the agent identity separately from the human or service account that authorised it. This lets investigators tell delegated activity apart from direct user actions. Check that they can trace a request from source retrieval through to the final action - not just see the final response. [3][5]
Prefer immutable or tamper-evident storage, with restricted deletion rights. Set retention periods by data category. Store prompts and outputs only when needed for security, investigation or compliance, using redaction and restricted access.
Run misuse tests before approval. Confirm that exports preserve timestamps, identities, event order and correlation IDs, and that alerts reach security operations and the teams responsible for escalation. Check what happens if logging fails or is disabled. [2][3][5]
Required evidence: sample logs, logging architecture, retention configuration, export-test results and the monitoring runbook.
Approval owners: security operations approves ingestion, alerts and escalation. The system owner confirms coverage and configuration. Privacy or data-protection advice covers content recording, access and retention.
Test AI Risks and Set Retesting Rules
Once logging has been verified, test whether the system detects and blocks known AI failure modes.
Review current vulnerability management and penetration-test findings for this deployment. Supplier assurance does not replace deployment-specific tests for this use case. Test direct and indirect prompt injection, data leakage, unsafe handling of model-generated code or commands, privilege escalation and unexpected agent actions.
Record the scope, exclusions, expected controls, observed results, severity and remediation status. Set thresholds for stopping the system when data exfiltration or approval bypass is confirmed. Require retesting after material changes to the model, prompts, retrieval, tools, permissions or hosting. [2][4]
Required evidence: penetration-test and assurance reports with scope, dates and findings; AI test results; and remediation records showing owners, deadlines and successful retests.
Approval owners: application security approves testing and vulnerability handling. Security operations approves detection. The technical owner confirms deployment coverage and fixes. Record unresolved findings, compensating controls and the approver accepting residual risk.
Confirm Incident Response and Contract Terms
Test Incident Response and Safe Shutdown
After logging and testing, agree how incidents will be reported, contained and recovered from. Define which security, privacy, availability, model-failure and agent-misuse incidents must be reported. Include unauthorised tool use and incidents involving subprocessors or connected systems.
Name 24/7 contacts. Require notification without undue delay and within 24 hours of supplier awareness - not after the investigation ends. Reports must include impact details and containment actions, followed by regular updates, evidence preservation and forensic support.
Keep supplier notification separate from UK GDPR reporting duties. The processor must notify the controller without undue delay. The controller must notify the ICO of a reportable personal-data breach without undue delay and, where feasible, within 72 hours of awareness.[6][7] Do not approve production until the supplier can report, contain and recover from incidents on the agreed terms.
Run a scenario exercise before production launch, annually and after major changes. Test token revocation, agent suspension, cancellation of queued tasks, integration isolation, rollback and controlled recovery. Check that delegated actions actually stop. Set recovery time and recovery point objectives, then test restoration and manual fallback against them.
Required evidence: incident-response plan, escalation matrix, exercise results, and business continuity and disaster-recovery plan.
Approval owners: incident-response lead, information security and the business owner, with privacy and legal advisers approving breach-allocation and UK GDPR terms.
Once response duties are agreed, secure the contract rights needed to enforce them.
Agree Audit, Change and Exit Rights
Make security obligations enforceable after the contract is signed. Set remediation deadlines and require prompt notification of critical vulnerabilities, suspected compromise and unresolved high-risk findings. Include suspension rights and remedies for serious or repeated failures.
Secure rights to updated assurance reports and proportionate, targeted audits after a serious incident. Specify audit scope, confidentiality, costs and access to remediation evidence. Require equivalent protections for subprocessors; the supplier remains responsible for their performance.[8]
Require at least 30 days’ written notice of material changes to models, hosting, subprocessors or data use. Include rights to assess changes, object, suspend processing or terminate if the risks become unacceptable. Allow urgent protective changes, but require a prompt explanation.
Define termination triggers, usable exports, transition support and deletion deadlines. Those deadlines must cover backups, caches and subprocessors, subject to legal retention requirements. Require a deletion certificate recording the scope, dates and exceptions, alongside credential revocation and secure decommissioning. Treat change notice and exit rights as a control, not a commercial extra.
Required evidence: signed contract schedules, supplier notification procedure and an exit plan naming the migration owner, manual fallback, budget in pounds sterling and completion date.
Approval owners: legal and privacy advisers approve data-processing, notification and liability terms; procurement confirms supplier commitments; information security approves controls and assurance rights; the accountable executive accepts material residual risk and exit exposure.
Conclusion: Record the Decision and Plan Reviews
Complete the Security Decision Checklist
At the final procurement gate, use the table as a draft decision record, not a completed assessment. Replace each role with a named person and each deadline with a fixed date. Specify whether approval covers a restricted pilot or production use. Pilot approval does not authorise production.
The default status is remediation required. The go/no-go decision stays no-go until all mandatory evidence is complete.
Use the checklist to create a signed decision record. State the outcome explicitly: completed checks do not, by themselves, mean approval.
| Control | Risk if unmet | Required evidence | Approval owner | Status | Remediation deadline | Decision |
|---|---|---|---|---|---|---|
| ☐ Scope and data flows | Out-of-scope processing | Use-case record; data-flow diagram | Business owner | Set date | ||
| ☐ User and agent access | Overbroad access | Role matrix; effective permissions; agent identities | Security owner | Set date | ||
| ☐ Encryption | Data exposure through weak configuration | Encryption design and configuration | Security owner | Set date | ||
| ☐ Credentials | Credential misuse | Secret storage and rotation evidence | Technical owner | Set date | ||
| ☐ Data use and privacy | Unlawful reuse or retention | Supplier data-use statement; DPIA where applicable | Privacy reviewer | Set date | ||
| ☐ Audit logs | Insufficient traceability | Log samples; retention and integrity controls | Security owner | Set date | ||
| ☐ Monitoring | Missed misuse | Alert rules; escalation test results | Security owner | Set date | ||
| ☐ Security testing | Unidentified weaknesses | Test results; remediation retests | Security owner | Set date | ||
| ☐ Incident support | Slow containment | Response plan; exercise record | Incident-response lead | Set date | ||
| ☐ Safe shutdown | Activity persists after suspension | Revocation and shutdown test results | Technical owner | Set date | ||
| ☐ Supplier assurance | Unverified supplier claims | Independent security report; findings closure | Security owner | Set date | ||
| ☐ Contract rights | Weak enforceability | Signed security and processing schedules | Procurement owner | Set date | ||
| ☐ Exit arrangements | Exit lock-in | Export test; deletion and migration plan | Business owner | Set date |
Use only these outcomes: approved, approved with conditions, remediation required, or rejected. Approval requires complete mandatory evidence and acceptable residual risk.
Conditional approval needs explicit risk acceptance, compensating controls, a named action owner, a deadline and automatic expiry. It cannot waive mandatory requirements. Missing evidence blocks approval until remediation is complete. Reject purchases if mandatory requirements cannot be met or unacceptable risk remains.
Sign the One-Page Approval Record
Once the checklist is complete, set out the decision on one page.
Record the product, model/version, supplier, contracting entity, owners, purpose, deployment, integrations, user groups, data categories, processing locations and risk class. Include the approval scope, outstanding risks, compensating controls and evidence references, with their versions, scope and review or expiry dates.
Obtain named approvals from security, architecture, procurement and the accountable executive. Record legal and privacy reviews while preserving the DPO’s advisory role.
Include production approval and next review dates in UK format (DD/MM/YYYY). Also record suspension triggers, the person authorised to suspend access and the authority responsible for approving a restart.
Reassess at Changes and Key Stages
Approval is time-bound, not permanent. Reassess before pilot and production, at renewal and retirement, after major incidents, and whenever models, integrations, data categories, agent permissions or intended use change.
Check data flows, retention, audit coverage and supplier assurances - not just the model version. Link change records to updated tests, and give every follow-up action a named owner and deadline. Procurement approval and residual-risk acceptance remain with the purchasing organisation.
FAQs
How do I decide which AI security checks are mandatory?
Classify actions by impact and reversibility, and require human approval for high-risk actions. Before deployment, check that access revocation has been tested, tools are contained, secrets stay outside the model’s context, approvals for high-impact actions are enforced, and audit logs show any tampering.
All critical tests must pass before production, with no unresolved findings. Assign named owners, record dependencies and approved exceptions, and complete a data protection impact assessment for processing that poses high risks to individuals under UK GDPR.
When does an AI purchase require a DPIA?
You must complete a Data Protection Impact Assessment (DPIA) before processing personal data that is likely to pose a high risk to individuals’ rights and freedoms [1]. Review and update the assessment whenever the purpose, scope or nature of the processing changes [1].
Hokstad Consulting helps organisations meet these requirements through AI strategy and implementation, including suitable data-minimisation controls [1].
How can I verify security controls without supplier system access?
During procurement, require OpenAPI specifications, data dictionaries, self-service audit tools and automated compliance evidence. Test interoperability with dummy data to check access, authentication and logging.
Use your own monitoring tools, such as Cloud Security Posture Management (CSPM) tools or policy-as-code, to spot configuration drift. Require structured audit logs and incident records so your team can reconstruct events and check that security policies are enforced as documented.