Accountability sits with the organisation’s leadership and compliance function together, because Sapin II expects a corporate programme that can be implemented, monitored, and updated across the business. The article also shows that responsibility extends beyond policy owners to managers who oversee high-risk activity, since training, controls, and disciplinary measures only work when leadership supports enforcement.
Who owns Sapin II compliance in practice?
Sapin II accountability is organisational, not purely administrative. The programme has to be owned by leadership because it depends on resourcing, tone from the top, escalation, and enforcement. Compliance functions usually coordinate the framework, but managers and control owners still carry responsibility for applying it in day-to-day activity where corruption risk is highest, especially in third-party interactions and high-value business decisions.
That division matters because a compliance programme can be well written and still fail if business leaders treat it as a legal checkbox. Effective ownership means someone can answer who approves controls, who reviews exceptions, who tracks remediation, and who can stop a risky transaction or relationship when controls are not working as intended.
What accountability should look like across the organisation
The strongest Sapin II programmes separate information security management style oversight from operational execution: leadership sets expectations, the compliance function maintains the programme design, and the relevant business managers enforce the controls where they operate. That structure is important because anti-corruption controls only work when they are integrated into procurement, sales, intermediaries, gifts and hospitality, and approval workflows rather than being left in a policy folder.
In practice, accountability also needs evidence. A programme is more credible when it has named owners for risk mapping, due diligence, training completion, incident escalation, disciplinary follow-up, and periodic review. That is why governance artefacts, review minutes, and control attestations matter, they show the programme is being maintained rather than merely announced.
For compliance programmes with strong audit and assurance expectations, SOC 2 Trust Services Criteria is a useful analogue for thinking about ownership: controls must be operated consistently, monitored, and evidenced by accountable people. The same principle applies here, even though Sapin II is a different legal regime, because accountability without operating discipline does not produce defensible compliance.
If the organisation operates in payments or regulated commercial environments, control ownership should also be explicit at the process level, not just the policy level. PCI DSS v4.0 shows the value of clear role separation and least-privilege control ownership, which is a useful compliance pattern when a Sapin II programme depends on approvals, access, and segregation of duties.
Risk and Threat Considerations
The main failure mode is diffusion of responsibility. If leadership assumes compliance owns everything, while compliance assumes business managers will enforce controls, high-risk third-party arrangements, gifts, or facilitation-risk situations can proceed without meaningful challenge. That creates a gap between policy and practice, which is where compliance failures usually emerge.
Failure mechanism: unclear ownership weakens escalation, control testing, and exception handling, so risky conduct is not stopped at the point of decision and remediation drifts until after an issue is discovered.
Impact: the programme may appear complete on paper but still fail under review, because the organisation cannot demonstrate active supervision, timely intervention, or consistent enforcement across the business.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.3 — Segregation of Duties | Separates ownership and approval responsibilities across Sapin II controls. |
| A.5.37 — Documented Operating Procedures | Supports a maintained programme with named responsibilities and repeatable controls. | |
| Recommendation — Assign distinct approvers and reviewers for high-risk compliance decisions. Document and maintain role-specific procedures for Sapin II control operation. | ||
| CIS Controls v8 | 3 — Data Protection | Supports governance over sensitive business and compliance records used in oversight. |
| Recommendation — Track and protect compliance evidence needed for audit and review. | ||
Practitioner Guidance
What to verify: confirm that each major Sapin II control has a named owner, an approver, and a reviewer, and that the business managers closest to the risk know when they are expected to escalate rather than self-approve.
What good looks like: leadership can show it receives status reporting, compliance can show monitoring and updates, and managers can show they apply controls in procurement, third-party onboarding, and exception handling without waiting for central intervention.
Common mistake: treating compliance as the owner of the whole programme while the business remains a passive subject of the rules. That usually produces weak enforcement, because the people with decision authority are not tied to the control outcomes.
Practitioner takeaway: effective Sapin II accountability is shared, but not diluted, leadership must own the programme, compliance must run it, and managers must enforce it where the risk actually occurs.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
