= $page_description ?>

AI FOR MANAGERS CERTIFICATION

AI Tools Assessment and Selection (Level 1) | AI Tools Assessment and Selection

LECTURE: AI Tool Security and Compliance Basics

Lesson 1.5.3 | Estimated Duration: ~22 minutes

Welcome to the AI for Managers certification program. I am your instructor, and today we are covering one of the essential lessons in the AI Tools Assessment and Selection module: AI Tool Security and Compliance Basics.

This is Lesson 1.5.3 in Level 1, the AI Awareness track. Whether you are joining us as a new manager evaluating tools for your team, a director building an AI procurement strategy, or a VP setting governance standards, the material in this session is designed to meet you where you are.

In our previous lessons, we covered how to evaluate AI tools and building evaluation frameworks. Today we focus on something equally critical: ensuring that any AI tool your team adopts is secure, compliant, and trustworthy.

Before we begin, let me set expectations. This is not a passive lecture on legal compliance or security policy. Rather, this is about how you as a manager can ask the right questions, understand the risks, and ensure your organization adopts AI tools responsibly. You will need to engage with your IT and legal teams, but you need to know what to ask.

So I encourage you to have a notepad ready and to jot down specific questions you can ask vendors and your security team.

Let us get started.

Lesson 1.5.3: AI Tool Security and Compliance Basics

Purpose

You have learned how to evaluate AI tools for capability and fit. Now you need to assess them for security and compliance—whether they meet your organization's data protection standards, regulatory requirements, and risk tolerance.

This lesson provides a practical framework for those conversations. It is the foundation for responsible AI tool adoption.

Why This Matters for Managers

A common mistake is assuming that because a tool is popular or widely adopted, it is secure and compliant. The truth is more nuanced. Widely-used tools have different security models, different data retention policies, and different compliance certifications. Your organization's requirements are specific to your industry, your location, and your data sensitivity.

The stakes include:

• Data security (are customer records protected?)
• Regulatory compliance (does this expose us to violations?)
• Liability (who is responsible if something goes wrong?)
• Team trust (do employees feel their data is protected?)
• Vendor dependency (are we locked in or exposed to price hikes?)

Your job is to ask the hard questions before adoption, not after a breach.

Key Security and Compliance Questions

DATA HANDLING AND STORAGE

Where is data stored?

• Is data stored on servers in your country, or overseas?
• Different regions have different legal standards (GDPR in EU, CCPA in California, etc.)
• Cloud providers may store data in multiple regions for redundancy
• Clarify whether the vendor stores data at rest and in transit

Does the vendor retain your data after use?

• Some AI tools retain your input to improve models (this is a privacy risk)
• Others delete data after a session (more secure)
• Ask explicitly: "Do you retain any of our data? For how long? For what purpose?"
• Get this in writing in the service agreement

Can you control where your data goes?

• Can you request data deletion?
• Can you request that your data not be used for model training?
• Can you audit where your data is stored?
• These should be part of the contract

Third-party access:

• Does the vendor share data with subcontractors?
• If yes, who? What are their security standards?
• If no, what happens if the vendor gets acquired?

ACCESS AND AUTHENTICATION

How is access controlled?

• Does the tool use strong passwords, multi-factor authentication (MFA), single sign-on (SSO)?
• Can you control who in your organization has access?
• Can you revoke access immediately when someone leaves?

Session management:

• How long before a user is automatically logged out?
• Can you set custom session timeouts?
• Are sessions encrypted?

ENCRYPTION AND DATA PROTECTION

Is data encrypted in transit?

• All communication should use HTTPS or equivalent
• Ask: "Is data encrypted between our team and your servers?"

Is data encrypted at rest?

• Even if data is stored on the vendor's servers, is it encrypted?
• Who controls the encryption keys? (You should want control, or at minimum transparency)

What happens in a breach?

• Does the vendor have breach insurance?
• What is their incident response plan?
• How quickly will they notify you if your data is compromised?
• Do they have penetration testing and security audits?

REGULATORY COMPLIANCE

Common regulatory frameworks:

GDPR (General Data Protection Regulation) - applies if you do business with EU customers or have EU employees

• Does the vendor comply with GDPR?
• Do you have a Data Processing Agreement (DPA) in place?
• Can users exercise the "right to be forgotten" (request data deletion)?

HIPAA (Health Insurance Portability and Accountability Act) - applies if you work in healthcare

• Is the tool HIPAA-compliant?
• Does the vendor sign a Business Associate Agreement (BAA)?
• Are they willing to document their security practices?

SOC 2 Type II - a security standard many vendors undergo

• Has the vendor completed a SOC 2 audit?
• Can they provide the report? (Request it during evaluation)
• What does it cover? (Authentication, encryption, uptime, audit trails?)

CCPA and similar state privacy laws - applies if you operate in California, Colorado, or other states

• Does the tool meet state-specific privacy requirements?
• Can you export user data upon request?

Industry-specific requirements:

• Finance: PCI DSS for payment processing
• Education: FERPA for student data
• Healthcare: HIPAA for medical records
• Verify what applies to YOUR organization

AUDIT TRAILS AND ACCOUNTABILITY

Can you audit who did what and when?

• Most enterprise AI tools provide audit logs
• You should be able to see: who accessed the tool, when, what they did, what data they viewed
• Audit trails are critical for regulatory compliance and investigating misuse

Are audit logs preserved and secure?

• Logs should be immutable (can't be deleted or changed)
• How long are they retained? (Usually 90 days to 7 years depending on regulation)
• Can you export them for compliance reviews?

INCIDENT RESPONSE AND TRANSPARENCY

How does the vendor respond to security incidents?

• Do they have a security incident response team?
• Will they notify you within 24 hours if your data is compromised?
• Will they provide forensic details (what happened, how, when)?

What is their transparency report?

• Reputable vendors publish annual security reports
• These detail breaches, security improvements, law enforcement requests
• Request and read these before signing

Vendor independence and security practices:

• Who is their security officer or CISO?
• Do they conduct regular penetration testing?
• Do they have a bug bounty program?
• Have there been any publicized breaches?

COMMON SECURITY MISCONCEPTIONS

Misconception 1: "Everyone uses it, so it must be secure."

Reality: Popularity does not equal security. Popular AI tools have different security models. They also have larger attack surfaces (more users = more attractive to attackers). Vet for YOUR organization's standards.

Misconception 2: "The vendor said it's GDPR-compliant, so we're good."

Reality: GDPR compliance is not binary. It depends on how you use the tool, how you configure it, and whether you have proper agreements in place. A vendor can be GDPR-capable, but you might use it in a non-compliant way. Work with your legal team.

Misconception 3: "We're a small company, so security doesn't matter."

Reality: Data breaches don't discriminate by company size. Attackers often target small companies because they assume weaker defenses. Standards and practices matter at any scale.

Misconception 4: "We signed the contract, so we're protected if something goes wrong."

Reality: Contracts allocate liability, but they don't prevent breaches. You are responsible for the data you handle. Choose vendors you trust, not vendors whose contract protects you after the fact.

WORKING WITH VENDORS ON SECURITY

Red flags:

• Vendor refuses to answer security questions
• Vendor claims they are "too small" to have security practices
• Vendor resists putting commitments in writing
• Vendor doesn't offer data protection or encryption
• No SLAs (Service Level Agreements) for uptime or incident response

Green flags:

• Vendor provides security documentation and certifications (SOC 2, ISO 27001, etc.)
• Vendor offers a Data Processing Agreement
• Vendor has a public security contact and incident response plan
• Vendor regularly updates their security practices
• Vendor allows audits or provides transparency reports

Contract essentials:

• Service Level Agreement (SLA): uptime guarantees (typically 99.5% to 99.99%)
• Data Processing Agreement (DPA): outlines how data is handled, especially under GDPR
• Breach notification clause: timeline for notifying you if your data is compromised
• Data deletion clause: what happens to your data if you cancel
• Encryption and security commitments: specific practices they will maintain

Creating a vendor security questionnaire:

Before evaluating a tool, create a standardized questionnaire. Examples:

1. Where is data stored? In which regions/countries?
2. Is data encrypted in transit and at rest?
3. Do you retain our data after sessions? If yes, for how long and why?
4. What compliance certifications do you hold? (SOC 2, ISO 27001, GDPR, HIPAA, etc.)
5. Do you have a Data Processing Agreement?
6. What is your incident response plan? Notification timeline?
7. Can we request data deletion?
8. How are access controls managed? Do you support MFA and SSO?
9. Can we audit who accessed our data and when?
10. Have there been any public security breaches?

Use this questionnaire consistently. Vendors should be able to answer clearly. If they cannot, that is a risk signal.

ANTI-PATTERNS

Anti-Pattern 1: Skipping Security Evaluation

"We're in a hurry to deploy this tool. We'll worry about security later."

Why it fails: Security breaches are expensive, disruptive, and damage trust. They are much harder to fix after deployment than before. By then, data is already flowing through the system.

Better: Build security evaluation into your adoption timeline from the start. It takes a week or two, not months.

Anti-Pattern 2: Delegating Security Entirely to IT

"IT will handle security, so I don't need to worry about it."

Why it fails: IT needs to vet the tool, but as the manager, you are accountable for how your team uses it. You need to understand the risks and communicate them to your team.

Better: Work with IT to vet the tool. Understand the constraints they identify. Communicate those to your team and ensure they follow them.

Anti-Pattern 3: Assuming Compliance is the Vendor's Responsibility

"The vendor said they're compliant, so we're compliant."

Why it fails: Compliance is a shared responsibility. The vendor provides a compliant tool, but YOU determine whether you use it in a compliant way. Inputting sensitive data (customer records, health information) into a consumer tool is YOUR decision and YOUR risk.

Better: Understand what compliance means for your organization. Work with your legal team. Use the vendor's tool in a compliant way.

PRACTICE PROMPTS

1. Vendor Evaluation: You are considering adopting an AI tool for your team. Create a short security questionnaire (5-10 questions) that you would ask the vendor. What is most important for YOUR organization's industry and data sensitivity?
2. Risk Assessment: Think about the data your team handles. If that data were exposed, what would be the impact? Regulatory violations? Customer trust? This informs how strict your security evaluation should be.
3. Conversation with IT: Schedule a brief conversation with your IT or security team. Ask: "What are the non-negotiables for any AI tool we adopt? What certifications or agreements do we require?" Document their answer.
4. Compliance Checklist: Identify the regulatory frameworks that apply to your organization (GDPR, HIPAA, CCPA, PCI DSS, FERPA, or others). For each, research what an AI tool would need to comply. Create a compliance checklist for future evaluations.

KEY TAKEAWAYS

1. Data security is not optional. Where data is stored, how it is encrypted, and who has access are foundational questions. Get answers in writing.
2. Regulatory compliance is mandatory in many industries. Understand which frameworks apply to your organization and ensure vendor agreements cover them.
3. Audit trails and incident response are non-negotiables. You need to know who accessed what, and vendors need to notify you of breaches quickly.
4. Security evaluation takes time but is faster than recovering from a breach. Build it into your adoption timeline from the start.
5. Security is a shared responsibility. The vendor provides a secure tool, but you decide how to use it responsibly. Communicate security expectations to your team.

GLOSSARY

Encryption: The process of encoding data so that only authorized parties can read it. Data should be encrypted in transit (moving between your team and the vendor's servers) and at rest (stored on the vendor's servers).

GDPR (General Data Protection Regulation): A European Union regulation on data protection and privacy. Applies to organizations that do business with EU customers or have EU employees. Requires strong data protection practices and gives individuals the right to request their data.

SOC 2: A security auditing standard. SOC 2 Type II means the vendor has been independently audited for security controls over a period of time (typically 6 months or more).

SLA (Service Level Agreement): A contract commitment about uptime and performance. Example: "We guarantee 99.9% uptime, which means no more than 43 minutes of downtime per month."

Audit Trail: A record of who did what and when. Critical for compliance and investigating misuse.

[SYNTHESIS AND APPLICATION]

Let us step back and look at the bigger picture of what we have covered in this session on AI Tool Security and Compliance Basics.

Many managers approach security as a checkbox: "We need SOC 2? Check. GDPR-compliant? Check. Moving on." But security is not a checkbox. It is an ongoing conversation between you, your team, your IT department, and your vendors.

Here is what I want you to take away from this session:

First, the framework. You now have a mental model for security and compliance. You know what questions to ask and why they matter. You understand the difference between a vendor's security capability and your organization's responsible use of that capability.

Second, the practical next steps. This week, I want you to do two things: (1) Identify what regulatory frameworks apply to YOUR organization. (2) Schedule a brief conversation with your IT or security team to understand their non-negotiables for AI tool adoption.

Third, the accountability dimension. You are not responsible for being a security expert. But you ARE responsible for ensuring that your team uses AI tools responsibly. That means asking vendors the right questions, working with IT, and communicating expectations to your team.

[REFLECTION EXERCISE]

Before we close, I would like you to spend two minutes on this reflection:

Think about the data your team handles right now. Where does it come from? Who should have access? What would happen if it were exposed? Write down your answer. This informs how strict your security evaluation should be.

Next, identify one AI tool you are considering or currently using. What would you need to know about it to feel confident it is secure? Write down those questions. Those become your vendor questionnaire.

[CLOSING REMARKS]

In our next lesson, we will explore Building a Team AI Tool Evaluation Framework, which brings together everything we have covered on capability, fit, and security. I encourage you to complete the reflection exercises before moving on.

This has been Lesson 1.5.3: AI Tool Security and Compliance Basics, part of the AI Tools Assessment and Selection module in Level 1: AI Awareness of the AI for Managers certification.

Remember: the goal is not to be a security expert. The goal is to be an informed, responsible manager who asks the right questions and ensures your team adopts AI tools that are both powerful and trustworthy.

Thank you for your time, your attention, and your commitment to responsible AI adoption in your organization.

END OF TRANSCRIPT

A SkillsClinic initiative by No Worker Left Behind and The Work Company.