Most policy libraries fail in the same moment: when an auditor asks, “show me which version applied on that date, who approved it, who it applied to, who acknowledged it, and how you know it changed behavior.”
Policy management that auditors can test and trust is not about having more documents. It is about building audit and control into the policy lifecycle so you can demonstrate, with evidence, that policies are current, understood, and operating in the business.
This guide focuses on practical moves that work for France and Spain, especially when you need to satisfy expectations under loi Sapin II (and AFA audits), ISO 37001, and Spain’s UNE 19601 and UNE 19603.
What “auditors can test and trust” means in practice
Auditors (internal audit, certification bodies, external reviewers, sometimes regulators) typically test policy management through four lenses.
1) validity and version control
They want to confirm that employees could only reasonably rely on the current version, and that old versions are controlled (archived, traceable, not still circulating in shared drives).
2) governance and accountability
They want clear ownership: who drafts, who reviews (legal, compliance, HR, operations), who approves, and who is accountable for periodic review.
3) applicability and accessibility
They want to see that the policy reached the right population (including new joiners), in the right language (France/Spain reality), and that it is findable.
4) effectiveness signals
They want more than “policy published.” They look for evidence that the policy is embedded into controls, training, monitoring, investigations, and remediation.
For reference texts, you can start with the legal requirement itself for France (Article 17 of loi Sapin II on anti-corruption measures) via Légifrance, and for ISO programs, ISO 37001 at the official ISO overview page.
Step 1: establish policy governance that matches your audit reality
In mid-caps and large groups, policy work fails when it is “everyone’s job,” meaning no one is accountable. Create a simple governance model that can be explained in one slide.
A common pattern that auditors understand:
- a policy oversight committee (sets priorities, resolves conflicts, approves the meta-policy)
- policy owners (accountable for content and review cadence)
- a policy manager or document control administrator (runs the workflow, enforces formatting, maintains the system of record)
- legal and compliance reviewers (validate legal and regulatory alignment)
- operational stakeholders (confirm feasibility and integration into processes)
A simple RACI you can reuse
activity | responsible | accountable | consulted | informed |
|---|---|---|---|---|
policy inventory and taxonomy | policy manager | head of compliance | IT, HR, internal audit | leadership |
drafting (policy + procedure links) | policy owner | business line leader | compliance, legal, HR | impacted teams |
review for legal/regulatory alignment | legal | general counsel | compliance, DPO (if relevant) | policy owner |
approval and publication | policy oversight committee | executive sponsor | internal audit (optional) | all employees (as applicable) |
distribution and attestation | policy manager | head of compliance | HR, IT | managers |
periodic review and refresh | policy owner | business line leader | compliance, legal | policy manager |
exception handling and enforcement routing | compliance | head of compliance | HR, legal | leadership (as needed) |
Keep the committee small. Auditors usually prefer consistent governance over perfect representation.
Step 2: write a “policy on policies” (the meta-policy)
A meta-policy is one of the fastest ways to improve auditability because it defines the rules of your policy lifecycle. It is also easy to test.
Your meta-policy should define:
- what counts as a policy vs a procedure vs a guideline
- mandatory document fields (owner, approver, effective date, next review date, version)
- standard approval workflow and escalation if reviewers miss deadlines
- translation rules (when required, who approves translations, how you ensure parity)
- publication rules (single source of truth, removal of obsolete versions)
- mandatory evidence to retain (approvals, attestations, training records, exception logs)
- review cadence rules (minimum annual for high-risk topics is common, but justify based on risk)
If you work under anti-corruption frameworks, ensure the meta-policy aligns with the expectation that compliance measures are implemented and monitored, not just drafted (AFA publishes practical guidance on Sapin II controls and evaluation on its site: Agence française anticorruption).
Step 3: design a policy lifecycle that produces an audit trail by default
Auditors love consistency. The easiest way to build trust is to apply the same lifecycle to every policy, with proportionate depth.
Lifecycle evidence map (use this as your audit script)
lifecycle stage | what auditors typically test | minimum evidence to retain |
|---|---|---|
research and drafting | policy is based on actual risks and operations | draft history, sources used (risk map reference, incidents, regulatory inputs), stakeholder list |
review and approval | appropriate reviewers approved the final text | approval workflow record, legal review sign-off (where required), final version file hash or controlled PDF |
publication and communication | employees could access the current version | publication timestamp, access path, comms message, role-based assignment logic |
attestation (if applicable) | acknowledgements are complete and traceable | attestation report (by population), exceptions list, reminders log |
training (if applicable) | learning was delivered and measured proportionately | training assignment list, completion records, quiz results or scenario attendance |
monitoring and enforcement | violations are handled, policy is not “dead” | incident linkage, investigation outcomes, disciplinary routing rules, remediation actions |
review and update or retirement | policy is refreshed on schedule and old versions controlled | review meeting note, version history, archive location, depublication evidence |
This single table often becomes your internal audit work program.
Step 4: make policies testable (not just readable)
Most policies are written as statements of intent. Auditors test whether they can be turned into controls.
The “testability” checklist for each policy
Use this checklist during drafting and again before approval.
- scope: does it clearly state which entities, roles, and third parties it covers (France, Spain, subsidiaries, JV staff, contractors)?
- definitions: are key terms defined (gift, public official, competitor contact, facilitation payment, conflict of interest)?
- mandatory vs optional: is the required behavior explicit (avoid vague “should” unless you mean it)?
- process hooks: does the policy point to procedures, tools, and registers (for example, approvals, registers, reporting channels)?
- control points: are there at least one or two measurable controls (approval required above threshold, four-eyes review, restricted clauses, pre-clearance)?
- records: does it state what evidence is created and where it is kept (register, approval log, due diligence file)?
- exceptions: does it define who can grant exceptions and how they are documented?
- consequences: is enforcement described in a defensible way (without turning the policy into an unintended contract)?
A policy template that supports audits
You can standardize to one page for the policy and push details into procedures.
section | what to write | what it enables auditors to test |
|---|---|---|
purpose | why this policy exists, linked to your risk map | risk-based rationale |
scope | who and what it covers (including countries) | population coverage |
rules | 5 to 10 clear “do/don’t” statements | behavioral expectations |
required steps | link to procedure(s) and forms | process existence |
approvals and thresholds | when pre-approval is required | control design |
records to keep | what register or proof is created | evidence trail |
speak-up and questions | how to report, who to ask | operational use |
version and governance | owner, approver, dates | version control |
If you operate under UNE 19601 or UNE 19603, the same structure works well because both standards are built around documented governance, operational controls, and evidence of effectiveness (see UNE’s standards catalog via UNE and certification resources via AENOR).
Step 5: build a decision tree for updates, retirements, and urgent changes
One reason auditors lose trust is when policies stay unchanged while the business changes. Make updates predictable.
Decision table (easy to apply, easy to show)
trigger | typical decision | evidence to keep |
|---|---|---|
new law, regulator guidance, certification finding | update policy (fast-track if needed) | change request, legal note, updated version, comms |
repeated incidents or near-misses on same topic | update policy and procedure, add controls | incident trend analysis, root cause note, action plan |
process changed (new tool, outsourcing, new sales channel) | update procedure first, then policy if needed | process owner sign-off, updated links |
duplicate policies across entities | consolidate into group policy + local annex | mapping table, local deviations approved |
policy not used, no clear owner, no risk link | retire | retirement approval, archive record |
Step 6: distribute, train, and capture acknowledgement without creating training fatigue
Auditors do not require “everyone trains on everything.” They require that the right people received the right content, and that you can prove it.
Practical rules that work in France and Spain:
- assign policies by role (procurement, sales, finance, HR, executives, association representatives)
- use short acknowledgements for low-risk policies, and training plus attestation for high-risk policies
- avoid annual re-attestation on unchanged low-risk policies (instead, attest on change, and run periodic awareness nudges)
- treat translations as controlled documents with the same approval logic
What an attestation report should contain
Auditors will often request extracts. Make sure you can produce:
- policy title and unique ID
- version number and effective date
- population in scope (headcount, criteria)
- completion status by entity and country
- due date and reminder logic
- exception list (leavers, long-term absence, contractors, system issues) with justification
Step 7: connect policies to your controls so they can be audited and controlled
Policies are not controls. Policies should define expectations, while controls are the mechanisms that enforce or detect compliance.
To make this link explicit, use a lightweight mapping worksheet.
Policy to control mapping worksheet (template)
policy clause | related risk | control(s) | control owner | evidence source | test method |
|---|---|---|---|---|---|
gifts above threshold require approval | bribery risk | approval workflow + register | sales ops or compliance | register entries, approval logs | sample 25 gifts, verify approval |
competitors contacts must be pre-cleared in trade associations | antitrust risk | pre-meeting checklist + minutes review | legal/compliance | meeting pack, attendance list | sample meetings, verify checklist |
third parties must be risk-rated before onboarding | third-party risk | due diligence questionnaire + screening | procurement | due diligence file | sample vendors, verify completeness |
This structure aligns well with how internal audit tests design and operating effectiveness, and it also helps with certification audits under ISO 37001.
Step 8: measure effectiveness (design vs operating effectiveness)
A frequent audit finding is confusion between:
- control design: is the control correctly designed to mitigate the risk?
- operating effectiveness: did it run as designed, consistently, in the period?
Policy management touches both.
Practical effectiveness tests you can run quarterly
Pick 2 or 3 high-risk policies and test them with small samples.
- version control test: search shared drives and intranet for obsolete versions of the policy title
- accessibility test: ask 10 employees in France and Spain to find the policy in under 3 minutes
- operating test: sample transactions or decisions that should have triggered the policy (approvals, registers, due diligence files)
- learning test: run one scenario question in a team meeting and record answers (short, repeatable)
These tests create defensible evidence without building a heavy monitoring machine.
Step 9: define policy KPIs that leadership understands
Your leadership team does not want “number of policies.” They want whether the program is under control.
KPI | definition | what it tells auditors |
|---|---|---|
on-time review rate | % of policies reviewed by due date | lifecycle discipline |
obsolete version leakage | count of obsolete versions found in the wild | document control strength |
role coverage | % of high-risk roles assigned key policies | applicability |
attestation timeliness | median days to complete after publication | adoption velocity |
exception rate | % of in-scope population with justified exceptions | data quality and HR alignment |
policy-linked incidents | incidents tagged to policy areas, trend over time | effectiveness signals |
remediation closure time | median days to close actions from policy breaches | enforcement and follow-through |
Use these KPIs in France/Spain steering committees to harmonize expectations across entities.
Step 10: prepare a policy evidence pack for audits (France and Spain)
When an AFA-style audit, ISO 37001 certification audit, or UNE 19601/19603 assessment happens, time is lost searching for basics. Build a reusable evidence pack.
Policy evidence pack checklist (one folder per core policy)
- approved policy (current version) + version history
- meta-policy (policy on policies) and governance chart
- approval record (who reviewed, who approved, when)
- distribution record (who received it, when)
- attestation report (if applicable) + exceptions list
- training evidence (if applicable), proportionate to risk
- control mapping worksheet (policy clauses to controls)
- last effectiveness test results (design and operating, even if lightweight)
- incidents and remediation actions linked to that policy topic (where relevant)
This pack directly supports “effectiveness, not paper” expectations that come up across frameworks.
Common failure patterns auditors flag (and quick fixes)
“We have a policy, but we cannot show who it applied to”
Fix: define role-based applicability criteria (job family, cost center, country, third-party category) and keep it versioned.
“We cannot prove which version an employee saw”
Fix: ensure attestations capture version number and effective date, and de-publish obsolete versions.
“Policies exist, but procedures and tools do not match”
Fix: run a quarterly link check for referenced forms, registers, and processes, and log remediation.
“Local practices differ between France and Spain”
Fix: keep one group policy with a controlled local annex, then test annex adoption locally.
How naltilia can help
If your biggest bottleneck is evidence, not intent, automation helps. Naltilia can support policy management by connecting policies to your risk map and controls, orchestrating review and approval workflows, tracking attestations, and centralizing audit-ready evidence. This is especially useful in France/Spain groups where translations, local annexes, and distributed ownership make version control hard. If you want to reduce time spent chasing documents before audits, an evidence library and dashboards can make gaps visible early.
Soft next step: explore Naltilia at naltilia.com.
Frequently asked questions
What do auditors test first in policy management? They usually start with governance (who owns what), version control (single source of truth), and evidence of distribution and acknowledgement for key policies.
How often should policies be reviewed? Typically at least annually for high-risk topics, but the defensible approach is risk-based: review sooner after legal changes, incidents, major process changes, or audit findings.
Do we need employee attestation for every policy? Generally no. Use attestations for high-risk policies and for material changes. For lower-risk topics, evidence of availability, communication, and targeted training may be sufficient.
How do we handle group policies across France and Spain? Use one controlled group policy with local annexes where needed (legal references, thresholds, reporting channels), and keep translations and annexes under the same version and approval rules.
How do ISO 37001 and UNE 19601/19603 change policy expectations? They increase emphasis on documented governance, operational controls, and demonstrable effectiveness. Policies should be mapped to controls, monitored, and supported with evidence that they work in practice.
This article is general information, not legal advice.
