Peppol Makes ISO/IEC 27001 Mandatory for Certified Service Providers

What OpenPeppol has decided

On 24 June 2026 the OpenPeppol Managing Committee approved the final ISO/IEC 27001 Implementation plan. Certification becomes a condition of continued participation in the network, and the certificate has to cover the Peppol services the provider actually operates.

The draft circulated for member review set the deadline at 1 July 2027. The Managing Committee moved it, recording that the final documentation "has been made available three months later than planned" and that the deadline therefore "shifts with 3 months". The date in the approved plan is 1 October 2027.

The July date is still widely quoted, including by the Italian Peppol Authority, whose July 2026 notice carries it in the headline and links the earlier draft. The approved plan is the document to work from.

OpenPeppol's stated reason for requiring certification rather than self-declaration is that "self-attestation and contractual commitments alone are not sufficient to manage this risk". The plan sets the decision against NIS2, DORA and comparable security regimes in the United States, Singapore and Australia, and concludes that the mandate "does not create a new burden" but aligns the network with existing regulation.

Who the obligation applies to

The obligation applies to Peppol Certified Service Providers, and the plan ties it to one thing: holding a Peppol PKI Production certificate. Providers without one are not caught.

A second date sits well before the deadline. Providers issued a first PKI Production certificate on or before 31 December 2026 have until 1 October 2027 to certify. From 1 January 2027, a first PKI Production certificate will only be issued to an applicant that already holds ISO/IEC 27001 or an approved equivalent. Test certificates are unaffected, so conformance testing can continue while a certification project runs.

Holding a certificate is not the same as being compliant

The plan is explicit that a certificate is necessary but not sufficient. Its scope must cover the end-to-end provision of the Peppol services operated under the Service Provider Agreement, including the systems and processes behind them. Providers have to check their Statement of Applicability against that definition before submitting, and open a scope extension with their certification body where it falls short. The plan warns that an extension "cannot be assumed to take an exact amount of time".

Three conditions catch providers who assume an existing certificate is enough. A group certificate held by a parent only counts if it names the entity that signed the Service Provider Agreement. A certificate that is still valid but whose surveillance audits have slipped does not count, because compliance includes keeping to the audit calendar. And a provider running on someone else's certified platform still needs its own certificate: the host's covers the platform's infrastructure, not how the provider configured access control, database encryption, credential handling or MFA on its own admin portal.

From submission to enforcement

The plan sets six submission milestones, T0 to T5, then a five-step non-compliance phase. The nearest one matters most: by 1 September 2026, providers that already hold a qualifying certificate must submit it through the OpenPeppol Service Desk with the Statement of Applicability, the Service Provider Agreement and a signed management attestation. Until OpenPeppol acknowledges that submission, the provider is treated as not holding a valid certificate and has to meet the later deadlines like everyone else.

Enforcement is initiated by the Peppol Authorities rather than OpenPeppol, and the plan describes the non-compliance dates as an indicative timeline that Authorities may handle case by case. It flags two situations for particular attention: public bodies whose national rules make the Peppol requirement difficult, and providers that started late while waiting on an alternative scheme that was ultimately rejected.

Equivalent certifications

A security certification other than ISO/IEC 27001 may be accepted, but only if it appears on the official OpenPeppol list of allowable certificates. Requests to add a scheme closed at T0 on 31 July 2026. They are reviewed by the Operating Office with the Security Committee, and the Managing Committee decides. The test is whether the scheme covers Peppol end-to-end services and requires independent third-party audit rather than self-assessment.

The plan makes one allowance: public sector entities subject to national security requirements that exceed ISO/IEC 27001 may have an equivalent third-party audited framework accepted. On the auditor, providers may choose any certification body accredited by a recognised national accreditation authority, in any jurisdiction.

If you reach Peppol through a provider

The obligation sits with the certified provider, not with the businesses and ERP teams exchanging documents through it. The exposure is indirect: the escalation above ends in the provider losing its PKI Production certificate and then its Service Provider Agreement.

The conditions above are checkable, which makes them reasonable renewal or tender questions. Does the certificate name the entity that signed the Service Provider Agreement? Does the Statement of Applicability cover the Peppol services in use? Are surveillance audits current? And where the provider runs on a white-labelled platform, does it hold its own certificate rather than its host's?

What happens next

For providers already certified, the work is a scope check rather than a certification project, and OpenPeppol asks anyone unsure whether their Statement of Applicability qualifies to confirm it through the Service Desk before submitting. Providers who sent a certificate before the final plan was published need to add the remaining documents to the same ticket.

For providers not yet certified, the plan asks for early engagement with a certification body and proof of it. Where the earliest available Stage 2 audit falls after the deadline, the FAQ says to submit a certification process plan with the audit date confirmed by the certification body. The plan also stresses that ISO/IEC 27001 places obligations on senior leadership that cannot be delegated to a security team, and that programmes treating it as a technical workstream tend to come apart at the surveillance audit. Our ISO 27001 explainer covers what the standard involves.

One inconsistency survives in the approved document. At T2 the evidence package asks for a plan "confirming that certification will be achieved by 1st of July 2027", the release-candidate date, while the requirement beside it refers to 1 October 2027. Every other part of the plan uses 1 October 2027.