Overview

Your company is scaling. You now have 200 employees. You're being asked to formalize security policies for the first time. You need documentation for: password management, data classification, access control, incident response, and acceptable use. These are foundational documents that compliance auditors will review. They're also lengthy and complex.

Your security team could spend weeks drafting policies from scratch (researching frameworks like NIST and CIS, adapting them to your company, writing in clear language). Or you could use AI to generate initial drafts, NIST-compliant, aligned with industry standards, written in policy language, and then have your security team review and customize them.

This lesson teaches you how to use AI for security policy documentation, why human expert review is non-negotiable, and how to avoid the mistake of publishing AI-generated policies without vetting.

Purpose

Security policy documentation serves multiple purposes:

• Compliance framework: Policies articulate how your organization implements compliance requirements (ISO 27001, SOC 2, NIST, PCI DSS, etc.)
  - Risk mitigation: Policies document the controls you've implemented to reduce specific risks (data exfiltration, unauthorized access, malware infection)
  - Audit evidence: When regulators or auditors ask "Do you have a password policy?" you produce documentation proving you do
  - Employee guidance: Policies communicate to staff what the security rules are and why they exist
  - Incident response: During security incidents, policies clarify what was violated, what the impact is, and what the response should be

Manual policy documentation is labor-intensive. Security teams often copy templates, adapt them (sometimes poorly), and end up with policies that either don't fit their organization or don't align with frameworks.

AI can generate initial drafts quickly, mapping to compliance frameworks and industry standards. This compresses the initial drafting phase, freeing experts to focus on customization and vetting.

Why This Matters

Regulatory requirements are real: Most organizations face compliance requirements (HIPAA for healthcare, PCI-DSS for payments, GDPR for EU operations, SOC 2 for SaaS). Regulators require documented policies. Policies without documentation = non-compliance = fines or audit failures.

Bad policies are risky: A password policy that's too weak (8 characters, no special characters) puts you at risk. A policy that's too strict (32-character passwords, change every 30 days) causes people to write passwords on sticky notes. Bad policies increase risk more than no policies.

Framework alignment matters: NIST has detailed guidance on what a "good" access control policy includes. CIS has benchmark controls. Copying NIST language directly sometimes works, but adapting it to your organization is necessary.

Policies must be maintained: A policy written in 2015 that says "We use this vendor for identity management" is stale if you switched vendors in 2022. Maintenance is ongoing.

Audit eats time: During SOC 2 audits or security assessments, auditors ask "Show me your policy for X." If you don't have documented policies, you fail the audit. If policies are vague or don't address audit requirements, you fail. Documented, clear, framework-aligned policies accelerate audits.

Core Concepts

Key insight: AI drafts frameworks, experts customize

AI can generate a NIST-compliant password policy in seconds:

All user passwords must be minimum 12 characters, contain uppercase, lowercase, numbers, and special characters. Passwords must not be reused within 12 previous instances. Passwords must be changed every 90 days.

This is framework-aligned (maps to NIST standards). It's also generic and might not fit your organization. Your security team must customize:

• Is 12 characters right for your organization, or should it be 10 or 14?
  - Do you have password managers that make the "special character" requirement less necessary?
  - Is 90-day rotation the right interval for your industry?
  - Do you have technical controls (SSO, conditional access) that make manual password management less critical?

AI generates a starting point. Experts validate and customize.

Key insight: Policy language matters

A policy written as:

"Employees must not download unapproved software."

Is vague. Does Firefox count? What about VS Code? What's "unapproved"?

A policy written as:

"Employees may install software only from the approved software catalog or with prior approval from IT Security. Unapproved installations will be detected by MDM (Mobile Device Management) tools and the application will be remotely removed. Exceptions: IT and security teams may install software for testing with written approval."

Is specific, explains the mechanism, and clarifies exceptions.

AI sometimes produces generic policies. Customization includes making them specific to your environment.

Key insight: Compliance frameworks are starting points, not outcomes

A NIST-aligned access control policy says "Implement role-based access control." NIST also lists what RBAC should include (clearly defined roles, regular access reviews, principle of least privilege).

But NIST doesn't tell you if you should have 10 roles or 100 roles. NIST doesn't tell you how often to review access (quarterly, annually). Customization requires your expertise.

AI can generate the NIST-aligned framework. You customize it based on your organization.

Key insight: Policies are only effective if people actually follow them

A policy that's 50 pages long, written in legal language, and incomprehensible to employees is worthless. People won't follow it because they don't understand it.

A policy that's 3 pages, written in clear language, and explains "why," generates buy-in and compliance.

AI can generate comprehensive policies. Customization includes making them readable and understandable to non-security staff.

Key insight: Policy maintenance is continuous

A policy written today will be stale in 2 years. Security threats evolve. Compliance requirements change. Your organization changes (new vendors, new products, organizational restructuring).

Effective policy documentation includes a review and update schedule. "This policy is reviewed annually and updated if threats change or regulations change."

Key insight: Sensitive details don't belong in policies

Policies are often read by employees, contractors, and auditors. Some details are operational security sensitive:

• Specific tools you use (naming it in policy constrains your flexibility)
  - Internal security controls (might signal to attackers how to evade)
  - Threat scenarios (might give attackers ideas)

Policies should articulate "what" and "why," not always "how." "We implement multi-factor authentication" is a policy. "We use Okta for MFA and challenge users via text message" is operational detail that shouldn't be in a general policy.

Practical Use Cases

Use Case 1: Initial Policy Drafting (Before/After)

Before AI:

• Security team spends 2 weeks researching NIST, CIS, and industry standards
• Senior security engineer manually drafts password policy, access control policy, data classification policy, incident response policy: 40 hours
• Policies are 50+ pages combined
• Draft review with stakeholders: 10 hours
• Multiple revision cycles (policies too strict, too vague, compliance gaps): 20 hours
• Final policies: 8 weeks from start to approval
• Cost: ~$8,000 in engineer time + overhead

After AI:

• Security team defines policy requirements: "We need NIST-aligned policies for password management, access control, and incident response. Our company has 200 employees, uses cloud infrastructure (AWS), and targets SOC 2 compliance."
• Prompt to AI: "Generate a NIST-aligned password policy for a mid-size SaaS company. Include: requirements, exceptions, responsibilities, enforcement mechanism, and maintenance schedule. Include mappings to NIST controls."
• AI generates draft in 2 minutes
• Security team reviews draft: "Good starting point. We don't use password managers company-wide, so special character requirement is reasonable. 12-character minimum is appropriate. 90-day rotation is fine. We need to add requirement for MFA on critical accounts."
• Team edits the draft, adding MFA requirement and customizing for their context
• Review with stakeholders: 3 hours (faster because draft is already framework-aligned and well-written)
• Minimal revisions needed (draft was good enough)
• Final policies: 2 weeks from start to approval
• Cost: ~$2,000 in engineer time + overhead
• Additional benefit: Policies are framework-aligned from the start; audit alignment is easier

Use Case 2: Compliance Framework Mapping (Before/After)

Before AI:

• You're preparing for SOC 2 audit
• Auditors ask: "Map your security policies to SOC 2 requirements"
• You have policies, but they're not organized by SOC 2 criteria
• Mapping requires manually aligning policy content to SOC 2 criteria: 20+ hours
• Result: A matrix showing which policy addresses which criterion
• Often incomplete (some criteria are not clearly addressed by existing policies)

After AI:

• You have security policies documented
• Prompt to AI: "I have the following security policies: [list or paste policies]. Map each policy to the SOC 2 Criteria (Trust Service Criteria). Which policy addresses which criterion? Are there any gaps (SOC 2 criteria not addressed by existing policies)?"
• AI produces a matrix within seconds, identifying:
• Which policies address which SOC 2 criteria
• What criteria are fully addressed vs. partially vs. not addressed
• Suggested additions to fill gaps
• Review with compliance team: "This mapping looks mostly right, but [criterion X] is not fully addressed by the access control policy. We need to add a policy on periodic access reviews."
• You add a policy for access reviews
• Re-run the mapping to confirm all criteria are addressed
• Result: Complete SOC 2 mapping in 1 week (vs. 3 weeks manual mapping)
• Additional benefit: Identified policy gaps before audit (time to address them proactively)

Use Case 3: Policy Customization for Specific Role (Before/After)

Before AI:

• You have a general acceptable use policy for all employees
• IT leadership asks: "Do contractors and third-party vendors follow the same policy, or do they need something different?"
• You don't have a contractor-specific policy
• Option 1: Use the same policy (might be too restrictive or not restrictive enough)
• Option 2: Manually create a contractor policy: 15 hours
• You choose Option 2 and spend time creating a contractor policy

After AI:

• You have a general acceptable use policy
• Prompt to AI: "Generate a contractor acceptable use policy. Our standard policy is: [paste policy]. A contractor policy should be similar but may have additional restrictions (access only to assigned resources, no access to internal communications) and different consequences (contract termination vs. employee termination). Generate a contractor variant that is consistent with our employee policy but adapted for contractors."
• AI generates draft in 2 minutes
• Review with legal and security: "Good. Add requirement that contractors cannot use their own personal devices (corporate devices only). Add requirement for background checks. Add requirement that contractors sign the policy when contract begins."
• You edit the draft
• Result: Contractor policy created and approved in 1 week (vs. 2 weeks of manual creation)

Examples

Example 1: Policy Draft Generated by AI (Password Management)

Prompt:

Generate a password management policy for a mid-size SaaS company (200 employees).

Requirements:
- Map to NIST guidelines (SP 800-63)
- Include exceptions for service accounts
- Include enforcement mechanisms
- Include employee responsibilities
- Include rate of change guidance (how often to update the policy)

Company context:
- Uses cloud infrastructure (AWS)
- Uses identity provider (Okta)
- No company-wide password manager
- Mostly non-technical employees (but some developers/engineers)
- Target: SOC 2 Type II compliance

Output: Policy document, suitable for internal distribution and audit purposes.

AI Output:

PASSWORD MANAGEMENT POLICY
Last Updated: 2026-04-09
Next Review: 2027-04-09

1. PURPOSE
   This policy establishes password management requirements to protect organizational assets from unauthorized access. Passwords are a critical component of information security and must be managed in accordance with NIST SP 800-63 standards.
2. SCOPE
   This policy applies to all employees, contractors, and third-party users who access organizational systems. Exceptions are documented in Section 5.
3. PASSWORD REQUIREMENTS
   3.1 Minimum Length: All user passwords must be a minimum of 12 characters.
   3.2 Complexity: Passwords must contain at least three of the following four character types:
   - Uppercase letters (A-Z)
   - Lowercase letters (a-z)
   - Numbers (0-9)
   - Special characters (!@#$%^&*)

3.3 Password Age: Passwords must be changed every 90 days. The system will enforce this requirement via automated reminders at days 60, 75, and 89.

3.4 Password History: Passwords must not be reused within 12 previous instances (users cannot reuse a password until they have created 12 new passwords).

3.5 Account Lockout: After five failed login attempts within 15 minutes, the account is automatically locked for 30 minutes.

1. PASSWORD MANAGEMENT PRACTICES
   4.1 Password Storage: Employees must not store passwords in plaintext documents, browsers, or shared locations. Passwords should be:
   - Memorized (preferred)
   - Stored in a personal password manager (personal responsibility; no company endorsement)
   - For shared accounts (not recommended), encrypted using approved methods

4.2 Multi-Factor Authentication (MFA): MFA is required for all users accessing:
- Administrative accounts
- Systems containing sensitive data
- VPN and remote access
- Email systems for users with elevated privileges

4.3 Password Sharing: Passwords must never be shared, including:
- Via email or messaging
- Written on physical documents
- Verbally communicated
Exception: Authorized account delegation via Okta (documented and audited)

1. EXCEPTIONS
   5.1 Service Accounts: Database credentials, API keys, and service account passwords follow different requirements:
   - Minimum 32 characters
   - Random generation (not user-created)
   - Stored securely in secrets management system (HashiCorp Vault)
   - Rotated every 30 days
   - Multi-user accounts strictly prohibited; service accounts must be user-specific for audit trails

5.2 Legacy Systems: Systems that do not support complexity requirements or aging must be approved by IT Security with documented risk mitigation controls.

1. USER RESPONSIBILITIES
   - Create strong, unique passwords for all accounts
   - Never share passwords or write them down
   - Report suspected compromised passwords immediately to IT Security
   - Enable MFA for all accounts where available
   - Update passwords upon prompting by the system
2. ADMINISTRATION RESPONSIBILITIES
   - Enforce password requirements via directory service (Okta)
   - Monitor password compliance via automated reporting
   - Disable accounts or reset passwords when employees leave
   - Maintain audit logs of password changes and failed login attempts
   - Notify users of password requirements during onboarding
3. ENFORCEMENT
   - Password non-compliance: Initial warning + IT Security consultation. Repeat violations may result in account suspension or disciplinary action (per employee handbook).
   - Password sharing incidents: Investigation, password reset, and possible security training requirement.
   - Severe violations (intentional password sharing for unauthorized access): Disciplinary action up to termination.
4. RELATED POLICIES
   - Acceptable Use Policy
   - Access Control Policy
   - Incident Response Policy
5. MAPPING TO NIST SP 800-63
   - Requirement 3.1-3.3 map to NIST IA-5 (Authentication and Identification)
   - Requirement 4.1-4.3 map to NIST SC-28 (Protection of Information at Rest)
   - Requirement 5 map to NIST IA-2 (User Identification and Authentication)
6. MAINTENANCE
   This policy is reviewed annually. Changes to password requirements, technology, or threat landscape may trigger updates outside the review schedule. Updates are communicated to all affected users within 14 days of policy change.

(Ready for use, specific to your organization, framework-aligned)

Example 2: Policy Customization for Different Audience

Original (General):

Employees must not access systems containing sensitive data without authorization.

Contractor variant:

Contractors must not access systems containing sensitive data. Access to systems is limited to those systems explicitly required to perform contracted work. All access must be requested by the hiring manager and approved by the Chief Security Officer. Contractors who access systems containing sensitive data in violation of this policy are subject to immediate contract termination and referral to legal.

IT Team variant:

IT staff must follow the principle of least privilege. When access to sensitive data is required for support or operational reasons, IT staff must: (1) Log and document the reason for access, (2) Use role-based temporary elevation rather than standing access, (3) Ensure access is time-limited (hours, not days), (4) Submit access logs for periodic review by the Chief Security Officer.

(Same concept, different details for different roles)

Anti-Patterns

Anti-Pattern 1: Publishing AI-generated policies without expert review

What happens:

AI generates policy. You like it. You publish it.
Auditors ask: "How does this policy prevent data exfiltration?"
You realize the policy says "No exfiltration" but doesn't explain controls that prevent it.
Policy is vague and fails audit.

Why it fails: AI generates text that reads like a policy but may lack critical details, context, or enforcement mechanisms. Expert review catches these gaps.

Fix: Every AI-generated policy must be reviewed by someone with security expertise. A checklist: Does the policy map to compliance requirements? Does it explain enforcement? Does it address known risks? Does it fit our organization?

Anti-Pattern 2: Policies that are too strict or too vague

What happens:

Case 1 (Too Strict): "Employees cannot use personal devices ever."

Reality: Employees use personal phones for 2FA. Policy makes this illegal. Unenforceable.

Case 2 (Too Vague): "Employees must protect sensitive data."

Reality: Does this mean encryption? Physical security? Who is "employees"? What is "sensitive"?

Why it fails: Unenforceable policies breed non-compliance. Vague policies create audit gaps.

Fix: Policies must be specific enough to enforce and vague enough to adapt. "Employees may use personal devices to receive MFA codes via text message. Personal devices may not store work documents or credentials." Specific, clear, enforceable.

Anti-Pattern 3: Policies that never change

What happens:

Policy written in 2018 says: "All file storage is on corporate shared drives."
In 2023, company migrated to cloud (OneDrive, SharePoint).
Policy is stale but not updated.
Auditors ask: "Where do you store data?"
You have to explain that your policy doesn't match your actual practice.

Why it fails: Stale policies create audit findings. They also cause confusion (which rule actually applies?).

Fix: Build a maintenance schedule into policies: "This policy is reviewed quarterly and updated if technology or threats change." Actually follow it.

Anti-Pattern 4: Policies that don't address known risks

What happens:

You document a password policy but don't document data classification.
Employees don't know what data is sensitive.
They treat everything as public (because the policy doesn't say otherwise).
Sensitive data is exposed.

Why it fails: Policies without comprehensive risk coverage leave gaps. Employees don't know how to protect what they don't know is sensitive.

Fix: Map policies to risks. "Here's our risk: Data exfiltration. Our policies that address this: [Data Classification, Access Control, Incident Response, Acceptable Use]. Are we missing any?"

Anti-Pattern 5: Policies that don't explain "why"

What happens:

Policy: "All passwords must be changed every 90 days."
Employee thinks: "This is annoying. I'll write my password down so I don't forget the new one."
You've increased risk instead of decreasing it.

Why it fails: Without context, people resist compliance. With context, they understand the point.

Fix: Explain why. "We require password changes every 90 days because if a password is compromised, the compromise window is limited to 90 days before it changes automatically. This reduces the risk of prolonged unauthorized access."

Human Judgment Checkpoints

Before publishing AI-generated security policies:

• 
  Compliance fit: Does the policy map to your compliance requirements (NIST, CIS, SOC 2, etc.)? If you're targeting SOC 2, does it address the relevant criterion?
• 
  Organization fit: Does the policy fit your organization's size, structure, and technology? (A policy written for 1,000-employee enterprises might not fit a 50-person startup.)
• 
  Enforcement mechanism: How is this policy enforced? Who is responsible for verification? What happens if someone violates it? If enforcement is unclear, the policy is unenforceable.
• 
  Specificity: Is the policy specific enough to enforce, but vague enough to evolve? (Too specific: names specific products. Too vague: "must protect data.")
• 
  Risk coverage: Does this policy address a real risk? Is there a vulnerability without this policy? If not, is it worth the complexity?
• 
  Maintenance plan: When and how will this policy be reviewed and updated? Without a maintenance plan, it will become stale.

Key Takeaways

• 
  AI drafts frameworks, experts customize. Use AI to generate compliant initial drafts. Use security expertise to customize for your organization, clarify ambiguities, and validate enforcement mechanisms.
• 
  Expert review is non-negotiable. Security policies are critical. They must be reviewed by someone with security expertise before publication. Check: Does it address known risks? Is it enforceable? Does it map to compliance requirements?
• 
  Policies need explanation. A policy that says "do this" generates resistance. A policy that explains "do this because [risk]" generates compliance. Include "why" in policy language.
• 
  Maintain policies continuously. A policy written once and never updated becomes stale and misleading. Build a review schedule (quarterly, annually) into policy maintenance.
• 
  Map policies to risks and compliance. Document the relationship: "Risk: Data exfiltration. Policies addressing this: [list]." "SOC 2 Criterion: A1.1. Policies addressing this: [list]." This helps during audits and clarifies coverage.
• 
  Make policies specific but flexible. Avoid naming specific products in policies (limits flexibility if you switch vendors). Make policies specific enough to enforce (what exactly is required) but flexible enough to evolve with technology.
• 
  Document exceptions clearly. Some systems or users need different rules. Document why exceptions exist and what controls replace the standard policy.
• 
  Review with stakeholders. Policies affect employees, contractors, and IT operations. Get input from all stakeholders during review. A policy that IT can't enforce or that employees can't understand will fail.