Documentation & SoA

Writing Information Security Policies That People Read

Alex Fuerst

23 Nov 2025 — 6 min read

The Evidence-Based Reality of Policy Effectiveness

During a recent certification audit at a tech startup, I asked the development team lead about their organization's Clean Desk Policy. "Oh yeah, we have that," he said, gesturing to the cluttered workspace around us—laptops open to client code, sticky notes with passwords visible, and confidential design documents scattered across multiple desks. When I asked if he'd read the policy, he admitted: "Honestly, I think I clicked 'acknowledge' during onboarding, but I couldn't tell you what it says."

This scenario plays out in audit after audit. Organizations invest significant resources developing comprehensive policy documentation that addresses every requirement in ISO 27001:2022 Clause 5.2 (Information security policy) and related Annex A controls, yet fail the most basic test: do people actually know what's expected of them?

The problem isn't that organizations write bad policies—it's that they write policies optimized for compliance theater rather than behavioral change. Your beautifully formatted, legally-vetted, comprehensively-detailed security manual becomes worthless when employees develop workarounds because the official guidance is too complex to follow in daily operations.

Why Traditional Policy Writing Fails the Audit Test

I've reviewed thousands of information security policies across industries, and the patterns are predictable. Organizations consistently optimize for the wrong audience—writing for auditors and legal teams rather than the people who must implement these requirements daily.

Consider Control 5.1 (Policies for information security) from ISO 27002:2022, which requires policies to be "communicated to and acknowledged by relevant personnel and relevant interested parties." The operative word here is "communicated"—not just distributed or acknowledged, but actually understood and internalized.

During a financial services audit, I encountered a perfect example of this disconnect. The organization had engaged a major consultancy to develop their ISMS documentation. The result was technically flawless: every control addressed, every responsibility mapped, every term precisely defined. Their Acceptable Use Policy alone ran 23 pages with 14 appendices covering everything from USB device management to social media guidelines.

But when I interviewed a customer service representative about suspicious email handling, she paused and said: "I know there's a policy somewhere, but honestly, I just ask Sarah—she used to work in IT and seems to know this stuff." This is compliance documentation existing in parallel to actual behavior, creating exactly the kind of gap that leads to nonconformities.

ISO 27001:2022 Clause 7.3 requires that persons doing work under the organization's control be aware of the information security policy and their contribution to ISMS effectiveness. Notice it specifies "aware"—not "have theoretically acknowledged." Awareness implies understanding, and understanding requires policies that people can actually absorb and apply.

Writing Policies That Survive the Implementation Test

Effective security policies share characteristics that prioritize human psychology over legal precision. Here's what separates policies that get used from those that get ignored:

Strategic Brevity Over Comprehensive Coverage

Every additional paragraph reduces the probability that someone reads the next one. This isn't about employee laziness—it's cognitive reality. Your staff process hundreds of communications daily. Your policy competes with urgent emails, system alerts, and actual work deliverables.

I worked with a manufacturing client that reduced their 34-page Information Security Policy to a focused 3-page document with hyperlinks to detailed procedures for those who needed deeper guidance. The result? Audit findings related to policy awareness dropped by 60% in their next surveillance audit, and employee interviews revealed significantly better understanding of key requirements.

The key is distinguishing between policy (what we do) and procedure (how we do it). Your core policy should establish principles and requirements that fit on a few pages. Detailed implementation guidance belongs in separate, role-specific documents.

Concrete Actions Over Abstract Principles

Consider these two approaches to Control 5.15 (Access control):

Traditional version: "Users shall not disclose authentication credentials to unauthorized parties or utilize shared accounts except where explicitly authorized by management."

Actionable version: "Never share your password with colleagues, even temporarily. Don't write passwords on sticky notes or save them in unencrypted files. If you need to grant someone access to a system, contact IT to set up their own account."

The second version gives employees specific behaviors they can immediately implement. It addresses real scenarios (the sticky note problem, temporary access requests) rather than abstract concepts that require interpretation.

Scenario-Based Guidance

Abstract statements like "maintain confidentiality of sensitive information" mean nothing without context. Employees don't think in categories—they think in situations. When writing policies that address Control 5.7 (Threat intelligence) or Control 5.23 (Information security in the use of cloud services), frame requirements around recognizable scenarios.

Instead of: "Personnel shall exercise appropriate caution when processing confidential information in public or semi-public environments."

Write: "Don't discuss client projects in coffee shops, trains, or elevators. Close your laptop screen when walking away from your desk. If someone can read your screen from behind you, they can probably see confidential information."

This approach helps employees recognize policy-relevant situations in real time, which is exactly what you need for effective implementation of controls like 5.8 (Information security in project management).

What Auditors Actually Look For

During certification and surveillance audits, I evaluate policy effectiveness through multiple evidence streams. Here's what I'm actually checking:

Employee interviews reveal genuine understanding. I don't just ask if people have read policies—I present scenarios and see if their responses align with documented requirements. Can the marketing coordinator explain what information she can share about upcoming product launches? Does the IT administrator know the approval process for emergency system access?

Consistency between stated policy and observed practice. If your Clean Desk Policy requires locked screens during absence, I'm noting whether screens are actually locked as I walk through the office. If your Control 8.9 (Configuration management) policy requires change approval, I'm sampling recent changes to verify the process was followed.

Evidence of regular communication and reinforcement. Effective organizations don't just distribute policies during onboarding—they reference them in team meetings, include reminders in newsletters, and use them as teaching moments when incidents occur. I look for evidence that policies are living documents, not static compliance artifacts.

Appropriate customization for different roles. One-size-fits-all policies typically fail because they're either too generic for anyone or too technical for most people. The best organizations I audit provide role-specific guidance that connects generic policy statements to specific job functions.

Common Policy Writing Mistakes That Create Audit Findings

Three patterns consistently create problems during audits:

The "Everything is Critical" Problem: When policies treat password complexity and incident response with equal urgency, employees can't prioritize effectively. I've seen organizations where the policy for printer usage received the same treatment as guidelines for handling personal data under Control 5.31 (Legal, statutory, regulatory and contractual requirements).

Disconnected Control Implementation: Policies that don't clearly connect to specific ISO 27002 controls create implementation gaps. For example, a "Data Protection Policy" that doesn't explicitly address Control 8.10 (Information deletion) or Control 8.11 (Data masking) leaves employees unclear about retention and disposal requirements.

Missing Cross-Standard Integration: Organizations in regulated industries often need policies that address multiple standards simultaneously. A cloud security policy should reference not just ISO 27001 controls but also relevant guidance from ISO 27017 (Cloud security controls) and potentially ISO 27018 (PII protection in cloud environments) where applicable.

Practical Implementation Framework

Based on successful implementations I've audited, here's a practical approach to policy development:

Start with risk context. Before writing any policy content, document the specific risks you're addressing and the controls you're implementing. This ensures your policy language directly supports your risk treatment decisions and provides clear traceability for auditors.

Map policies to job functions. Create role-specific policy summaries that extract relevant requirements for different employee groups. Your developers need detailed guidance on secure coding practices, while your sales team needs clear rules about information sharing with prospects.

Build in feedback loops. Include mechanisms for employees to ask questions and report difficulties following policies. I've audited organizations where policy review cycles included feedback from actual users, resulting in much more practical and followable guidance.

Test comprehension regularly. Beyond annual acknowledgment, implement periodic checks to verify understanding. This could be scenario-based questions in team meetings or brief surveys about specific policy areas.

Tip: When developing policies that address supplier relationships (Control 5.19 - Information security in supplier relationships), create separate guidance for procurement teams, project managers, and end users. Each group needs different levels of detail about the same underlying requirements.

Remember that effective policies serve two masters: they must satisfy audit requirements while actually influencing daily behavior. The organizations that excel at both understand that clarity and comprehensiveness aren't opposing forces—they're complementary aspects of mature information security management.

Policy writing isn't about impressing auditors with comprehensive coverage—it's about creating behavioral guidance that employees can follow consistently. When your policies achieve that balance, both compliance and security effectiveness improve naturally.

---

Need help developing policies that work in practice? Join our community of ISO 27001 practitioners at the IX ISO 27001 Info Hub for ongoing guidance and peer support, or reach out for consultation on policy development that passes both audit scrutiny and the real-world implementation test.

Need personalized guidance? Reach our team at ix@isegrim-x.com.