Your developers are using ChatGPT to debug code. Marketing is running campaign copy through Claude. Support is testing AI chatbots you didn't approve. According to Gartner analyst Andrew Walls, every CISO he speaks with has discovered some form of shadow AI in their organization.
You need a systematic way to inventory these tools, assess their risks, and decide what stays, what goes, and what needs governance. Here's a template that provides a repeatable process.
Purpose of the Template
This discovery and assessment template helps you identify unauthorized AI tools across your organization and make informed decisions about each one. Unlike shadow IT, where the main risk is often data exfiltration or compliance violations, shadow AI introduces risks that security strategist Olivia Rose warns "can become physical very, very quickly." This includes AI-generated code with vulnerabilities or AI systems making operational decisions without human oversight.
Use this template when:
- You suspect employees are using unapproved AI tools.
- You need to build your first AI governance policy.
- Auditors ask how you're managing generative AI risk.
- You're preparing for SOC 2 Type II or ISO 27001 certification and need to demonstrate control over AI systems.
Prerequisites
Before you run this discovery process, you need:
Technical access: Network traffic logs, SaaS application inventory from your SSO provider, browser extension data if you use endpoint management.
Stakeholder buy-in: Brief your legal and HR teams. You're going to ask employees direct questions about tool usage, and some will worry this is a "gotcha" exercise. Frame it as risk assessment, not enforcement.
Clear decision criteria: Define what makes an AI tool acceptable. Data residency requirements? SOC 2 attestation from the vendor? On-premises deployment option? Decide this before you start finding tools, or you'll make inconsistent decisions.
The Discovery and Assessment Template
Copy this into a spreadsheet or your GRC platform. Each row represents one AI tool you've discovered.
DISCOVERY FIELDS
─────────────────
Tool Name:
Primary Use Case:
Department/Team:
Number of Users:
Discovery Method: [Network logs | User survey | SSO audit | Expense report]
Data Classification Processed: [Public | Internal | Confidential | Restricted]
RISK ASSESSMENT
───────────────
Data Handling:
□ Processes customer PII
□ Processes payment data ([PCI DSS](https://www.pcisecuritystandards.org/) scope)
□ Processes health information
□ Stores conversation history
□ Allows data export
□ Vendor uses data for model training
Security Controls:
□ SSO integration available
□ MFA enforced
□ SOC 2 Type II report available
□ Data residency controls
□ Audit logging
□ API access for monitoring
Operational Risk:
□ Used for code generation
□ Used for decision automation
□ Used for customer-facing content
□ Used for compliance documentation
□ Integrated with production systems
DECISION FRAMEWORK
──────────────────
Risk Score: [Calculate: High=3, Medium=2, Low=1 for each checked box above]
Business Value: [Critical | High | Medium | Low]
Decision: [Approve with governance | Approve as-is | Migrate to approved alternative | Sunset]
Remediation Owner:
Deadline:
Policy Exception Required: [Yes | No]
GOVERNANCE REQUIREMENTS (if approved)
────────────────────────────────────
Required training:
Acceptable use restrictions:
Data handling requirements:
Monitoring requirements:
Review frequency:
Customizing the Template
Adjust risk categories for your industry: If you're in healthcare, add HIPAA-specific questions. Financial services? Add questions about model explainability and algorithmic bias. Manufacturing? Add questions about AI systems controlling physical processes.
Weight the risk factors: Not every checked box carries equal weight. In our template, we use simple counts, but you might score "Vendor uses data for model training" as a 5 while "Allows data export" is a 2.
Add compliance mapping: If you're working toward ISO 27001 certification, map each control requirement to your assessment criteria. For example, Annex A.5.23 (Information security for use of cloud services) applies to most SaaS AI tools.
Create department-specific versions: Sales teams evaluate AI tools differently than engineering teams. A sales-focused version might emphasize CRM integration and customer data handling, while an engineering version focuses on code generation risks and CI/CD pipeline integration.
Validation Steps
1. Cross-reference with network logs: Your survey will miss tools. Check egress traffic for common AI API endpoints (api.openai.com, api.anthropic.com, api.cohere.ai). If you see traffic but no survey responses, someone's hiding usage.
2. Test your decision framework: Run three discovered tools through your assessment. If all three get the same decision despite having different risk profiles, your criteria aren't granular enough.
3. Verify vendor claims: When a vendor claims SOC 2 Type II compliance, request the report. Check the audit period, the auditor, and whether it covers the specific service you're evaluating. We've seen vendors list SOC 2 certification for their main product while the AI feature runs on separate, unaudited infrastructure.
4. Pilot your governance requirements: Before you roll out governance for 15 different AI tools, pick one high-value tool and implement your full governance framework. You'll discover gaps. Maybe your "required training" is too generic, or your monitoring requirements assume API access the vendor doesn't provide.
5. Schedule your first review: Put a calendar reminder for 90 days out. Shadow AI doesn't stay discovered; new tools appear constantly. Your template should be a living process, not a one-time audit.
The goal isn't to eliminate shadow AI. It's to understand what your teams are using, why they're using it, and whether you can support that use case safely. Sometimes the answer is "approve it with guardrails." Sometimes it's "we have a better alternative." Rarely should it be "shut it down immediately" without understanding what problem employees were trying to solve.
