DigiD assessment for SaaS providers: the RSO, norm allocation and the Logius pre-check

DigiD is the login scheme Dutch citizens use for public services. Every organisation that lets citizens log in with DigiD must submit an annual security assessment to Logius, the government agency that supervises the scheme on behalf of the Ministry of the Interior. If a municipality, health insurer or education institution runs that citizen portal on your platform, you are what the assessment rules call a service organisation. The DigiD connection stays in your customer's name and your customer submits the report, but part of the 21 norms is tested at your end rather than theirs. This article covers how that allocation is made, what your customer needs from you, when an ISAE 3402 or SOC 2 report is enough, how old your report may be, how the Logius pre-check works and what changes on a multi-tenant platform. For the obligation itself, the deadlines and how Logius supervises, see DigiD assessment: who must comply and which deadlines apply.

Who carries the responsibility and what is tested at your end

Logius deals with one party only: the DigiD service provider, the organisation that holds the connection number. That organisation remains owner and ultimately responsible, even when the portal, hosting, administration and DigiD interface are fully outsourced. Logius restated this in April 2026 in its rules for the "my environment" set-up: regardless of outsourcing to a broker, SaaS or hosting party, the service provider remains the owner of the connection. A letter about a deficiency therefore goes to your customer's board, not to you. That is also why your customer raises the assurance question during procurement.

When the service provider outsources part of the environment, the service organisation falls within the scope of the assessment. Some norms are then tested at the service organisation, some at the service provider, and some at both. The service provider's RE auditor (a registered IT auditor in the NOREA register) decides that allocation. Logius does not prescribe which norms land where, but it does state that there are always norms the service provider must have tested itself.

The scope follows the perspective of the citizen who logs in: the internet-facing pages the citizen uses after logging in, the system interfaces and infrastructure involved in the identification and authentication process, and the administration of all that. Out of scope are www.digid.nl itself, the token exchange between Logius and the web server, and the back-office systems that feed data into the web application. Subsystems and interfaces are in scope as soon as their primary authentication is based on DigiD. For a SaaS platform that usually means the application, the environment it runs in and the processes for change, patching, access and logging are tested at your end. Those include the five norms that have been tested on operating effectiveness since 2025 (U/TV.01, U/WA.02, C.07, C.08 and C.09), with a test period of at least six months.

Two ways to be tested: inclusive or carve-out

There are two routes, and they match the carve-out and inclusive method in ISAE 3402 and SOC 2. Under the inclusive method, service provider and service organisation are tested as one whole and the results land in the service provider's report, the RDV. That works if you have one customer. With ten customers it means ten auditors visiting the same environment every year, each with their own evidence requests and schedule.

Under the carve-out method you, as the service organisation, engage an RE auditor to test your part of the norms. The result is a service organisation report, the RSO, formerly known as a TPM (Third Party Mededeling). You hand that one report to all your customers. Their auditor assesses whether it applies, carries the opinions over into appendix C of the RDV and tests only the norms that stayed with the service provider. For a SaaS provider with several DigiD customers this is the only workable route.

There is a hybrid too: several service organisations without the service provider, for instance you and your hosting party, can be tested together under the inclusive method. The result is one RSO covering the whole chain beneath you, which your customers then use under the carve-out method.

What goes into an RSO and what your customer's auditor checks

The RSO follows the NOREA template, which differs from the service provider template on a few points. The main one is the chapter on user organisation responsibilities: the norms, or parts of norms, your customer has to cover itself, such as managing its own staff accounts in your platform or approving the changes it requests. Anyone familiar with complementary user entity controls in a SOC 2 or ISAE 3402 report will recognise the mechanism. Write that chapter carefully, because your customer's auditor reads it as the list of what still has to be tested at the customer.

The formal requirements are the same as for the RDV: an opinion of complies or does not comply per norm, a unique reference, PDF/A and a qualified electronic signature tied personally to the signing RE auditor. Your customer's auditor checks that the RSO matches the object of examination (your platform may have changed between the RSO's issue and the customer's assessment), that the signature is valid and that the report is not too old. If the two auditors disagree about usability, the matter can be put to NOREA.

If you have suppliers in the chain yourself, such as a hosting party or an identity broker, they are sub-service organisations. Their RSO or international assurance report feeds into your RSO, subject to the same age and signature requirements. A hosting party without its own assurance is a gap in your report, and therefore in the report of every one of your customers.

Can an ISAE 3402 or SOC 2 report replace the RSO?

Logius accepts an ISAE 3402 or SOC 2 report as assurance for a service organisation, with one reservation: the service provider's RE auditor decides how far the report can be used. The controls in such a report do not map one to one onto the 21 DigiD norms. Your customer's auditor assesses per norm whether the controls in your report cover it, records that this mapping was done, and enters the document details and the covered norms in appendices C and D of the RDV.

That has three consequences. Every customer has the mapping done by its own auditor, so the work is repeated as many times as you have customers. Norms your report does not cover, or covers only partly, still have to be tested at your end or at your customer's. And an opinion that an ISAE 3402 control operated effectively says nothing about a DigiD norm that control does not describe. With more than one or two DigiD customers, an RSO on the 21 norms is the cleaner route. It does not rule out an ISAE 3402 or SOC 2 engagement: the same auditor can combine the fieldwork for both reports in the same test period.

An ISO 27001 certificate or a data processing agreement is neither. Logius only mentions RSOs and international assurance reports such as ISAE 3402 and SOC 2. A certificate states that a management system conforms to the standard and gives no opinion per DigiD norm, so your customer's auditor cannot fill appendix C with it.

The twelve-month rule and annual renewal

The opinions in an RSO may not be more than twelve months older than the opinions in the service provider's report. Logius does not look at the report date. For a norm tested on existence, the difference between the opinion dates counts; for a norm tested on operating effectiveness, the difference between the end dates of the test periods. The same rule applies to the reports of your sub-service organisations relative to the service provider's report.

Every annual assessment also needs a new RSO. The only exception: an RSO that resulted from a re-assessment last year may be used once more. Two consecutive initial reports may not be identical, because the intention is that every service organisation is tested again every year.

For planning, one rule that does not apply to you helps. The service provider may not set its opinion date before 31 December, so that December falls within its assessment. Service organisations are exempt from that requirement. Logius itself gives the example of a service provider having October to March tested on operating effectiveness, using an RSO whose test period ran from June to November with an opinion date at the end of November. If you issue your RSO in December, you are ready before your customers' auditors start. If you are still working in March, you hold up the reports of all your customers. Bear in mind that Logius has announced the test period for operating effectiveness will grow to a year; if you already have a full year tested, nothing changes for you.

The Logius pre-check: 1 September to 1 November

Since 2023 a draft RSO can be checked by Logius in advance. The conditions are precise. The report must be issued to several service providers, so an RSO for a single customer does not qualify. It is submitted as a draft, must not yet have been issued to customers, carries a reference ending in -check and has no electronic signature yet. The auditor sends it through the Logius submission form, entering their own name and firm in the field for the connection number. Logius responds by email, normally within five to ten working days, and does so once per RSO. If you have several services or service organisations, you submit the next draft only after processing the comments on the previous one, so the same error is not made twice.

Logius adds that a good draft is no guarantee of a good final version, because an RSO is only part of the total report and some errors only surface from the way the parts fit together. The pre-check is still worth it. A formal error in an RSO otherwise surfaces during the submission period, when your customer's report is rejected and the correction deadline starts running. You then fix it under time pressure for all customers at once. Plan the test period so the draft is ready in September or October.

Multi-tenant: one platform, many connection numbers

Each customer has its own connection number and submits its own report; your RSO is attached to each of them. That only works if the RSO describes the service the way all those customers consume it. So state explicitly what is arranged at platform level and applies to everyone, and what differs per customer: configuration, interfaces with customer systems, customer-specific administrator accounts. Customisation for one customer that is not in the RSO falls outside the report and that customer has to have it tested separately.

With a "my environment", several services or applications behind one connection number, for instance through an identity broker, this becomes even more precise. Since April 2026 Logius requires, per application, a description, a list of the suppliers involved and a table of norms. An application added during the year must have a test period of at least six months for the norms tested on operating effectiveness; otherwise Logius treats the norm as not complied with. For a SaaS provider rolling out a new module, that means the operating effectiveness of change management, patching and monitoring on that module has to be built up before the customer can include it in its assessment.

The multiple assessment: only for a cluster connection

There is a variant in which the service organisation accounts for all its connection holders in one go: the multiple assessment. The supplier, called the LMA by Logius, signs an agreement with Logius, demonstrates during the assessment that onboarding a new customer is a standard and repeatable process, implements technical controls for the norms that would otherwise be tested at the connection holder, and includes a mandatory annex in the contract with every connection holder. All connection holders consume the same service; customisation is not allowed. New customers can ride on a positive assessment until the next annual one. The downside: if the supplier issues no report or no positive report, Logius can terminate the service for all connection holders, and Logius may carry out a supervisory visit.

The limitation is significant. The multiple assessment is only possible for a cluster connection, and TVS is currently the only provider of those, so it is open only to providers in the healthcare domain. For most SaaS providers, the RSO per customer remains the route.

Where it goes wrong in practice

The RSO arrives late. The customer's auditor cannot complete appendix C, the 1 May deadline approaches and the customer gets the letter. Count back from December and use the pre-check.

The RSO describes a different environment from the one the customer uses. A new version, a second data centre, an acceptance environment with production data kept out of scope. The customer's auditor tests the object of examination and finds the difference.

Operating effectiveness has not been built up. The change management procedure exists, but there are no six months of approved, tested and logged changes to show, or monitoring runs without anyone following up on alerts. How to make that demonstrable is covered in logging and monitoring for the audit. A gap in operating effectiveness cannot be closed before the deadline.

The hosting party has nothing. Your RSO relies on a sub-service organisation without its own RSO or assurance report, and that gap carries through to every customer.

Secure Audit performs DigiD assessments as an RE auditor, for service providers and for service organisations, including preparing RSOs and combining them with an ISAE 3402 engagement. See the IT audit services page.

Sources: Logius, IT-assessmentrapportage voor DigiD (outsourcing to a service organisation), Mededelingen ICT-beveiligingsassessment DigiD (pre-check on RSOs, 22 July 2024; the DigiD assessment and the "my environment", 14 April 2026) and Het meervoudig assessment: https://www.logius.nl/onze-dienstverlening/toegang/digid/ict-beveiligingsassessments-digid