ISAE 3402 system description: template with example
The system description is the part of your ISAE 3402 report in which you explain yourself which service you provide, how it works, and which systems, people and data are involved. The auditor checks whether the description matches reality. A client reads it to understand what happens to its data. For a type 2 report, the description must also match the period for which you request an opinion. The framework of the whole engagement is on what ISAE 3402 is, the order of the process is on the step-by-step plan, and the place of the description in the report is on the requirements for the report. Your management confirms in a separate assertion that the description is accurate.
Write the description so that an accountant at your client can form a picture of it without you. If he still has three questions after reading it about how a process runs, the description is too thin.
What the system description contains
The sections below appear in most ISAE 3402 reports. The exact structure depends on your service and on what you agree with the auditor.
| Section | What you write | Question it answers |
|---|---|---|
| Service description | Which services you provide and which parts fall outside the scope | What exactly does the client get from us? |
| Infrastructure | Systems, applications, network and locations | Where does it run, and on which software? |
| Personnel and roles | Departments and roles that carry out the service | Who does what? |
| Processes | Step by step, the processes that affect the client, from receipt to output | How does the work flow? |
| Control objectives and controls | What you control, and with which control, for each objective | Why does this control exist? |
| Data | Which data you process, where it is stored and how long you keep it | Which data are we dealing with? |
| Subservice organisations | Suppliers that are part of the service, and how you treat them in the report | Who else is involved? |
| Additional controls of the client | What the client must do itself for the controls to work | What must our client arrange itself? |
Template
Use the structure below as a starting point. Fill in each heading with concrete facts. Replace the text in square brackets with your own details.
1. Introduction and scope
[Service name] provides [description] to [type of clients].
Outside scope: [parts that are not in the report].
Period: [start date] up to and including [end date].
2. Service description
Per service: what the client orders, which output it receives,
which service level agreements apply.
3. Infrastructure and applications
Per system: name, version, hosting location, administrator.
4. Organisation and roles
Per role: function, responsibility in the process.
5. Processes per service
Per process: start, steps, control points, end, exceptions.
6. Data and retention
Which data, where stored, how long kept, how deleted.
7. Control objectives and controls
Per objective: the controls, the owner and the frequency.
8. Subservice organisations
Per supplier: which service, which method in the report
(see subservice organisations), and whether it has its own report.
9. Additional controls of the client
Per control: what the client does and why (see CUEC).Example: system description of a payroll processor
Below is a fictional but realistic extract for a small payroll processor. Note the concrete details: who, which system, which step, which exception.
Processes per service (extract)
A change to a salary item comes in through the secure client portal or through a standardised file. An administration employee enters the change in the payroll package and records the source in the ticketing system. Changes above €500 are approved by a second employee before the payroll run starts. Differences between the source and the input are reported to the team leader the same day.
Infrastructure (extract)
The payroll package is version 8.2 and runs on two servers in the data centre of [hosting partner], managed by the system administrator of the service provider. Backups are made daily and tested weekly for recovery.
Why this works: the auditor can link each component to a piece of evidence. The ticketing system, the approval log and the backup test reports exist. The report also describes what is not included, such as the link between the client portal and the bank, which falls outside the scope.
Common mistakes
- A brochure instead of a description. Marketing phrases such as “reliable and secure” say nothing to the auditor. Write what happens and who does it.
- Missing systems. A tool you use for processing but do not name will be noticed during the walkthrough.
- Incorrect versions. A description of version 8, when you moved to version 9 in the middle of the period, is a change you must report.
- Unclear scope. If the client does not know what is not in the report, it will assume that everything was tested.
- Subservice organisations you leave out. A data centre or an external payment partner that affects the processing belongs in the description. For how to treat them, read subservice organisations.
- Client controls that are not mentioned. If your system depends on a control the client must perform, this must be in the description. See CUEC.
Frequently asked questions about the system description
Must the description be in Dutch?
In the Dutch market, the description is usually in Dutch, sometimes with English system names. Agree the language with your auditor and your clients, especially if your clients operate internationally.
Can I take over a template from another company?
You can take over the structure, but not the content. The auditor recognises a copy immediately, and the result is a description that is not about your systems. Use the structure and fill in the content yourself.
How long should the description be?
There is no fixed number of pages. A small service often fits on a few pages. What matters is completeness and accuracy, not length.
Who signs the description?
The description belongs to the service provider. Management signs a separate assertion that the description is a fair presentation and that the controls were designed properly (for type 2, also that they worked). The auditor gives his own opinion on this in his report. His opinion is therefore not the same as your assertion.
More information
The description is linked to the step-by-step plan, the audit and the requirements for the report. See also type 1 vs type 2 for what the auditor tests in the description.