Audit finding: policy says one thing, operations do another

TL;DR — This finding usually means one of two things: your written policy is outdated, or your team is doing the work but cannot prove it with records. Start by comparing one policy statement to one real system setting or ticket trail, then either update the policy to match reality or change the system/process to match the policy. Reading time: ~6 min

The scenario

It is a Tuesday afternoon and your audit report lands in your inbox with a line that sounds simple but feels vague: "Policies do not align with observed practices." Your team swears you do monthly access reviews, backups are running, and production changes require approval — but the auditor says the screenshots, logs, or tickets do not support what the policy claims. Now leadership wants a response plan by end of day, and you need to work out whether the problem is the document, the system, or the missing evidence. You do not need to become a compliance expert; you need a repeatable way to compare what is written with what is actually happening.

Symptoms

• Audit report wording such as:

Policy states quarterly user access reviews are performed; no evidence was provided for the last two quarters.

• Or:

Observed password minimum length is 10 characters, while the policy requires 14.

• Or:

Change management policy requires documented approval before production deployment; sampled changes lacked approval records.

• Your admin dashboard shows a setting that conflicts with the policy text, for example:

MFA optional
Password length: 10
Retention: 30 days

• Tickets or change records exist, but they are inconsistent or missing required fields such as approver, date, or scope.
• Staff say things like "we changed that months ago" or "we do it in Slack, not in the ticket system."
• The auditor asks for evidence and the only available proof is a screenshot with no date, an exported CSV with no owner, or a verbal explanation.

Likely causes

Step-by-step diagnosis

1. Pick one exact audit finding, not the whole report. Copy the sentence into a working note.

   • Menu path: your document repository or audit portal → open the finding → copy the exact wording.
   • This is your problem if the finding contains a measurable claim like "quarterly", "14 characters", "all production changes", or "retain for 1 year".
   • Jump to the next step.

2. Find the source policy and highlight the exact requirement.

   • Menu path: document repository (for example SharePoint, Google Drive, Confluence, or your policy tool) → search the policy name from the finding → open the current approved version.
   • Look for words like "must", "all", "every", "quarterly", "within 24 hours", or a number.
   • This is your problem if the policy wording is broader or stricter than what your team actually does. Jump to Fixes → Policy document is outdated or Fixes → Scope is unclear.

3. Check the live setting or live workflow.

   • Dashboard path depends on the control:
     • Access/authentication: provider dashboard → Security or Authentication → Password policy / MFA.
     • Backups/retention: provider dashboard → Backups / Data retention.
     • Change approvals: ticket system → Changes / Requests → open the last 5 production changes.
   • This is your problem if the live setting clearly conflicts with the policy, such as policy says 14-character minimum and dashboard says 10. Jump to Fixes → System configuration does not meet the policy requirement.

4. Check whether you can prove the process happened.

   • Menu path: ticketing system or shared folder → search for the last 3 instances required by the policy.
   • Examples to search:

access review
production approval
restore test
vendor review

• This is your problem if the work happened but there is no dated record, no approver, or no retained export. Jump to Fixes → Process happens informally, but there is no retained evidence.

1. Check the scope against your system inventory.

   • Menu path: asset inventory / CMDB (configuration management database, your list of systems) / spreadsheet → compare the systems named in practice to the systems covered by the policy.
   • This is your problem if the policy says "all systems" but the inventory shows exceptions, acquisitions, test environments, or SaaS tools that are not included. Jump to Fixes → Scope is unclear.

2. Confirm there is only one current policy version.

   • Menu path: document repository → Version history or document properties.
   • This is your problem if teams are using different templates or an older version is still linked in onboarding docs or the wiki. Jump to Fixes → Different teams follow different versions.

[Audit Finding] ---- 1. read exact claim ----> [Policy Text]
      |                                         |
      | 2. compare                              | 3. compare
      v                                         v
[Live Setting/Workflow] ---- 4. collect proof -> [Evidence]
      |
      | 5. compare scope
      v
[System Inventory]

Fixes

Policy document is outdated and no longer matches current settings or workflow

If the team intentionally changed the process and leadership accepts the new approach, update the policy to match reality.

1. Edit the policy sentence so it is specific and true.
   • Example before:

All user accounts are reviewed quarterly across all systems.

• Example after:

User access for production systems and business-critical SaaS applications is reviewed quarterly by the system owner. Evidence is retained in the ticketing system for 1 year.

1. Route it through your normal approval path.
   • Menu path: document repository → policy page → Edit / Submit for approval.
2. Update linked procedures and templates in the same session so they do not drift again.

Verify it worked: the approved policy version, linked procedure, and actual process all say the same thing in plain language.

Process happens informally, but there is no retained evidence

If the work is happening but you cannot prove it, create a simple evidence trail in the system your team already uses.

1. Create a ticket template for the control.
   • In your ticketing system, add required fields: System, Date completed, Reviewer/Approver, Result, Evidence attachment.
2. For recurring controls, create a repeating task.
   • Example title:

Quarterly access review - Production systems

1. Attach exports or screenshots with dates visible.
2. If approvals happen in chat, move them into the ticket comment before closing.
   • Paste the approval text and name the approver.

Verify it worked: you can open the last 3 tickets and each one shows date, owner, outcome, and attachment without asking anyone to explain it.

System configuration does not meet the policy requirement

If the dashboard setting is weaker than the policy, change the setting or formally revise the policy if the requirement is no longer appropriate.

Examples of common fixes:

• Password policy
  • Dashboard path: provider dashboard → Security / Authentication → Password policy.
  • Set the minimum length to the value in policy, for example 14.
• MFA (multi-factor authentication, a second sign-in step)
  • Dashboard path: provider dashboard → Security / Authentication → Multi-factor authentication.
  • Change from Optional to Required for the in-scope users.
• Retention
  • Dashboard path: Backups / Data retention.
  • Set the retention period to the policy value.

If you do have infrastructure config in code, update the source of truth there too. Example:

{
  "password_policy": {
    "min_length": 14,
    "mfa_required": true
  }
}

⚠️ Changing authentication or retention settings can lock users out or increase storage costs. Apply the change during a planned window and notify affected users first.

Verify it worked: the live setting page now matches the exact number or requirement written in the policy.

Scope is unclear: policy says "all systems" but the team only applies it to production or a subset

Narrow or define the scope so the statement is testable.

1. Update the policy language from vague scope to named scope.
   • Example before:

All systems must have quarterly access reviews.

• Example after:

Quarterly access reviews apply to production systems, customer data stores, identity systems, and business-critical SaaS applications listed in the system inventory.

1. Add or update the inventory location in the policy.
   • Example:

The in-scope system inventory is maintained in the "System Inventory" sheet in the Governance folder.

1. Review the inventory and add missing systems.

Verify it worked: every system in scope can be pointed to in one inventory list, and every control references that same list.

Different teams follow different versions of the policy or template

Clean up the document source so there is one current version and old links stop causing drift.

1. In the document repository, mark the approved version as current.
2. Archive or clearly label older versions as superseded.
3. Replace links in onboarding docs, runbooks, and wiki pages.
4. If you use templates, delete old copies and publish one standard template.

Verify it worked: when two different team members search for the policy, they land on the same current version and the same template.

Prevention

1. Add a quarterly policy-to-config review checklist. For each key control, compare one policy statement to one live setting and save the result in a ticket.

Control: Password minimum length
Policy says: 14
Live setting says: 14
Checked by: Jane
Date: 2026-10-30

1. Put evidence fields into your change and review templates. Required fields should include owner, date, approver, and attachment before a ticket can be closed.

{
  "required_fields": ["owner", "completed_date", "approver", "evidence_attachment"]
}

1. Pin one document location as the source of truth. In your repository, keep one approved policy folder and move drafts elsewhere.

Governance/
  Policies/Current/
  Policies/Superseded/
  Procedures/
  Evidence/

1. Add a CI check for policy-controlled config where possible. If settings are stored in code, fail the review when values drift from the standard.

grep -R '"min_length": 14' . || echo "Password policy drift detected"

1. Tie policy scope to an inventory, not memory. Maintain one list of in-scope systems and review it after new vendors, acquisitions, or major launches.

system_name,owner,environment,in_scope_reason
identity-provider,IT,prod,authentication
customer-db,Engineering,prod,customer data
billing-saas,Finance,saas,business critical

1. Store auditor-ready evidence as you go. Do not wait for the audit request. For recurring controls, keep exports or screenshots in a dated folder.

Evidence/
  2026-Q1-access-review/
  2026-Q2-access-review/
  2026-Q3-access-review/

This article was written by an AI system and published pending human review. Verify anything you intend to act on.