“We have an ISAE 3000 report.” That sounds reassuring. It also tells you surprisingly little, because an ISAE 3000 report can relate to GDPR controls, NIS2-related supplier controls, cybersecurity, contractual requirements, SKI security requirements, corporate-law matters or something else entirely.
ISAE 3000 is an assurance standard. It does not prescribe one fixed set of security or compliance requirements for organisations to implement. That distinction matters, especially when customers, procurement teams and suppliers start treating “ISAE 3000” as if it were another ISO 27001. It isn’t.
The short version
ISAE 3000 stands for International Standard on Assurance Engagements 3000, and the current version is ISAE 3000 (Revised) from the International Auditing and Assurance Standards Board (IAASB). It is deliberately broad: the general, overarching standard for this family of assurance engagements, supporting both reasonable and limited assurance across many different subject matters. One qualification matters, though: a more specific assurance standard can also apply to a particular subject matter, because subject-matter-specific ISAEs build on and supplement ISAE 3000. In Danish practice, FSR therefore describes it as the standard used where no more specific standard fits the reporting need.
FSR - danske revisorer makes the practical difference clear: an assurance standard determines how the auditor plans, performs and reports the assurance work. It does not prescribe the processes and controls that a service provider must have. So, in plain English: ISAE 3000 tells the assurance practitioner how to perform the engagement. It does not hand your organisation a universal security checklist. That checklist, framework or contractual requirement set comes from somewhere else, and that is where the useful part begins.
A report is only as meaningful as what sits underneath it
Think of ISAE 3000 as the assurance methodology. You still have to define what is being assured and against what, so a useful shorthand is:
ISAE 3000 engagement = subject matter + criteria + scope + date/period + assurance level + assurance procedures + conclusion
Change any one of those elements and you end up with a completely different assurance engagement. Same ISAE 3000, very different assurance.
So what does ISAE 3000 actually cover?
A lot, and that is the point. FSR lists examples including GDPR, cybersecurity, general IT controls, application controls, NIS2 and DORA, and the standard is also used entirely outside cybersecurity, including for certain corporate-law assurance engagements.
But there is a naming trap here. Terms such as “ISAE 3000 GDPR”, “ISAE 3000 NIS2” and “ISAE 3000 Cyber” are useful market shorthand, but they are not separate IAASB standards. The label is telling you something about the subject matter or criteria attached to the engagement: “GDPR” points to controls for personal-data processing and obligations under data-processing agreements, “NIS2” to defined supplier measures and contractual requirements, “Cyber” to a defined control environment. That is why asking “Do you have ISAE 3000?” is usually incomplete. Ask instead: “What does your ISAE 3000 report actually cover?” Much better.
It is not a certification, and it does not automatically mean “secure”
ISO 27001 certification and an ISAE 3000 report are different things. ISO/IEC 27001 defines requirements for an information security management system, which an organisation implements and is certified against within a defined certification scope. ISAE 3000 provides no equivalent universal set of organisational requirements. It is an assurance standard used by the assurance practitioner, which is why “ISAE 3000 certification” is an inaccurate label: there is no universal ISAE 3000 state a company reaches, no master checklist, no magic badge and no moment where somebody declares your entire organisation “ISAE 3000 compliant”.
The practitioner concludes on a defined subject matter, against defined criteria and within a defined scope. Read the scope. Always. One engagement might cover 15 narrowly defined contractual controls, the next an extensive cybersecurity control environment spanning identity, access management, vulnerability management, incident response, supplier security, business continuity, logging and security governance. Both are performed under ISAE 3000, but the assurance they provide is not remotely identical, because a conclusion does not reach beyond what the practitioner was engaged to examine. If application security or supplier management sits outside the scope, the report does not cover it. Assurance has boundaries, and the acronym on the front page does not remove them.
What people mean by “Type 1” and “Type 2”
Here is an important terminology trap: Type 1 and Type 2 are not classifications defined by ISAE 3000 itself. Both terms are formally used in ISAE 3402 and have also become common shorthand in Danish ISAE 3000 reporting. FSR’s GDPR templates use “type 1” and “type 2”, and SKI’s 02.15 and 02.17 material explicitly requires reports labelled ISAE 3000 Type 1 and Type 2. The terminology is real in Danish practice, it just does not originate in the standard.
Type 1, in Danish practice, covers whether the relevant controls are appropriately designed and implemented at a specified date: have we established the control environment we said we would, from access control and incident response to backups, supplier management and approved policies? It provides assurance over that design and implementation on that date. It does not prove that the controls have operated effectively for the previous twelve months.
Type 2 extends the engagement across a period and covers whether the controls operated effectively, or whether the defined requirements were complied with throughout it. Writing “Privileged access is reviewed quarterly” is easy. Maintaining evidence that the reviews actually took place, that exceptions were handled and that the control kept operating is something else. And since the practitioner samples rather than inspecting every single occurrence, Type 2 means the conclusion relates to the defined period rather than a single date.
Separately from all that, ISAE 3000 works with two levels of assurance: limited assurance and reasonable assurance. Reasonable assurance is high, but not absolute, and limited assurance provides a lower level based on procedures that differ in nature, timing and extent. So a useful review does not stop at “Is it Type 1 or Type 2?” You also want to know: ISAE 3000 over what? Against which criteria? At a date or over which period? At what level of assurance?
Why it matters particularly in Denmark
ISAE 3000 is particularly relevant in Denmark because independent assurance reports are widely used to create trust between customers and service providers, and the use runs broader than cybersecurity: FSR notes that the standard is also used for certain company-law assurance engagements. That breadth supports the central point, which is that ISAE 3000 is not a cyber standard with a hidden list of security controls. Three areas dominate Danish cybersecurity and GRC work: GDPR, NIS2 and public procurement.
For GDPR, ISAE 3000 has become the familiar way to report on the controls performed by data processors, and FSR and the Danish Data Protection Agency have collaborated on assurance-report templates for controller oversight, prepared using the Danish “Type 1” or “Type 2” convention and at different levels of assurance. Again, the useful question is not whether the processor has “ISAE 3000”, but whether the report covers the processing activities, controls and contractual obligations that matter to you. Receiving the PDF is not the end of supplier oversight. Someone still has to read it.
For NIS2, the Danish NIS 2 Act entered into force on 1 July 2025, and FSR has developed an ISAE 3000 template as a common starting point for assurance on measures between regulated entities and their direct suppliers. It is not a blanket certificate of the supplier’s compliance with every NIS2 obligation: FSR explicitly describes the control activities and assurance procedures as guidance that must be adapted to the concrete risk assessment, the agreed measures and the practitioner’s professional judgement.
And then there is SKI
This is where the distinction becomes genuinely practical. SKI, Staten og Kommunernes Indkøbsservice A/S, is a publicly owned procurement company and purchasing body serving the Danish public sector, owned 55% by the Danish state and 45% by KL. For the 2025 02.15 It-rådgivning and 02.17 It-konsulenter framework agreements, SKI made its security annex mandatory. But there is no single “SKI ISAE 3000 requirement”. There are several separate obligations that are easy to mix together, and SKI has collected the answers in a Q&A on Bilag B.3.
1. The IT-security assurance under section 11.4.4. Here the relevant requirements live in Bilag B.3 Sikkerhedskrav, which uses four security packages, B (Basis), 1, 2 and 3, plus add-on packages. The customer picks the package for the particular delivery, and different sub-deliveries can be subject to different packages. But that delivery-level choice is not the same as the scope of the supplier’s framework-level report: SKI’s FAQ states that the report under section 11.4.4 must cover packages 1, 2 and 3 plus the add-on packages, and that Basis package B is explicitly not included in that audit requirement. Claiming the report covers “all of Bilag B.3” without explaining the exception would be misleading.
The timetable is just as concrete. SKI’s FAQ set 1 September 2025 as the deadline for the first Type 1 report, and it could be dated before the framework agreement entered into force provided it covered the required controls. So the deadline is not a generic rule such as “three months after entry into force”, because the two agreements entered into force on different dates. After that, SKI requires annual Type 2 reporting with no uncovered period between successive reports, where the first period may run shorter than twelve months. The scope also reaches beyond the named main supplier to consortium members and subcontractors in use. That is considerably more specific than “We have an ISAE 3000.”
2. The personal-data assurance under section 11.4.3. SKI’s framework agreements also carry a separate assurance requirement on personal-data processing, and the FAQ is explicit that this report does not refer down into Bilag B.3. It concerns the supplier’s compliance with the data-processing obligations in the framework agreement and the delivery contracts, it starts when the supplier begins acting as a data processor, and it repeats every twelve months. The applicable standard varies: ISAE 3402 or equivalent where the service is relevant to the customer’s financial reporting, and otherwise ISAE 3000 (Revised) or equivalent. So even inside the same framework agreement, the answer to “Which assurance standard applies?” can depend on the service.
3. ISO 27001 or equivalent under section 11.4.1. The FAQ refers separately to section 11.4.1, which requires compliance with ISO/IEC 27001 or equivalent, and that is not the ISAE 3000 assurance requirement. That is why the sentence “The actual SKI security requirements come from Bilag B.3” is too broad. Four layers have to be kept apart: the framework security obligations, the delivery-level security package, the IT-security assurance under section 11.4.4 and, where it applies, the personal-data assurance under section 11.4.3. Nor is the model uniform across SKI: on 02.14 It-konsulenter (DIS), customers choose between SKI’s security annex and their own, so do not assume the 02.15/02.17 model carries over unchanged. For ongoing Type 2 work, though, the practical consequence is always the same: the evidence has to exist while the controls are operating, not three weeks before the auditor arrives.
ISAE 3000 vs ISAE 3402
These two also get mixed together. ISAE 3402 is a subject-matter-specific assurance standard for controls at a service organisation that are relevant to user organisations’ internal control over financial reporting. FSR is quite direct: ISAE 3402 is for services that support customers’ financial reporting, and it is not the right standard for GDPR, cybersecurity, NIS2 or DORA when those matters are unrelated to financial reporting. It sits within the same ISAE architecture and supplements the general requirements, and it formally uses Type 1 and Type 2 reports, which ISAE 3000 does not. So controls relevant to customers’ financial reporting point to ISAE 3402, while cybersecurity, GDPR, NIS2, contractual security requirements or another suitable non-financial subject matter point to ISAE 3000. The right answer depends on what assurance is actually needed, not which acronym looks best in the sales deck.
How to read a report properly
Seeing “ISAE 3000” on a supplier’s security page does not tell you that the entire organisation was in scope, that every product or subsidiary was included, that all cybersecurity controls were examined, that the supplier meets every GDPR or NIS2 obligation, or that there were no exceptions. The answers need somebody to read the report, and these are the questions that matter:
- Subject matter. What exactly is the engagement about: GDPR-related processor controls, cybersecurity, SKI requirements, NIS2 supplier measures or one particular service?
- Criteria. Which benchmark was used: a law, a contractual control set, a customer requirement, a framework or an internally defined set? Do not translate that into “Is the whole organisation compliant?”, because that may not be what the practitioner concluded on.
- Scope. Which systems, services, locations, legal entities and processes are included, and which are not? Some control environments also only work if the customer performs specified activities.
- Date or period. If the report uses Type 1/Type 2 terminology, find out what it means in that specific report. A beautiful report covering January to December 2025 still only covers January to December 2025, and evidence gets old.
- Level of assurance. Limited or reasonable, which is not the same question as Type 1 or Type 2.
- Exceptions. Often the most interesting part. An exception is not automatically catastrophic, but you need to know what happened, how significant it was, whether it was isolated or systemic and what followed.
And then the final test: a perfectly valid report is still irrelevant if it does not address the risk you are trying to assess.
Preparing for an engagement is therefore not about “implementing ISAE 3000”
It sounds contradictory, but it is not. The assurance practitioner needs evidence, and the organisation’s work happens before the engagement: determine the applicable requirements and criteria, establish and implement the controls, assign owners, document the procedures, perform the recurring activities, retain the evidence, review exceptions, remediate findings, and keep the control environment running throughout the relevant period. Then the practitioner examines it. The report is a checkpoint. The control environment is the job.
This is where ArbaGRC helps
A GRC platform that gives you a folder called “ISAE 3000” and an upload button has technically contributed. Well done, folder. The hard part is everything that happens before the PDF arrives: requirement → control → owner → task → evidence → review → finding → remediation → assurance. That is exactly the part we built ArbaGRC to handle. Because for SKI 02.15 and 02.17, the useful work is not pretending that ISAE 3000 itself contains the security requirements, it is getting the actual contractual obligations under control: Bilag B.3, the delivery-level security package, the separate assurance obligations, ISO 27001-or-equivalent, owners, controls and evidence.
So instead of SKI in one spreadsheet, ISO 27001 in another, NIS2 in a third, evidence in SharePoint, findings in Jira, one critical screenshot in somebody’s Downloads folder and Audit_FINAL_v8_THIS_ONE.xlsx holding the whole thing together through force of personality, the work stays connected in one place. One requirement maps to the controls that implement it, the same control covers overlapping obligations across ISO 27001, NIS2 and GDPR, evidence stays attached to the work it documents, owners and deadlines remain visible, and findings move through remediation. When the auditor asks what happened over the last twelve months, you have an operating record instead of a reconstruction project.
ArbaGRC does not make you “ISAE 3000 compliant”. That would make no sense. The platform implements, operates and documents the actual requirements underneath the assurance engagement and collects the evidence for them, which is considerably more useful.
TL;DR
ISAE 3000 is a standard. It is an assurance standard. It is not a cybersecurity framework, a certification scheme, a universal compliance checklist or a secret collection of controls your organisation “implements”. It tells the assurance practitioner how to perform an engagement over a defined subject matter using suitable criteria.
Remember the terminology trap as well: “ISAE 3000 GDPR”, “ISAE 3000 NIS2” and “ISAE 3000 Type 2” are useful labels in the market and in Danish templates and contracts, not separate versions or native ‘types’ defined by the standard itself. And for SKI 02.15 and 02.17, Bilag B.3 is central to the IT-security assurance requirement, but it is not the whole picture of the contractual security requirements.
So the practical job is not “Implement ISAE 3000.” It is: implement the real requirements, run the controls, keep the evidence, and be ready to show what actually happened. That is the bit ArbaGRC is built for. Because compliance is hard enough without complying with a standard that never asked you to.