When CB Financial Services filed its Form 8-K with the SEC in May 2026, it wasn't due to a ransomware attack or network breach. An employee had uploaded customer data into an unauthorized AI tool. No attacker was involved. Yet, the four-day disclosure clock started ticking.
If your incident response plan assumes "breach" means "hacker," you're not ready for what's coming through your front door.
The Problem: Your Breach Definition Is Outdated
Shadow AI incidents don't fit the traditional cybersecurity playbook. There's no malware to contain, no compromised credentials to rotate, and no perimeter to secure. But when an employee uploads a spreadsheet with Social Security numbers and birth dates into an unapproved AI application, you've crossed the threshold for breach notification under most state laws.
The CB Financial incident exposed customer names, Social Security numbers, and birth dates. The company determined materiality within two days and filed its 8-K on day two of the four-business-day SEC deadline. This speed suggests they had a process ready, not one they invented during the crisis.
Your risk profile isn't shrinking just because federal regulatory changes might streamline some disclosure requirements. State breach laws still apply. Class-action attorneys still file lawsuits. If you're handling what one data protection officer calls "the crown jewels of identity theft," your notification obligations don't disappear just because no hacker was involved.
What You Need Before Starting
To respond effectively to shadow AI incidents, ensure these components are in place:
Stakeholder alignment on materiality criteria. Your disclosure committee must include security, legal, finance, communications, and business leaders. They need shared definitions for what constitutes material risk, not just operational impact. If you wait for the technical investigation to finish before convening this group, you'll miss your reporting windows.
Visibility into AI tool usage. You can't govern what you can't see. Deploy tools that identify API connections, monitor data egress patterns, and flag unauthorized cloud service usage. This is essential infrastructure now.
Approved AI alternatives. Employees use shadow tools because your approved options are slow, cumbersome, or nonexistent. If your governance strategy is "just say no," you're guaranteeing non-compliance.
Updated incident classification taxonomy. Your current categories probably include malware, phishing, insider threat, and DDoS. Add: unauthorized AI data upload, embedded AI feature activation without review, AI agent unauthorized database access, and open-source AI component vulnerability.
State breach law matrix. Document which states define breach as "unauthorized acquisition" versus "unauthorized access." Know which data types trigger mandatory notification. Some states let you skip notification if you determine the incident is unlikely to cause harm, but that determination must be documented and defensible.
Step-by-Step Implementation
Step 1: Map your current AI surface area (Week 1-2)
Run network traffic analysis to identify cloud AI services in use. Check SaaS application logs for newly activated AI features. Survey department heads about tools their teams are using. Don't announce this as a compliance crackdown; frame it as building an approved tools catalog.
Document what you find in a risk register: tool name, data access scope, business owner, approval status, risk rating.
Step 2: Build your materiality decision tree (Week 2-3)
Work with legal and finance to define materiality thresholds specific to AI incidents. Consider:
- Volume and sensitivity of exposed data
- Likelihood of downstream harm to data subjects
- Potential regulatory notification obligations across jurisdictions
- Expected litigation risk based on data types involved
- Reputational impact and customer notification costs
Create a decision flowchart your incident commander can follow at 2 a.m. Keep it to a one-page visual with yes/no branches.
Step 3: Integrate AI scenarios into incident response procedures (Week 3-4)
Update your Computer Security Incident Response Team playbooks to include shadow AI as a distinct incident category. Your containment steps will look different: you're not isolating infected systems, you're determining what data left your environment and where it went.
Add these response actions:
- Immediate suspension of employee access to the unauthorized tool
- Inventory of all data the employee uploaded or processed
- Contact with the AI service provider to request data deletion (document this request and any response)
- Legal review to determine if the tool's terms of service create additional exposure
- Assessment of whether other employees are using the same tool
Step 4: Define your approved AI tool stack (Week 4-6)
You need sanctioned alternatives before you can enforce a prohibition. Work with business units to understand their AI use cases. Evaluate tools that meet your security, privacy, and compliance requirements. Get them approved, procured, and documented.
Publish an internal catalog with clear guidance: "Need to summarize customer feedback? Use Tool X. Need to draft marketing copy? Use Tool Y. Anything else? Submit a request to the AI governance committee."
Step 5: Run a tabletop exercise with shadow AI scenarios (Week 6-7)
Test your new process before you need it. Create a realistic scenario: "A sales representative uploaded a customer list into an unapproved AI tool to generate personalized email templates. The list included names, email addresses, company names, and revenue figures. You discovered this when the rep asked IT for help accessing the tool's API. What happens in the next four hours? The next four days?"
Walk through your materiality determination. Practice your notification timeline. Identify gaps in your process.
Validation: How to Verify It Works
Your implementation is ready when you can answer yes to these questions:
Can your security team identify unauthorized AI tool usage within 24 hours of first use? Test this by having a trusted employee use an unapproved tool with non-sensitive test data. See how long it takes your monitoring to flag it.
Can your disclosure committee convene within four hours of incident discovery? Run a drill. Send the alert. See who shows up and how long it takes.
Can you document a materiality determination with supporting evidence? Practice this during your tabletop. Have legal draft the analysis they'd include in a filing.
Do employees know which AI tools are approved and how to request new ones? Survey a random sample. If fewer than 80% can name at least one approved tool and know where to find the full list, your communication failed.
Maintenance: Ongoing Tasks
Monthly: Review network logs for new AI service connections. Update your approved tools catalog as vendors add AI features to existing products. This is your embedded AI risk: the software you approved last year now includes capabilities you never assessed.
Quarterly: Retrain your disclosure committee on materiality criteria. As litigation patterns evolve and new state laws take effect, your thresholds will shift. Run a mini-tabletop with a new scenario each quarter.
Annually: Full incident response plan review incorporating lessons from real incidents (yours and industry peers). Update your state breach law matrix as legislatures pass new requirements.
Continuously: Employee education. Shadow AI emerges when people don't have approved tools that meet their needs. If you're seeing repeated violations, that's a signal your approved stack isn't working.
The CB Financial filing shows that shadow AI incidents will be disclosed, investigated, and potentially litigated. Your job isn't to prevent employees from ever using AI. It's to make sure that when they do, you can see it, assess it, and respond to it before you're racing against a four-day disclosure deadline with incomplete information.
Start building that capability now, while you still have time to test it.
