Step 1: Identify needs and triggers

Most policy projects start with a trigger. Common triggers include:

• A new law or regulation (for example, updates to privacy rules or new AI obligations). [eur-lex.europa.eu], [Law & Regu...ncy (CPPA)]
• A security incident, audit finding, or litigation event that reveals gaps.
• A technology rollout (cloud migration, new collaboration platform, enterprise AI assistant).
• Business expansion (new geography, acquisition, new product line).

Begin by writing a short “policy problem statement” that describes the risk or inefficiency you are trying to reduce and who is affected. Then confirm the scope: which business units, repositories, and data types are in scope now, and what will be addressed later.

Step 2: Map stakeholders and decision rights

Policies succeed when the right people help shape them. Identify stakeholders using a simple map:

• Business owners (who rely on the information to do work)
• Legal and compliance (who interpret laws, contracts, and litigation risk)
• Privacy (who focuses on personal data rights and appropriate processing)
• Security/IT (who can implement controls, logging, and monitoring)
• Records/Information management (who manages retention, disposition, and defensibility)
• Risk/Audit (who tests controls and reports findings)

Define decision rights early. For example: the IG steering committee approves enterprise-wide policy; business units may approve local procedures that do not conflict with enterprise policy; the CISO approves security standards. Documenting these rights reduces later conflict.

Step 3: Gather requirements and current-state evidence

Policy drafting should be grounded in evidence. Collect:

• Applicable legal and regulatory requirements (privacy, sector rules, retention mandates). [Law & Regu...ncy (CPPA)], [sec.gov], [hhs.gov]
• Contracts and third-party obligations (data processing terms, confidentiality clauses).
• Current workflows and pain points (where people struggle, where they bypass controls).
• Existing policies that overlap (acceptable use, incident response, vendor management).

A practical technique is to run short interviews or workshops around real scenarios: “A staff member wants to paste customer data into an AI tool; what should happen?” “A team wants to keep chat messages forever; should they?” These scenarios reveal where policy needs to be precise.

Step 4: Draft in plain language and structure for usability

Students often imagine policies as long legal documents. In reality, the best policies are concise, structured, and written for the people who must follow them.

Use a consistent structure:

• Purpose (why the policy exists)
• Scope (who and what it applies to)
• Definitions (only what readers truly need)
• Policy statements (the rules: “must,” “must not,” “may”)
• Roles and responsibilities (who does what)
• Exceptions (how to request, approve, and log exceptions)
• Enforcement (consequences, monitoring, audits)
• References (related standards, procedures, laws)

Write rules as testable statements. “Employees should be careful” is not testable. “Do not store Restricted data in personal cloud accounts” is testable.

Step 5: Review for feasibility, risk, and conflicts

Policy review is where many drafts fail. A policy may be legally sound but impossible to follow. Review the draft with:

• IT/Security for technical feasibility (can we enforce this in systems?)
• Business teams for workflow impact (does this block core work?)
• Legal/Privacy for compliance and defensibility (does it meet obligations?)
• Audit/Risk for measurability (can we test compliance?)

Resolve conflicts explicitly. If a policy requires encryption everywhere but a legacy system cannot encrypt, decide whether to migrate, isolate, or create a time-bound exception.

Step 6: Approve through a formal governance path

Approval should match policy impact. A department procedure may be approved by a director, but enterprise policy should be approved by an executive sponsor or steering committee. ARMA emphasizes accountability: a senior executive should oversee the recordkeeping program and ensure auditability. Formal approval creates legitimacy and signals that the policy is not optional. [armavi.org], [arma.org]

Step 7: Communicate, train, and operationalize

A policy that is not communicated is not real. Plan for:

• A launch message from leadership explaining “why now.”
• Role-based training (different content for employees, managers, IT admins, and developers).
• Job aids: quick reference guides, decision trees, and examples.
• Tool changes: labels, default settings, templates, automated prompts.

Step 8: Maintain and improve (policy lifecycle management)

Policies must stay current. Establish:

• A review cycle (often annually; faster for AI and security topics).
• Change triggers (new law, new platform, major incident).
• Version control and an accessible policy library.
• Metrics and audit results feeding into revisions.

NIST’s AI RMF Playbook emphasizes that governance is ongoing and should be adapted to context rather than treated as a one-time checklist. That same mindset applies to IG policies. [airc.nist.gov], [digitalgov...enthub.org]

Figure 6.1 Policy Development Lifecycle illustrating the end‑to‑end stages of effective policy creation, approval, implementation, monitoring, and revision within an information governance program.

Data classification policy

A data classification policy assigns sensitivity levels to information and links each level to required handling controls (storage, sharing, encryption, access approval, and disposal). Classification supports many downstream controls: data loss prevention (DLP), access reviews, retention rules, and incident response triage.

A common approach uses 3–5 levels. Keep names intuitive and aligned with real risk:

• Public: approved for public release.
• Internal: business information not intended for public distribution.
• Confidential: sensitive business data (contracts, HR records, nonpublic financials).
• Restricted: highly sensitive data (customer PII, health data, credentials, trade secrets).

Good classification policies include examples and default rules (for example, “When in doubt, classify as Confidential”). They also specify who can change labels and how classification should be embedded into tools (email banners, document headers, labels in content management systems).

Retention and disposition policy

Retention policies define how long information must be kept and when it should be securely disposed. Retention is not “keep everything forever.” Over-retention increases legal exposure (more data to search and produce) and security exposure (more data to breach). Under-retention creates operational and legal risk (loss of evidence, failure to meet statutory requirements).

A retention policy typically includes:

• Ownership of retention schedules (often Records/IM with Legal)
• Legal hold authority and process (holds override disposal)
• Approved destruction methods (including vendor requirements)
• Documentation (disposition logs and approvals)

ARMA’s Principles emphasize retention and disposition as core hallmarks of effective governance, reinforcing that policies should support consistent, auditable lifecycle decisions. [armavi.org], [arma.org]

Acceptable use and collaboration policy

Acceptable use policies (AUPs) define what employees may do with organizational systems and information. Modern AUPs should explicitly cover collaboration platforms (shared drives, chat, project boards) and mobile work.

In 2026, AUPs increasingly include rules about:

• Approved storage locations (no sensitive files in personal accounts)
• Sharing permissions (external sharing rules, guest accounts)
• Password and identity practices (including phishing-resistant options where available)
• Use of personal devices (BYOD) and minimum security requirements

A good AUP is short and supported by “how-to” guidance that teaches safe behaviors rather than listing only prohibitions.

AI use (AI acceptable use) policy

AI use policies are now a standard IG requirement because AI tools can copy, transform, and redistribute information quickly. A practical AI acceptable use policy distinguishes between:

• Approved AI tools (enterprise AI assistants, vetted vendors)
• Prohibited AI tools (unsanctioned services or plugins that lack controls)
• Approved data types for AI (for example, public or internal-only)
• Prohibited data types for AI (restricted personal data, PHI, credentials, trade secrets)

The EU AI Act establishes requirements for high-risk AI systems, including data governance, record-keeping/logging, transparency, human oversight, and cybersecurity, which should influence policy requirements even for organizations outside the EU if they operate globally. NIST’s AI RMF promotes a risk-based approach with governance structures and documentation practices that translate well into internal AI policies. IAPP research in 2025 found many organizations working on AI governance and building programs incrementally, often leveraging existing privacy and governance capabilities—suggesting that AI policy is becoming part of mainstream governance rather than a niche topic. [eur-lex.europa.eu], [artificial...enceact.eu] [airc.nist.gov], [digitalgov...enthub.org] [iapp.org]

A strong AI use policy also addresses outputs:

• When AI-generated content must be reviewed and approved before external use
• How to label AI-generated content where required or appropriate
• How to store prompts and outputs when they are business records

Incident response and breach notification policy

Incident response policies define how the organization detects, triages, escalates, and communicates security and privacy incidents. They connect IG to operational resilience by ensuring that the right information is available during crisis response.

For public companies, SEC rules require disclosures regarding cybersecurity risk management and material incident reporting, reinforcing that incident response processes must be documented, board-visible, and integrated with disclosure controls. In health care, HIPAA rules emphasize administrative, physical, and technical safeguards for electronic protected health information (ePHI), and breach notification rules require defined response practices. [sec.gov] [hhs.gov]

Third-party data handling and AI vendor policy

Third parties are often where governance breaks down. A third-party data handling policy defines requirements for vendors and partners, such as:

• Data minimization (share only what is necessary)
• Security controls (encryption, access control, logging)
• Subprocessor and supply-chain disclosure
• Data location and cross-border transfer conditions
• Incident notification timelines
• Return or destruction of data at contract end

In 2026, this policy should also cover AI vendors and integrations (plugins, APIs, connectors). The AI supply chain can include model providers, platform providers, and tool vendors, and each may process or store information. Policies should require documentation of what data is used, how it is retained, and how outputs are logged.

Policy template: enterprise IG policy (one-page skeleton)

Table 6.1. A reusable structure for most IG policies.

Data classification example table (to embed in a policy)

Table 6.2. Example classification scheme linking labels to controls.

AI acceptable use policy outline (practical template)

Table 6.3. AI acceptable use policy outline aligned with risk-based governance expectations.

Enforcement checklist (for policy rollout)

Table 6.4. A practical enforcement checklist you can apply to any IG policy.

Training and awareness

Training is the most visible enforcement mechanism, but it is only effective when it is role-based and scenario-driven. Consider four tiers:

• All staff: classification basics, safe sharing, AI do’s and don’ts, reporting incidents.
• Managers: approval responsibilities, exception handling, coaching.
• High-risk roles (HR, finance, health, customer support): handling Restricted data, retention and legal holds, AI decision safeguards.
• IT/security and developers: implementing controls, logging, secure configuration, AI model onboarding gates.

Use microlearning: short modules with examples. Reinforce training with “just-in-time” prompts in tools (for example, a reminder when someone tries to share a Restricted file externally).

Monitoring and technical controls

Modern enforcement depends on automation. Common technical controls include:

• Information protection labels that apply encryption and restrictions.
• DLP rules that detect sensitive data leaving approved locations.
• Identity and access management (least privilege, periodic access reviews).
• Audit logging for access, sharing, AI tool use, and administrative changes.

Addressing the "Air Gap": Technical enforcement in 2026 must also address the risks created by copy-paste behaviors. While a policy may prohibit uploading a document to an unvetted LLM, it is often harder to detect when an employee copies a single paragraph of Restricted data into a prompt. Modern enforcement, therefore, relies on Endpoint Data Loss Prevention (EDLP) that can trigger a "Just-in-Time" warning if sensitive patterns are detected in a clipboard buffer before they are pasted into a non-corporate browser window.

When building monitoring, prioritize high-risk behaviors (external sharing, public links, copying data into unsanctioned tools) rather than trying to monitor everything.

A useful design rule is “enforce at the point of action.” If a user can still share a Restricted file with “Anyone with the link,” the policy is not really enforced. If the platform blocks that option by default and requires an exception workflow, the policy becomes part of daily work. Similarly, if employees can install unapproved AI browser extensions without visibility, the AI policy will be ignored. Mature enforcement therefore includes configuration baselines (what settings must be true in each platform) and a control owner who tests those baselines after every major platform update.

Audits and continuous testing

Audits are how you prove policies are working. Effective audits combine:

• Control testing (are labels and access controls configured correctly?)
• Behavior testing (are people following the rules?)
• Evidence checks (are logs, approvals, and exception records maintained?)

For AI governance, NIST’s AI RMF Playbook provides example actions and outcomes that can be translated into audit questions (e.g., documentation, monitoring, and governance oversight). [airc.nist.gov], [digitalgov...enthub.org]

Disciplinary actions and accountability

Discipline should be predictable and proportional. Many organizations use a progressive model:

1. Coaching and retraining
2. Written warning
3. Loss of privileges or reassignment
4. Termination or contract action (for severe or repeated violations)

Accountability also includes leadership reporting. For example, if a business unit repeatedly violates sharing rules, the steering committee should review metrics and require corrective action.

Incentives and culture

Enforcement is easier when policy aligns with culture. Consider positive incentives:

• Recognize teams that improve classification coverage or reduce risky storage.
• Make compliance the default in tools so doing the right thing is easier than doing the wrong thing.

A practical mapping approach

Use a “policy-to-law crosswalk.” For each major law or regulation, identify:

• The information types covered (personal data, health data, security incidents)
• Required controls (transparency, access, retention limits, security safeguards)
• Evidence expectations (documentation, logs, assessments)
• Who owns compliance (privacy, security, legal)

Also define the organization’s policy hierarchy so it can handle overlapping rules. A common hierarchy is: (1) enterprise IG policies (broad rules), (2) domain policies (privacy, security, AI, records), (3) standards (technical requirements), and (4) procedures (step-by-step workflows). When conflicts occur, the higher-level policy sets the principle and the standard sets the implementation. For example, a privacy policy may state “limit collection and retention,” while the retention standard specifies schedules and disposal approvals. This hierarchy matters because regulators and auditors look for internal consistency.

Key legal domains

Policy-to-law integration table

Table 6.5. Example crosswalk between IG policy areas and common regulatory drivers.

Resistance to change

People resist policies when they feel like obstacles. Reduce resistance by:

• Explaining the “why” with real consequences (breach costs, fines, reputational harm)
• Involving users early in drafting and testing
• Making compliant behavior the default in tools

A useful communication tactic is to translate policy into “three rules to remember” for each audience. For example, for most employees: (1) label your files, (2) keep Restricted data in approved locations, (3) never paste Restricted data into nonapproved AI tools. For managers: add “approve exceptions and coach behavior.” This helps policies compete with daily workload.

Over-complex policies

Complexity is a common failure. Symptoms include 30-page policies, too many exceptions, and inconsistent language. Solutions:

• Use a layered approach: short policy, detailed standards, role-specific procedures
• Use examples and decision trees
• Review policies for readability and testability

Another practical method is a “policy usability test.” Give the draft to five people who represent the target audience. Ask them to answer three scenario questions using only the policy. If they cannot find the answer quickly, rewrite the policy, add examples, or move details into a procedure.

Enforcement gaps

Policies often fail because enforcement is not resourced. Solutions:

• Assign owners for each control (training, DLP, audits)
• Create a metrics dashboard (training completion, label coverage, risky sharing trends)
• Fund automation where possible

Treat enforcement as a control system: each policy statement should map to at least one control and one evidence source. If the policy says “Restricted data must be encrypted at rest,” the controls might be “encryption enabled in the repository” and “device encryption enforced,” and the evidence might be configuration reports and audit logs. This mapping prevents “paper compliance.”

Keeping policies current

AI tools and privacy rules change quickly. Solutions:

• Establish policy lifecycle governance with a clear review cadence
• Track external changes (regulatory updates, new guidance)
• Use modular policies so you can update one section without rewriting everything

IAPP’s 2025 AI governance report notes that organizations often build AI governance incrementally and need skills to translate legislative requirements into actionable policies. This supports a practical approach: start with clear minimum rules and expand as capability grows. [iapp.org]

Example 1 (hypothetical): Rolling out an enterprise AI acceptable use policy

A global consulting firm adopts an enterprise AI assistant. Early pilots reveal employees pasting client data into external tools. The IG team drafts an AI acceptable use policy with three risk tiers: “public,” “internal,” and “restricted.” Restricted data is prohibited in prompts unless a specific approved tool supports encryption, logging, and contractual controls. The firm integrates the policy into tools by blocking uploads of Restricted data to nonapproved domains and by displaying prompts that remind users of allowed data types. Quarterly audits review prompt logs in approved tools and investigate exceptions.

This approach aligns with risk-based governance expectations emphasized by NIST AI RMF resources and EU AI Act requirements for documentation and oversight in high-risk contexts. [airc.nist.gov], [eur-lex.europa.eu]

Example 2 (hypothetical failure case): A retention policy that no one can follow

A manufacturing company publishes a detailed retention schedule but does not configure retention labels in its collaboration platform. Employees keep creating shared folders with inconsistent naming and no ownership. After litigation, the company spends months searching unmanaged locations and cannot prove consistent disposal practices.

The fix is not rewriting the policy. The fix is operationalizing it: define repository owners, enable automated labels, require disposition approvals, and keep disposition logs. This illustrates a common lesson: policy must be paired with controls and evidence.

Example 3 (realistic composite): Health system strengthens third-party data handling

A health system experiences a vendor-related incident involving a billing contractor. In response, it updates third-party handling policies to require business associate agreements, minimum security controls, and strict incident notification timelines. It also updates access controls so vendors receive least-privilege access and all access is logged. The policy references HIPAA Security Rule safeguard expectations and ties vendor controls to periodic audits. [hhs.gov]

Example 4 (realistic composite): Public company integrates IG with SEC disclosure readiness

A mid-cap public company updates its incident response policy to align with SEC cybersecurity disclosure requirements. The policy clarifies who determines materiality, how information flows to disclosure counsel, and how evidence is preserved. The company runs tabletop exercises and maintains documentation so that, if an incident occurs, it can meet the required reporting timelines and provide consistent governance disclosures. [sec.gov]