“Reasonable security” is a legal standard, not a technical checklist. It describes the baseline level of effort that regulators, state breach laws, cyber insurers, and enterprise customers expect an organization to show, scaled to its size, its resources, and the sensitivity of the data at risk. For shadow AI, the unsanctioned chatbots, copilots, and AI browser extensions employees adopt without review, meeting that standard means you can produce evidence that you looked for the exposure, classified what it touches, set a usable policy, and kept checking, at a pace a 50 to 500 person company with no dedicated security team can actually sustain. It does not mean zero shadow AI use or a flawless inventory. It means you can show a deliberate, maintained, size-appropriate program the next time someone asks: an insurer renewing a policy, an enterprise customer’s security questionnaire, or a regulator after an incident.
Working through this in production? See how we run a fixed-fee AI and LLM security assessment.
“Reasonable security” is a legal term, and it already applies to AI
The phrase comes from enforcement and litigation, not an engineering standard. The Federal Trade Commission (FTC) brings most of its data security cases under Section 5 of the FTC Act, which bars unfair or deceptive practices, and its small-business guide, Start with Security, condenses more than fifty enforcement actions into one message: make reasonable choices based on the nature of your business and the sensitivity of the data you hold. The FTC has never published a fixed checklist defining “reasonable.” In its case against Wyndham Worldwide, the agency pointed to voluntary guidance, including standards from the National Institute of Standards and Technology (NIST), as evidence of what a reasonable company would have done.
Want to put this into practice? Use our free Shadow AI Inventory Quiz.
State law sharpens the test. California’s breach statute, Civil Code Section 1798.150, gives consumers a private right of action when a business’s failure to maintain reasonable security procedures and practices leads to a breach of categories like Social Security numbers or medical information, and the statute does not define “reasonable” either. Sector rules close the loop with the same scaled language: the FTC Safeguards Rule at 16 CFR Part 314 requires safeguards appropriate to a covered institution’s size and complexity, and the HIPAA Security Rule’s required risk analysis at 45 CFR 164.308(a)(1)(ii)(A) applies the same test to health care entities and business associates.
None of these rules were written with generative AI in mind, and none carve it out either. A customer record pasted into a public chatbot is still a security incident under whatever reasonable-security obligation already covers your data, and “we didn’t know employees were doing that” is itself evidence of a program that was not reasonable for the organization’s size.
Why shadow AI is where “reasonable” gets tested first
Shadow AI is any AI tool in active use that never went through review, and it grows faster than any policy cycle because AI capability now ships inside tools people already have. A free browser extension, a “summarize this” button bolted onto a SaaS product your team already pays for, or a developer’s personal API key wired into a script, none of that requires a purchase order or an IT ticket. That is why, when an incident or an insurance renewal asks what AI you use and what it touches, shadow AI is usually the question a 50 to 500 person company cannot answer, and the gap is the first thing a reviewer finds.
The discovery work does not change with company size. It runs across a handful of channels: network and DNS egress logs, single sign-on and OAuth grant records, expense reports, and a short no-blame employee survey to catch what the logs miss. Our companion piece on building a real AI inventory walks through those channels for a larger regulated enterprise; the method scales down cleanly, and the finding usually does not shrink. A 120-person company that has never looked typically turns up AI tools in payroll, legal, sales, and engineering within the first week.
The five-factor reasonable security self-score
No statute scores this for you, so here is a practical rubric built from what the sources above actually test for: whether you looked, whether you know what the AI touches, whether you wrote anything down, and whether any of it survives past the first quarter. Score each factor 0 (not there), 1 (informal or undocumented), or 2 (documented, current, and owned by a named person).
| Factor | What a “0” looks like | What a “2” looks like |
|---|---|---|
| Discovery | No one has looked; IT assumes the approved tool list is the whole picture | A documented pass across network, SSO, and expense channels in the last two quarters, with a named owner |
| Data classification | Unknown what data types reach each AI tool in use | Each discovered tool mapped to the data classes it touches: customer records, health information, financial data, source code |
| Written policy | No AI acceptable-use guidance exists anywhere | A one-page policy naming approved tools, prohibited data types, and an exception path, read and acknowledged by staff |
| Intake for new tools | AI tools get added on personal cards or personal API keys with no review | New AI tool requests route through a short intake before access or payment is approved |
| Monitoring cadence | Discovery happened once, as a one-off project | Re-discovery is scheduled at a fixed interval, tied to the same named owner as the first factor |
Sum the five scores. Zero to three means the exposure is real and undocumented, the position a plaintiff’s expert or an underwriter would call unreasonable for your size. Four to six means a program exists but would not survive a close look. Seven to ten is a defensible, size-appropriate “reasonable security” position: not flawless, but evidenced, current, and owned.
Where NIST’s AI framework helps, and where it stops
The NIST AI Risk Management Framework (NIST AI 100-1), published January 26, 2023, is the most widely cited voluntary reference for this work. It organizes AI risk management under four functions, GOVERN, MAP, MEASURE, and MANAGE, a different structure from the six Functions (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER) in NIST Cybersecurity Framework (CSF) 2.0 for general cyber risk; the two frameworks are companions, not substitutes, and conflating them in a policy document is a common, avoidable mistake. NIST’s Generative AI Profile (NIST AI 600-1), published July 2024, extends the base framework with risks specific to generative tools, including the data leakage and unmanaged third-party exposure that shadow AI creates.
Adopting the AI RMF is voluntary and not a legal safe harbor: no statute says that following it guarantees compliance or blocks a claim. What it provides is a credible, third-party reference to point to when a regulator or insurer asks what standard you measured yourself against. GOVERN and MAP, naming an owner and mapping where AI touches your data, map most directly to the five-factor score above.
What to do this month, with no security team
- Run one discovery pass this month: pull SSO and OAuth grant logs and check expense reports for AI subscriptions. Do not wait for a perfect tool.
- Write the one-page policy before you buy anything. Name the tools you approve, the data types that may never go into an AI tool (customer records, health information, credentials, source code, anything under an NDA), and who to ask for an exception.
- Classify what you find, not what you assume. A tool used only for marketing copy is a different risk than one employees are pasting client files into.
- Put a date on the next discovery pass before closing this one out; a one-time program is not one a reviewer will credit as reasonable.
- If you handle health information or sit under the FTC Safeguards Rule, route the finding into whatever risk assessment you already maintain; shadow AI is a new source of old obligations.
Where DSE’s AI security work fits, and where it does not
Discovery and policy work like this is governance and readiness advisory, not a penetration test. If you are actually worried about an AI application, chatbot, or agent your team built and shipped, that is a different, scoped engagement: hands-on adversarial testing of the model, retrieval layer, and tool integrations, fixed-fee and fixed-scope. What DSE does not do, in either case, is operate a 24/7 security operations center, provide managed detection and response, or perform live digital forensics after a breach. Penetration testing at DSE is scoped to LLM applications, external network and web applications, and cloud configuration and identity; internal network and assumed-breach testing fall outside that scope. DSE also does not certify, attest, or guarantee any outcome; a reasonable-security position is argued with your counsel, not declared by an advisor.
Questions buyers ask
Does “reasonable security” mean we need to certify our AI program? No. Certification and attestation come from accredited bodies, auditors, and standards organizations, not from a self-assessment or an advisory engagement. “Reasonable” is a liability and diligence standard: what a court, regulator, insurer, or enterprise customer would expect given your size and resources. DSE prepares organizations to show that evidence; it does not certify or guarantee any legal, insurance, or audit outcome.
Do we need to ban AI tools like public chatbots to be reasonable? No, and an outright ban with no approved alternative usually pushes the behavior further underground, onto personal devices with no visibility at all. A reasonable program names approved tools and the data they may touch, rather than relying on a prohibition nobody enforces.
How is this different from a SOC 2 or ISO 27001 audit? It is a different kind of proof. SOC 2 is an American Institute of Certified Public Accountants (AICPA) attestation report issued by a licensed CPA firm, and ISO/IEC 27001:2022 is a certification issued by an accredited certification body; both examine a defined control set against a fixed standard. “Reasonable security” has no fixed standard or issuing body, and it is argued case by case against what a similarly sized peer would have done. A company can hold a clean SOC 2 report and still lose a reasonableness argument over a control the audit never tested, such as AI tool use.
What should a 50 to 500 person company spend money on first? Discovery and a one-page policy, before any monitoring tool. Those two steps are the cheapest and they produce the evidence a regulator, insurer, or customer questionnaire actually asks for. Detection tooling and governance software are reasonable second and third purchases once you know what you are governing.
Does cyber insurance cover a shadow AI data leak? That depends on the policy language and the facts of the incident, and it is a question for your broker and counsel, not a security vendor. What insurers increasingly ask at renewal is simpler: whether an organization has any AI use policy and inventory at all. Having one, even a simple one, is evidence of the reasonable-security position an insurer is underwriting against.
What this guide is / What it is not
What it is: A practitioner explanation of the “reasonable security” legal standard as applied to unsanctioned AI tool use, anchored to FTC Section 5 enforcement, California Civil Code Section 1798.150, the FTC Safeguards Rule at 16 CFR Part 314, the HIPAA Security Rule at 45 CFR 164.308(a)(1)(ii)(A), and the NIST AI Risk Management Framework (NIST AI 100-1, 2023) and its Generative AI Profile (NIST AI 600-1, 2024). What it is not: Legal advice, an audit, a certification, or a guarantee of any compliance, insurance, or litigation outcome. DSE prepares organizations for review and does not certify them, run a security operations center, or perform live digital forensics. Consult qualified counsel on how these rules apply to your organization.
The Bottom Line
“Reasonable” is not a technical bar, it is an evidence bar, and shadow AI is where most 50 to 500 person companies fail it first because no one has looked, let alone written anything down. The fix is cheap relative to the exposure: one discovery pass, one page of policy, a data map of what the AI touches, and a date on the calendar for the next pass. Score yourself against the five factors above before an insurer, a customer questionnaire, or a regulator does it for you.
Atlanta and Georgia companies that want a scored starting point before a conversation can begin with the fractional CISO readiness check for Atlanta and Georgia small businesses.
Key facts
- The NIST AI Risk Management Framework (NIST AI 100-1), published January 26, 2023, organizes AI risk work under four functions, GOVERN, MAP, MEASURE, and MANAGE, distinct from NIST Cybersecurity Framework (CSF) 2.0's six Functions for general cybersecurity (NIST, 2023).
- California Civil Code Section 1798.150 gives consumers a private right of action over a breach of specific personal information categories caused by a business's failure to maintain reasonable security procedures and practices, a standard the statute itself leaves undefined (Cal. Civ. Code, current 2026).