Policy vs. Practice: Why Well-Written Policies Still Create Audit Findings

A security policy can be well written and technically sound, yet still create problems during an audit. The issue is usually not the quality of the prose. It is whether the policy describes what the organization does.

If your policy says access reviews happen twice a year, the auditor may look for evidence that those reviews occurred at that frequency. If the policy assigns the review to the CTO, but the security team actually performs it, that creates another inconsistency.

Good audit readiness therefore requires more than a complete policy library. Your policy, actual practice, and ownership need to tell the same story, supported by evidence that shows the process operated as described.

Why isn't a well-written policy enough for audit readiness?

A policy describes how your organization says a process should work. It doesn't, by itself, show that the process works that way in practice. That distinction matters during an audit.

Management-system auditing is evidence-based. ISO 19011:2026, the current ISO guidance for auditing management systems, addresses principles and methods for obtaining and evaluating audit evidence.

Other assessment methodologies make the same distinction in different ways. NIST SP 800-53A, for example, uses three assessment methods: examine, interview, and test. Those terms are specific to NIST methodology rather than a universal model for every audit, but they illustrate an important point: reviewing documentation is only one way to understand whether a control has been implemented.

Suppose a policy states: The CTO reviews privileged user access every six months.

That statement gives an auditor several things to check:

• Who performs the review?
• Does it happen every six months?
• What is included?
• Can the organization show that the reviews occurred?

A polished policy cannot answer those questions on its own.

This does not mean every discrepancy automatically produces a formal audit finding. Different frameworks use different criteria, testing approaches, and reporting terminology. But contradictions between documentation and operations can give the auditor a reason to investigate further.

That is why policy review should not stop at, "Does this document contain the right language?"

The better question is: Can we demonstrate that this is how we actually operate?

The GRSee Way

We don't just get you through your first audit—we set up sustainable processes and automation that make ongoing compliance manageable, so you can focus on growing your business instead of drowning in compliance tasks.

Contact Us

The three things auditors want to see aligned: Policy, practice, and ownership

A useful way to test audit readiness is to take an important control and compare three things:

Policy → Practice → Ownership

This is not a formal methodology prescribed by every compliance framework. It is a practical way to identify contradictions before an auditor finds them.

Policy: What have we committed to doing?

Start with what your organization has formally documented. Look for specific commitments around:

• Who performs an activity;
• How often it happens;
• Which systems or employees are covered;
• What approvals are required;
• What gets reviewed, tested, or documented.

Specificity can be useful, but it also creates commitments.

A policy that says "access will be reviewed regularly" may be too vague to guide an effective process. But writing "the CTO reviews all privileged access every six months" is only better if that is genuinely the process you intend and can operate.

Policies should describe a defensible process, not an idealized version of the company.

Practice: What actually happens?

Next, ask the operational owner to explain how the process works today.

Don't assume the policy is still accurate because someone approved it last year. Perhaps the business moved to a new identity platform. The review is now largely automated. Maybe the security team took ownership from IT. Perhaps a quarterly review was replaced with another monitoring process.

Those changes may be entirely reasonable. The problem appears when the organization changes but its documented control environment does not.

Then look at the evidence. If the organization says the activity happens, it should keep appropriate records to support that claim where evidence of operation is required.

Ownership: Who is responsible?

The third check is accountability.

The person named in the policy should either own the activity or the documentation should reflect whoever actually does. This is particularly important when controls cross Security, IT, Engineering, Legal, Privacy, or HR. A control can easily become "everyone's responsibility" without clear accountability.

The owner should also know what they own.

Discovering during an audit that someone is formally responsible for a process they have never heard of is a strong sign that the governance model and operating model have drifted apart.

What does a policy-to-practice mismatch look like?

Policy-to-practice gaps are often surprisingly ordinary. The control may exist, but some part of the documented story is no longer true. Consider three examples.

Access review ownership and frequency

A policy says the CTO performs the access review and the review happens every six months.

During the audit, the team explains that the CISO actually runs the review once a year.

The organization is performing an access review, but its evidence does not support the documented process.

The next step is not to automatically "change the policy."

First determine what the applicable requirements and organizational risk call for. If a six-month review remains appropriate and necessary, the process needs attention. If the real process has legitimately changed and remains sufficient, the documentation and responsibilities may need updating.

A SaaS change-management policy

Imagine a cloud-native SaaS company whose policy requires manual approval before every production deployment. Its engineering team, however, uses an automated CI/CD workflow.

Low-risk changes follow predefined controls and automated testing, while certain higher-risk changes require additional human approval.

The real process may be mature and defensible.

But if the policy still describes a workflow the company abandoned two years ago, an auditor comparing documentation with engineering practice sees two different control environments.

The fix is not to force engineering back into an outdated process merely because it appears in a document. It is to make sure the documented process and the actual control design accurately reflect one another.

An AI-generated development policy

A team asks a generative AI tool to write a secure software development policy based on common best practices. The result looks excellent. It includes formal threat modeling, several review stages, strict approval requirements, and recurring security testing.

One problem remains: the company doesn't actually do half of it. The policy has not improved compliance. It has created commitments the company now has to reconcile with reality.

This is becoming particularly relevant as creating sophisticated compliance documentation gets easier. The harder work is still implementation.

Why do policies drift away from actual practice?

Most policy drift doesn't come from one dramatic failure. Operations change faster than documentation.

A startup grows and divides one person's responsibilities across several teams. A company replaces its ticketing platform. Engineering changes deployment workflows. Security introduces a new access-management tool. A manual process becomes automated.

Each change can be reasonable. Over time, however, the policy may describe a company that no longer exists.

Templates can create the same problem from day one. A generic security policy may include sensible practices that don't fit the organization's size, architecture, staffing model, or risk profile.

AI can accelerate that problem. Generative AI is very good at producing plausible policy language based on familiar patterns. Plausible does not mean implemented.

That is why policy maintenance should involve the people who operate the controls. Compliance can coordinate the process, but Engineering, Security, IT, HR, Legal, and other owners need to verify that documented procedures still match their work.

A policy review that never leaves the GRC team is likely to miss operational drift.

How to run a policy-to-practice audit readiness check

You do not need to rewrite every document before each audit. Start with the controls and processes that matter most, then test whether the story holds together.

A simple alignment review can look like this:

For each selected control, follow five steps:

1. Read the documented requirement. Pull out specific owners, frequencies, scope, approvals, and deliverables.
2. Ask the operational owner to describe the real process. Ideally, get the explanation without simply having them recite the policy.
3. Compare the two. Identify differences in owner, frequency, workflow, scope, or tooling.
4. Inspect the evidence. Can you demonstrate that the process operated as described?
5. Resolve the mismatch. Update the control, documentation, ownership, evidence process, or a combination of these based on what the organization actually needs to do.

This exercise is more useful than polishing policy language immediately before fieldwork.

The goal is not to make the organization look perfect on paper. It is to ensure its documented control environment accurately reflects how it operates.