Why run your own Peppol access point instead of buying one
Self-hosting a Peppol access point is a reasonable option for an enterprise or service provider that sends and receives Peppol invoices at scale, and the decision turns on three things: volume, control and operating capacity. Volume determines whether per-document fees from a service provider or an ERP vendor's network cost more over time than running your own AS4 endpoint and SMP. Control covers where invoice payloads are processed, who holds the private keys and certificates, and how quickly you can change routing when a trading partner or national rule changes. Operating capacity is the factor teams most often underestimate, because someone must own certificate renewals, AS4 message monitoring, SMP record maintenance, patching and incident response on a fixed schedule. If your current network no longer covers your trading partners, your countries or your data location requirements, the case for self-hosting gets stronger. If none of these pressures applies, buying remains the simpler path.
The open source path rests on two components. Oxalis-NG handles AS4 message exchange between access points, and phoss SMP serves capability lookup, publishing which document types and endpoints a participant supports so that senders can find the right receiver. The older Oxalis line is frozen and no longer receives development, so any access point still running it has to be migrated before it becomes a security and compliance gap. Start by inventorying every Oxalis deployment: its version, the Peppol document types and transport profiles it serves, and the systems that call it. That inventory defines the migration scope. Confirm the current support status of each component with its maintainers before you commit to a plan and a timeline.
DeployOpen plans, implements, customizes, hardens, backs up, upgrades and supports this stack inside your own cloud accounts, data centers or air-gapped networks, so invoice data and keys stay under your control. DeployOpen does not issue Peppol accreditation, certificates or any authority's approval. Accreditation runs through the Peppol authority process, so confirm the accreditation route for your country and legal entity before any work is scoped. Ask any implementation partner for a written scope that names who holds the accreditation, who requests and renews certificates, which monitoring and alerting is in place, how upgrades are tested against new Oxalis-NG and phoss SMP releases, and who responds when AS4 messages fail overnight.
Requirements a self-hosted access point must meet
This table maps each operating requirement for a self-hosted Peppol access point and SMP to its source, what it means for the build, and where teams usually fall short. Read it as a checklist to take into accreditation discussions, since the Peppol authority, not DeployOpen, sets and confirms the current rules. Use the rows to decide which requirements your organization must own internally and which a partner can help implement.
| Requirement | Source | What it means for the build |
|---|---|---|
| Accreditation with the Peppol authority | Peppol governance and the relevant Peppol authority | Confirm current accreditation steps, documents and timelines directly with the authority. DeployOpen does not grant accreditation, so plan the legal entity, contacts and sign-offs as your own deliverables. |
| Peppol certificates and PKI handling | Peppol governance and certificate policy | Plan issuance, storage, renewal and revocation of access point and SMP certificates. Ask who holds private keys, where they live and how an expired certificate is detected before traffic stops. |
| AS4 message exchange | Peppol governance (AS4 transport profile) and Oxalis-NG documentation | Run AS4 endpoints that send and receive signed, encrypted messages. Test with peer access points, confirm receipts and retry behavior, and monitor message status end to end. |
| SMP registration and lookup | Peppol governance and phoss SMP documentation | Publish participant and document type capabilities in your SMP and keep them accurate. Verify that lookups from other access points resolve correctly after every change to endpoints or certificates. |
| Message retention | SEC Rule 17a-4(b) where invoices are business records, plus your national tax retention rules | Define how long payloads, metadata and receipts are kept and where. Confirm retention periods with your tax advisor and legal team, since the SEC rule applies only to broker-dealers. |
| Access control and logging | 16 CFR 314.4 where a financial institution handles customer data | Require multi-factor authentication for administrators, restrict access to keys and message stores, and log administrative and user activity. Review who can change endpoints or certificates. |
| Change management | 16 CFR 314.4 change management requirement where applicable, and Peppol operational guidance | Document, test and approve changes to software versions, certificates, SMP entries and routing. Ask how the team tests changes against peer access points before production. |
| Vulnerability testing | 16 CFR 314.4(d)(2) where continuous monitoring is absent | Schedule penetration tests and vulnerability assessments at least every six months unless effective continuous monitoring is in place. Include the AS4 endpoint and SMP in scope. |
Which organizations should self-host and which should buy
A large enterprise that sends its own invoices to many trading partners usually has the strongest case for running its own access point and SMP, because the traffic, the data handling rules and the integration with the general ledger are all internal. Self-hosting keeps invoice payloads inside the company's own cloud accounts or data centers, lets the security team set the certificate and key policies, and puts the logs where internal audit can read them. The cost is an accountable internal team. That team must run Oxalis-NG for AS4 transport, phoss SMP for capability lookup, patch both, rotate certificates, and carry the operational load of an accredited network participant.
- Data location: Invoice content, bank details and customer identifiers stay in infrastructure the company already governs.
- Operating staff: Expect a platform team with on-call coverage, plus people who own the ERP mapping and partner onboarding.
- Certificate handling: The company holds its own Peppol certificates and must plan renewals and revocation as an internal process.
- Accreditation work: The company, not a vendor, answers for the access point's compliance with the Peppol requirements in its own name.
- Volume economics: Per-document fees disappear, but infrastructure and staffing become fixed costs that must be justified by volume.
Before committing, confirm with the Peppol authority and your own environment what the accreditation process requires and how long it takes.
A service provider that offers Peppol sending and receiving to its own customers is in a different position. Its access point is part of the product, so accreditation, uptime and support obligations are direct business commitments rather than an internal project. Running the access point in-house gives the provider full control over routing, tenant isolation and the tooling it gives customers. It also means the provider carries the accountability for every customer's documents, which makes multi-tenant design, key separation and audit trails central requirements rather than extras.
- Data location: Customer documents from many companies sit in one platform, so tenant separation and regional hosting are design decisions.
- Operating staff: Dedicated engineers handle AS4 operations, SMP directory changes and customer-facing incident response.
- Certificate handling: Certificates may be issued per customer or per provider, and the provider must document which model applies.
- Accreditation work: The provider must hold its own accreditation and keep it current as the network rules change.
- Commercial model: Revenue per customer has to cover fixed platform cost, so pricing and volume forecasts shape the decision.
Ask how the provider will show customers that one tenant cannot read another tenant's invoices, and how that claim will be tested.
Many organizations already use an ERP vendor's Peppol connection or a proxy the vendor operates. This route minimizes the number of systems the company runs, and the vendor carries the access point operation and most of the accreditation work. The trade-off is dependence: the company's invoice flow, retention and change timing follow the vendor's roadmap, and data passes through a network the company does not operate. For a company that already runs self-hosted ERP, the question is whether the vendor's connection keeps data where the company's policies require and whether the company can leave without rebuilding its partner registrations.
- Data location: Invoices pass through the vendor's network, so confirm hosting regions and any subprocessors in writing.
- Operating staff: The company still runs ERP configuration, master data such as Peppol IDs, and partner testing.
- Certificate handling: Certificates are usually managed by the vendor, which reduces internal work but removes direct control.
- Accreditation work: The vendor holds the accreditation, so the company's work is mainly evidence collection for its own auditors.
- Exit path: Ask how participant identifiers, archives and message logs can be exported if the company later moves to its own access point.
Check whether the vendor's proxy dependency affects your mandated formats or countries before relying on it.
An organization that sends and receives a small number of invoices often finds that running its own access point creates more operating burden than value. The fixed work of patching AS4 and SMP services, managing certificates, monitoring message delivery and keeping accreditation evidence current does not shrink with volume. A buyer in this position usually gets more benefit from a service provider or an ERP vendor connection, where the cost is mostly per document or per subscription and the operations are handled by someone whose full-time job is the network. Self-hosting still makes sense when data rules forbid third-party handling, regardless of volume.
- Data location: If policy requires that invoice content never leave company control, self-hosting may be justified even at low volume.
- Operating staff: A small team may not have spare capacity for on-call duty and certificate renewal.
- Certificate handling: Renewal deadlines and key custody become easy to miss when they are handled only occasionally.
- Accreditation work: Accreditation effort is a fixed cost, so it weighs more heavily on low-volume senders.
- Mandate pressure: Countries with national mandates may require a specific network or provider, which can settle the choice before volume matters.
Request a written quote for each option and compare the recurring costs over the contract term.
Which open source components fit an access point stack
A self-hosted Peppol access point rests on three layers that depend on one another: an AS4 access point for exchanging messages, an SMP for publishing where each participant can be reached, and the certificate layer that authenticates both. Each component has a different job, and each needs its own confirmation of version, licence and maintenance status before you commit.
Oxalis-NG as the AS4 access point
Oxalis-NG is the AS4 engine that sends and receives Peppol messages on your behalf. It handles the transport and message exchange with other access points, so it sits at the center of the stack. Confirm with the maintainers which release is current, which Peppol profile versions it supports, and what the operating requirements are for your Java runtime and database.
Frozen Oxalis line
The older Oxalis line is no longer developed, so new deployments should start from Oxalis-NG instead. Existing installations built on the older line need a migration plan that covers configuration, certificates and message handling. Ask your implementation partner to inventory every place the old line is referenced in your estate before any cutover.
phoss SMP for capability lookup
The phoss SMP publishes service metadata that tells other participants which document types and transport endpoints your organization accepts. Sending access points query it before every exchange, so its availability and accuracy directly affect delivery. Confirm the current release, its supported SMP specifications, and how it handles participant registration updates.
Peppol certificates and PKI
Both the access point and the SMP depend on certificates issued under the Peppol trust framework, which authenticates each party in the network. Certificate validity, renewal and revocation handling must be built into operations from the start. Ask the Peppol authority or your accredited provider which certificate profiles and trust lists currently apply to your role.
Hosting and operating the components
Running Oxalis-NG and phoss SMP means operating a Java service, a database, a reverse proxy and monitoring, all within your own cloud or data center. Plan for patching, backups of certificate material and configuration, and logging that supports audit. Confirm the hardware, database and high-availability requirements with each maintainer before sizing the environment.
Licences and maintainer checks
Each component carries its own licence and release cadence, and these can change between versions. Before selection, confirm the licence terms with the maintainers, check the open issues and release history for signs of ongoing support, and record the versions you tested. Treat this check as a gate in your selection review, not a one-time task.
How the rollout moves from scoping to live operations
The sequence turns a decision to run Peppol infrastructure into a tested, accredited access point and SMP that the team can operate and hand over. Each phase closes with a written output that the next phase depends on.
Scope the volumes and document flows
The client team and DeployOpen review which document types, senders, receivers and countries the access point must cover, and estimate message volumes per flow with the finance and ERP owners. DeployOpen then drafts the written scope, covering the software components, hosting model, integrations and out-of-scope items. The step is done when the client signs off a scope document that names the owner of each decision, including who holds the Peppol participant identifiers and who answers for the service during operations.
Confirm accreditation path and certificate requirements
The client confirms with the relevant Peppol authority and its own legal entity what accreditation the organization needs to operate as an access point or SMP, and which governance documents, contacts and technical declarations apply. In parallel, the team identifies the certificate types, issuing authority and key custody model the Peppol network requires. Timing for approvals is set by the accreditation body and the client's change calendar, so the client should obtain those dates in writing. The output is an accreditation checklist with named owners and a certificate plan.
Build test and production environments
DeployOpen provisions separate test and production environments in the client's own cloud account, data center or private network, with Oxalis-NG for AS4 message exchange and phoss SMP for participant capability lookup. The build covers hardening, TLS and certificate installation, key storage, backups, logging and access control aligned with the client's security baseline. The step closes when the team can send and receive test messages in the test environment, and the configuration, runbooks and network rules are documented and versioned.
Integrate the ERP and document pipeline
The client's ERP or invoicing system is connected to the access point through the agreed interface, with mapping for the UBL or other syntax used, validation against the relevant rules, and error handling that routes rejected documents to a queue with an owner. DeployOpen tests inbound and outbound paths, status reporting back to the ERP, and retry behavior. The output is a tested integration with a defect log and a list of known limits, such as document types not yet mapped.
Run partner testing and certification
The team registers test participant identifiers in the SMP and exchanges messages with trading partners or the network's test partners, covering every document type and error scenario in the scope. Results are recorded per test case, and failures are fixed and retested until the agreed pass criteria are met. The client should confirm with the accreditation body which test evidence it expects before go-live. The step is done when the test evidence pack is accepted by the client and, where applicable, by the accreditation body.
Migrate off Oxalis where it applies
Where the organization runs an existing Oxalis-based setup, the team moves participant registrations, certificates and routing to the supported successor components in a planned cutover window. The plan covers a parallel run or fallback path, rollback steps and the handling of messages in flight during the switch. The client confirms the migration timing against its own change calendar and any notice terms from the vendors involved. The output is a completed cutover with reconciled message counts and a decommissioning record for the old components.
Go live and monitor the service
After approval, the access point and SMP move to production, with alerting on message failures, certificate expiry, queue depth and service health. The client's operations team observes the first live traffic under an agreed hypercare arrangement, and DeployOpen tunes thresholds based on observed volumes. The step closes when monitoring dashboards and alerts are confirmed by the client's on-call staff.
Hand over runbooks and ongoing responsibilities
DeployOpen delivers operating procedures for certificate renewal, participant onboarding, incident response, patching and backup restore, along with a responsibility matrix separating client and DeployOpen duties. Any continuing support, upgrades or testing are set out in a separate written agreement such as a retainer. The handover is complete when the client's staff have run each runbook once in a test environment and the responsibility matrix is signed by both parties.
Deployment patterns for the access point in regulated environments
A self-hosted Peppol access point can run in three broad models: in the client's own cloud account, in a segregated service-provider environment shared by several clients, or on premises or in a private network. Each model changes who holds the keys, how traffic is segmented, where message logs live and how recovery is designed. The cards below set out what to decide and check for each.
Single-tenant in the client's cloud account
The access point, its SMP and the supporting services run in a dedicated account or subscription that only the client's team controls. Keys, certificates and message stores stay under the client's own identity and key management policies, and the client decides who can reach the AS4 endpoint. Check where the cloud key service holds the private keys, whether network rules isolate the AS4 receiving path from internal ERP networks, and whether message logs are written to storage the client controls. Recovery needs a second region or account, a tested restore of the message store and certificate material, and a written recovery target agreed with the implementation partner.
Segregated service-provider deployment
A provider runs one platform for several clients, with each client's certificates, routing data and message history kept in separate tenants or databases. This model suits organizations that want accreditation and operations handled by a specialist team, but it adds shared-responsibility questions. Ask how tenant keys are separated, whether one client's administrators can see another's messages, how access is logged and reviewed, and how the provider restores one tenant without touching others. Confirm where data is located and which contract terms govern incident notice.
On-premises or private network variant
Some regulated organizations keep the access point in their own data center or a private network with no public cloud dependency. The AS4 endpoint must still be reachable from the Peppol network through controlled inbound and outbound rules, so the team needs a clear design for the DMZ, the firewall policy and the path that carries SMP lookups. Hardware security modules or an equivalent key store protect the private keys. Recovery depends on a second site or a replicated virtual environment, and the team must test restores from backups that were taken while the access point was running.
Key storage and certificate custody
Peppol access points authenticate with certificates, so the private key is the asset that must be protected most carefully. Decide whether keys sit in a hardware security module, a cloud key service or a software keystore with restricted file permissions, and document who can generate, rotate and revoke them. Confirm the procedure for certificate renewal and for revocation after a suspected compromise, and make sure the accreditation and SMP registration steps can be carried out without copying private keys between environments.
Network segmentation and inbound exposure
The AS4 receiving endpoint is the only component that needs to accept inbound traffic from the Peppol network, so it should sit in its own network zone with a narrow rule set. The Oxalis-NG and phoss SMP components, the database and the ERP connector should not be reachable from the internet. Map each allowed flow, including outbound calls to SMP lookups and to the internal ERP, and review those rules whenever the Peppol network requirements or the team's ERP integration changes. Ask the partner to show the rule set and test it from outside the zone.
Message activity logging and retention
Each inbound and outbound document needs a trace that links the Peppol message identifier, the sender and receiver participant IDs, the transmission outcome and the business document reference. Store these records in an append-only or tamper-evident location separate from the application database, and restrict who can alter them. Retention periods are set by the client's own records policy and by tax and financial rules in each country, so confirm them with compliance before configuring log rotation. Make sure payload retention and log retention are handled as separate decisions.
Disaster recovery and continuity testing
Recovery for an access point must cover certificates, the SMP registration, the message store and the configuration, because losing any one of them can stop document exchange even when the servers are back. Define a recovery point and recovery time with the client's business owners, keep an offline copy of the certificate material under strict access control, and rehearse failover to the secondary site. Write down how the team will notify trading partners and the Peppol operating authority if messages cannot be sent or received during an outage. No recovery figures should be promised until the partner has tested them in the client's environment.
Evidence auditors and regulators ask for from the access point
This table maps each piece of evidence to the component that produces it and the requirement it supports. Read it as a checklist to build before an assessment, and confirm retention periods and formats with your auditor or regulator. DeployOpen prepares this evidence for assessment, but independent auditors and certification bodies issue the audit reports.
| Evidence | Produced by | Requirement it supports |
|---|---|---|
| Certificate inventory for Peppol and AS4 endpoints | Access point and SMP certificate store, plus your certificate management records | Access control and key management expectations under 16 CFR 314.4 (encryption in transit over external networks) |
| AS4 transmission logs with message IDs and timestamps | Oxalis-NG access point message and receipt logs, forwarded to central log storage | Activity logging for authorized users and systems under 16 CFR 314.4, and proof of delivery for invoice records |
| SMP registration and participant lookup records | phoss SMP administration logs and participant metadata history | Accuracy of participant data and change tracking for master data used in invoice routing |
| Access logs showing administrator and operator activity | Operating system, directory and application audit logs, reviewed against a named access list | Logging of user activity and multi-factor authentication for anyone accessing the systems under 16 CFR 314.4 |
| Change records for software, configuration and certificates | Change tickets, deployment pipeline history and version records for each upgrade | Change management procedures required under 16 CFR 314.4, including records of who approved each change |
| Annual penetration test report | Independent penetration tester working against the in-scope access point and SMP | Annual penetration testing under 16 CFR 314.4(d)(2), where continuous monitoring is not in effect |
| Vulnerability assessment reports at least every six months | Scanner output for hosts, containers and dependencies, with remediation tracking | Six-monthly vulnerability assessments under 16 CFR 314.4(d)(2), where continuous monitoring is not in effect |
| Retention records for invoice and communication data | Archive storage and retention configuration for transmitted and received documents | Record preservation duties, such as those in 17 CFR 240.17a-4 where a broker-dealer is the operator, confirmed with counsel |
Running certificates, monitoring and upgrades after go-live
The recurring work of a self-hosted Peppol access point is the part most often underestimated at purchase time. Once Oxalis-NG and phoss SMP are live, the one-time items (accreditation, initial certificate issuance, network connection and first partner tests) are finished, and what remains is a run loop: certificate renewal and revocation handling, watching AS4 delivery failures, keeping SMP records correct, applying component upgrades and security patches, and answering alerts out of hours. Before go-live, write down who owns each of these, how often each occurs, and which of them your accreditation terms or Peppol obligations make time-bound. Confirm the certificate lifetimes and renewal procedure with the Peppol authority and the certificate issuer, since those dates drive the calendar, not the software.
Certificate work deserves its own runbook. Map every certificate and key the access point and SMP depend on, including the AS4 signing and transport certificates and any keystore used by the SMP, and record its expiry, its owner and the exact steps to replace it without dropping traffic. Test a renewal in a non-production environment, then confirm that trading partners and the Peppol directory pick up the new material. Revocation is a separate path: you need a tested procedure for a compromised key, including who can trigger it, how the SMP and partners are told, and how documents in flight are handled. Monitoring should alert on AS4 receipt failures, retries, signature or certificate errors and SMP lookup failures, with the logs retained long enough to support investigation of disputed transmissions.
Upgrades follow the same discipline. Track releases of Oxalis-NG and phoss SMP, along with the Java runtime, database and operating system beneath them, and decide in advance how security patches are fast-tracked compared with feature releases. Every change should pass through change management with a rollback plan, because a failed AS4 upgrade affects every partner at once. Ongoing support of this kind, covering monitoring, on-call response, patching and upgrades, can be provided by DeployOpen under a retainer. Ask any provider for written response targets, the named escalation path, the change windows it will use and how it tests upgrades against your certificates before production. Those terms, not the initial build, determine how the system behaves in year three.
How much work and cost does a self-hosted access point take?
How much does it cost to run a self-hosted Peppol access point?
There is no single price, because cost depends on the scope of your setup rather than on a fixed fee. The main cost components are the accreditation and onboarding work, Peppol certificates, the infrastructure that hosts the access point and SMP, integration with each ERP or accounting system, monitoring, and the people who operate it. Some of these costs are one-time, such as accreditation effort and initial integration. Others recur, including hosting, certificate renewal, monitoring, patching and staff time. Ask any quote to split these components out so you can compare them with a service provider's per-document pricing.
Which factors push the cost of a self-hosted access point up or down?
Four factors drive most of the difference. The first is document volume, because throughput determines sizing, hosting and how much monitoring capacity you need. The second is the number of connected ERPs and business systems, since each one adds mapping, testing and maintenance. The third is certificate handling, including how many certificates you manage, how they are stored and how renewals are automated. The fourth is staffing and monitoring, meaning whether you have people with AS4 and Peppol knowledge on call. A low-volume setup with one ERP carries a very different load from a group running many entities across several countries.
How long does it take to get a self-hosted access point running?
The timeline depends mainly on the accreditation process, your internal approvals and how quickly your partners complete their own onboarding and testing. Timing for the accreditation steps is set by the accreditation body and the Peppol authority, not by DeployOpen or Oxalis-NG, so confirm the current process and expected lead times with them before you commit to a date. Infrastructure, integration and partner testing can run in parallel with accreditation. DeployOpen plans the rollout in a written scope and agrees the timeline with you before work starts.
What does my team need to provide for a self-hosted access point?
Your team needs to supply the business and legal inputs, plus the technical access to run the system. Typical inputs include the legal entity details and identifiers required for accreditation, a named owner for the service, access to your cloud or data center environment, and the ERP or accounting system owners who will connect to it. On the technical side, you need someone who can own DNS, TLS certificates, firewall rules, backups and incident response. You also need a process for testing with trading partners and for handling rejected or failed messages. Agree who signs off each of these items in the written scope.
Can our own team run a Peppol access point without outside help?
Some organizations can, if they already run Java-based services, manage certificates and maintain a formal on-call process. Oxalis-NG and phoss SMP are open source, so the software itself is not the barrier. The harder parts are accreditation, correct AS4 and SMP configuration, certificate lifecycle management, keeping up with specification changes and handling failures at night. Before deciding, ask whether your team can cover those tasks for the full life of the service, including staff turnover. Many organizations choose a hybrid model, where DeployOpen implements and documents the system and your team operates it, or a retainer covers upgrades and support.
When should we choose a Peppol service provider instead of self-hosting?
A service provider usually makes more sense when document volumes are modest, when you only need to exchange invoices with a few partners, or when you lack the staff to run a regulated messaging service around the clock. It also suits organizations that need to start quickly and do not want to own accreditation. Self-hosting becomes more attractive when you need control over data location, want to avoid per-document fees at high volume, must integrate many internal systems, or have sovereignty requirements. Compare total cost over several years, including the staff and monitoring time that a service provider's fees may already cover.
How do we get a fixed-scope quote for a self-hosted access point?
DeployOpen does not publish a price list. Instead, a quote follows from a written scope that covers the systems to connect, expected document flows, hosting environment, certificate approach, monitoring requirements, testing with partners and handover to your team or a support retainer. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ask for the quote to show the one-time and recurring components separately, and to state which accreditation and third-party costs are excluded. DeployOpen can also support ongoing upgrades and operations under a retainer.
What to ask an implementation partner before signing
Start with Peppol accreditation, because it decides what the partner can actually sign for. Ask which access point and SMP deployments the partner has taken through the accreditation process with the relevant Peppol authority, and whether they have done it for your country and your role. Then get a written split of responsibilities: who prepares the Oxalis-NG and phoss SMP configuration, who submits the accreditation evidence, who answers the authority's questions, and who is liable if a document is rejected at the network edge. Confirm whether the partner provides any hosted component, any managed service-provider capacity, or only installation and handover. A partner that cannot separate these clearly is describing a service it has not defined.
Next, pin down ownership of certificates, the Oxalis migration and the keys. Ask who requests, installs, renews and revokes the Peppol certificates, who holds the private keys at handover, and how they are stored and backed up. For the move off frozen Oxalis, ask for the migration plan as a written artifact: which endpoints and configuration keys change, how the old and new access points run in parallel, how traffic is cut over, and what the rollback looks like. Ask for the evidence pack contents too: configuration baselines, test results from trading partner exchanges, logs retained for the agreed period, change records and the accreditation file. Confirm that DeployOpen prepares this evidence for your assessors and does not issue any attestation itself.
Finally, test the operating model. Ask how monitoring is delivered, which alerts exist for failed AS4 exchanges, SMP lookup failures and certificate expiry, who responds out of hours, and what the agreed incident severities and response targets are in writing. Ask for the support terms, including whether ongoing support, upgrades and continuous testing are a retainer or part of the fixed-scope work, and what the notice period for upgrades is. Before signing, require the operating runbooks, restore procedures and access list to be handed over and reviewed by your own team, and confirm that your staff, not the partner, hold administrative access to the environment at the end of the engagement.
