Certified does not mean unbreachable: what to demand from a digital postman beyond a certificate

A purchasing checklist: general assurance categories are not a complete audit of Slovak provider certification.

A certificate is useful evidence when we know what it certifies. It becomes misleading when a sales conversation turns it into a promise that an entire service cannot fail. Businesses choosing an e-invoicing provider should avoid both extremes: accepting a logo as a complete security assessment, and dismissing certification as meaningless paperwork. The practical task is to connect assurance to the service, data and operating risks the business will actually depend on.

This matters especially when a public obligation brings firms into a new provider relationship. Small businesses cannot each fund a full technical investigation of every digital postman. They need reliable baseline assurance and clear contractual information. But reducing their burden is not the same as asking them to trust an undefined certificate. The public framework should make evidence comparable and identify where customer-specific judgment is still required.

These general categories do not establish the full current Slovak authorisation requirements. Before judging a service, obtain the applicable national conditions and mark what they already cover, what the supplied evidence demonstrates and what remains a customer recommendation. The absence of that comparison here does not show that national certification omits the proposed controls.

Three things commonly called certification

A Peppol production certificate, technical conformance testing and an information-security management certification answer different questions. OpenPeppol describes its public key infrastructure as part of the network’s trust arrangements and its provider agreements as part of the governance framework.1 A digital credential enabling network participation should not be confused with a comprehensive evaluation of every customer-facing function.

OpenPeppol’s Testbed assesses technical conformance to Peppol specifications. Its accreditation test suite must be passed for a provider to obtain a production PKI certificate, and a successful report supports the certificate request.5 That is valuable: interoperable messaging needs consistent implementation. It is not a reason to assume that every accounting connector, administrator account, backup or optional archive has been tested for every security failure.

ISO/IEC 27001:2022 concerns an information security management system. ISO explains that conformity means an organisation has a system for managing risks to the security of data it owns or handles, following the standard’s principles and practices.6 That is more substantial than merely possessing written policies. It is also different from a guarantee that no vulnerability exists or that no future incident can occur.

Read the scope before the logo

When a provider presents certification, ask for the exact legal entity, standard and edition, certification body, validity information and scope. Does the scope cover the e-invoicing service being purchased? How are hosting and subcontracted activities treated? Does the service described in the certificate match the product and contractual entity on the order form? These are due-diligence questions, not an accusation that any named provider misrepresents its status.

A group-wide brand can conceal operational distinctions. The certified organisation might offer several products, or the contracted service might depend on another entity. Customers do not need to infer wrongdoing from such arrangements. They do need an intelligible explanation of how assurance follows the actual service and supply chain.

The same caution applies to dates. Evidence of a successful assessment is relevant to its scope and period. A major service change should prompt a question about how the provider assessed the change and whether the available assurance still describes the operation. “We were assessed” and “this newly introduced function is covered” are not interchangeable statements.

A hypothetical procurement decision

Imagine a fictional distributor choosing between two providers. Both demonstrate the relevant network status and present information-security certification. One offers only delivery; the other also offers invoice storage, support access and data conversion. A comparison that ticks “certified” for both and then considers only price would overlook the different service boundaries.

Suppose the distributor needs to recover invoices and delivery evidence after a failure. It should map each recovery task to the party contracted to perform it and ask each provider to demonstrate recovery of its own contracted functions using synthetic records. A delivery-only provider need not restore an archive it has not sold; archive recovery belongs to the contracted archive service or the business’s own systems. For records within the purchased scope, can documents be restored in a usable format, restored records distinguished from newly transmitted messages and duplicate submissions avoided? A recovery exercise provides evidence about a particular requirement that a general badge cannot explain by itself.

This is not a report of tests I performed, and neither hypothetical provider has failed. The example shows how to make a procurement decision testable. If each satisfies the operational requirements within its contracted scope, certification remains useful supporting evidence. If one cannot describe the recovery process, the buyer has identified a question to resolve before relying on the service.

Ask for evidence in layers

The first layer is identity and access. I would ask how privileged access is authenticated, approved and removed, and how customer separation is checked. Who can view an invoice for support purposes? Can that access be limited to a case and recorded? A response should describe the actual service rather than repeat that employees have received training.

The second layer is data handling. Where can readable content exist? What is retained for delivery, troubleshooting and archiving? How are keys controlled and backups protected? Encryption claims need boundaries: encryption during transmission does not describe every point where an application or authorised person handles the document. The provider should explain those boundaries without disclosing secrets that would compromise security.

The third layer is technical assurance. Request a suitable summary of independent testing: the service assessed, when it was assessed, what classes of risk were covered and how material findings were addressed and retested. A full penetration-test report need not be public to make assurance meaningful. A tightly scoped summary and access under appropriate confidentiality arrangements can be more responsible than either secrecy about everything or indiscriminate publication.

The fourth layer is resilience. For the contracted functions, ask for the latest relevant recovery exercise, the assumed failure, the recovery objective and the result. A backup’s existence is not the same as evidence that a customer can resume its workflow. Availability promises also need definitions: which service is measured, from which point, with which exclusions and how customers learn of an incident.

Security is a process after onboarding

GDPR Article 32 requires appropriate technical and organisational measures proportionate to risk, including, as appropriate, confidentiality, integrity, availability, resilience, timely restoration and regular testing of effectiveness.16 Those requirements concern personal data processing. They also illustrate why a point-in-time procurement decision cannot replace continuing operational assurance.

A contract should identify how the provider handles material changes, subcontractor changes and incidents affecting the purchased service. Where the relationship is controller-to-processor, GDPR Article 28 contains requirements concerning other processors, assistance and information needed to demonstrate compliance, including provision for audits.16 The actual roles must be assessed for the activity; “digital postman” does not automatically determine them for everything a provider does.

Operational notification should give a customer usable facts as they become available: affected service, known scope, containment and next update. That recommendation is separate from any statutory notification threshold or deadline. A provider should not promise perfect early certainty, but customers should not have to wait for a completed investigation before receiving relevant operational information.

A certificate does not settle liability or exit

Security assurance and contractual remedies belong in the same procurement discussion, but they are not the same thing. Examine liability provisions, available remedies and the evidence a customer would receive after a disputed failure. Do not infer a business’s rights from a certificate, or from a contract between different parties for a different component.

The exit plan deserves equal attention. Can the business export its invoices, metadata needed for reconciliation and delivery evidence? What remains after termination, for what purpose, and under which retention rules? A secure relationship should not depend on keeping the customer permanently tied to one interface. These are service requirements to negotiate or standardise, not features guaranteed by a security-management certificate.

The strongest objection: due diligence has a cost

A small firm cannot reasonably commission bespoke audits of every shared platform. Providers cannot accommodate unlimited intrusive tests by every customer without expense and risk. Certification exists partly to make trust scalable, and dismissing it would recreate duplication. That is the strongest argument against an ever-expanding checklist.

The solution is proportionate shared assurance. A public authority or market framework could define a common evidence pack covering scope, data flows, incident contacts, recovery evidence and exit. As a proposed baseline, refresh the pack annually and after material changes: public scope, assessment date and incident contacts; confidential customer recovery and exit evidence; restricted technical findings for authorised reviewers. Existing independent evidence should suffice where current and relevant to the purchased scope. Extra scrutiny should address a specific uncovered risk, stale evidence or material change—not duplicate a full audit for every account. Customers should not conduct unauthorised scans or demand production access merely because they are evaluating a supplier.

A publicly available baseline channel could use the same assurance model, with specialist providers procured behind it where appropriate. Public operation would not remove the need for testing, competent staff or accountability. My proposal concerns a simpler way for businesses to meet a public obligation, not a presumption that state infrastructure is immune to failure.

Make assurance an answerable claim

Before signing, ask the provider to connect each major promise to evidence and an owner: network conformance, information-security scope, restricted access, recovery, notification and exit. Accept limits honestly stated and resolved; be cautious of absolute promises. Certification should open that conversation, not close it.

The objective is not an impossible “unbreachable” service. It is a service whose risks are managed, whose controls are tested and whose customer can obtain meaningful answers when something changes. That is a stronger foundation for e-invoicing than either blind faith in certificates or blanket distrust of the people who earn them.