Guideline 3000: what is it and why do I need it?

Advisory report versus assurance

Let's start at the beginning: all the terms mentioned above can ultimately be traced back to Directive 3000. And all the terms mentioned above have to do with assurance, another word for assurance. And specifically: assurance to third parties. This is an important feature, as an IT auditor you can perform an examination for an internal reader (often called an advisory report) or for an external reader (assurance).

Guideline 3000 aims to define a standard for assurance engagements and is derived from Standard 3000 of the Netherlands Institute of Chartered Accountants (NBA) and ISAE 3000 of the International Federation of Accountants (IFAC).

So in this case, Assurance explicitly means that a "third party" needs assurance about processes or services you perform. Think, for example, of investment administration for large pension funds, hosting hardware on behalf of large companies or providing Software-as-a-Service (SaaS) applications such as an online accounting or payroll package. In all these cases, it is (increasingly) common for the "customer," such as the pension fund, the large company outsourcing hosting, or the customer of the online payroll package, to ask: How do I know it's right?

Type of assurance

Now that we have clarified what assurance is, we can turn to the various forms of assurance reports that can be used to answer that question. The simplest answer is: within Directive 3000, almost anything is possible. What is essential is that when performing an assurance engagement, two things are carefully coordinated in advance: what is the precise question (need) of the client and what framework of standards is being used. Fortunately, the wheel does not always have to be reinvented here; in many common cases additional standards have been defined with which assurance can be provided. The most well-known are listed below:

1. Directive 3402: this concerns (according to the directive) assurance on the internal control measures of a service organization that provides a service to the user organizations that is likely to be relevant to the internal control of the user organizations in relation to financial reporting. In other words, this is about outsourced processes that have an impact on the client's financial statements (for example, the pension fund that outsources investment administration). Thus, the reader of this report in this case is often the client's auditor;
   
   
2. Directive 3000: this concerns (according to the directive): assurance assignments other than assignments to audit or review historical financial information. Simply put, therefore, basically everything that is not covered by Directive 3402. There are many examples of this, including some common standards:
   a. ENSIA: specific guideline by which municipalities must account annually to supervisors;
   b. DigiD: a very specific assurance engagement that is common in the Netherlands is the DigiD TPM. A separate directive has been drawn up for this. Annually, every holder of a DigiD connection must be tested in accordance with this guideline;
   c. Privacy Control Framework (PCF): directive aimed at testing control measures aimed at privacy and personal data protection;
   d. Police Data Act (Wpg): directive aimed at testing compliance with the requirements of this Act;
   e. See also NOREA - Handreikingen for an overview of all handreikingen;
   
   
3. System and Organization Controls (SOC): SOC is originally an American standard similar to Directive 3000 and recognizes three types of reports:
   a. SOC 1: assurance on internal controls at service providers in relation to financial reporting. This is actually the American version of ISAE3402 and is rarely used in the Netherlands;
   b. SOC 2: guideline intended for IT service organizations that want to provide assurance about controls in the areas of Security, Availability, Process Integrity, Confidentiality and/or Privacy. This includes, for example, the supplier of a SaaS application that wants to provide assurance to its customers. This guideline is increasingly applied in the Netherlands. Incidentally, this guideline in the Netherlands is also based on Directive 3000;
   c. SOC 3: This is an abbreviated version of a SOC 2 report, intended for general circulation.

And that word TPM? Is that what I need?

The result of an assurance engagement is often colloquially referred to as a Third Party Memorandum (TPM). So when one requests a TPM, what is actually meant is an assurance report performed against one of the above standards.

And then finally the question of whether you need it: that depends entirely on your situation, your services, what you yourself want from your organization and what your clients are requesting. In some cases, the latter is leading: if major clients or regulators require you to have an assurance statement, then you usually have little choice. If not, it is still advisable to think about an assurance statement because it is also a quality stamp on your organization and going through an assurance process also ensures growth (maturity) in your organization.

Difference between 3000A and 3000D

If we delve into the technical side of things, we see that the guidelines also distinguish between attestation and direct reporting engagements. This is an important distinction: in an attestation engagement, the IT auditor tests a "claim" by management (management statement); in direct reporting, the IT auditor tests the system of controls. With an attestation engagement, the organization is required to test whether it complies with the control procedures, make an assessment and include this in a statement. The IT auditor then tests whether that statement gives a true and fair view of reality. Examples of common attestation engagements include ISAE 3402, ENSIA, and SOC 2.

Type 1 or type 2?

Another important feature of assurance engagements is that an IT auditor can provide type 1 or type 2 assurance. Type 1 means that only design and existence is tested; with type 2, operation over a period of time is also audited. Design means the description (the paper reality), often recorded in policies, system documentation and procedures. Existence means that you can demonstrate that the design is actually implemented, for example with examples. Operation means that you can demonstrate that the setup has worked over an entire period (e.g., a year), with sampling and partial observations.

Why not ISO27001?

We see in practice that organizations often screen with an ISO27001 certificate. Although the ISO27001 standards framework is a good starting point and it is obviously a very good thing if your organization is ISO27001 certified, this is not comparable to an assurance statement. ISO27001 is actually a set of best practices that you can implement, but that does not compare to specific assurance about your actual services. In addition, ISO is always only about design and (limited) existence while assurance provides more assurance by also testing operation. Nevertheless, ISO27001 is a good first step toward an assurance statement. However, we do see a movement in the market that ISO27001 is becoming less and less accepted and that people are demanding an in-depth assurance statement.

How can we help you?

I hope that I have been able to guide you through the spider's web of assurance guidelines and that this will help you make the right choices should you be asked to provide an assurance statement.

Of course we at 2-Control can also help you think about the most appropriate form of assurance. We have extensive experience with all the standards mentioned above and can advise from a pragmatic point of view. So if you have any questions, please contact us!