Custom software for ISAE 3402 and SOC reporting
With a type II report, the question is not whether your controls exist but whether they operated effectively throughout the period. That changes what you need to keep: not the position on the day of the audit, but evidence from every month. Those who gather it afterwards find that the months in which things went wrong are exactly the months for which nothing was kept.
Type I, type II and the difference that matters
ISAE 3402 is the international standard for assurance over controls at a service organisation, focused on controls that affect the financial reporting of your clients. SOC 2 focuses on information security and the related system controls. Which of the two your clients ask for depends on what they engage you for.
The distinction that matters most is type I versus type II. A type I report assesses the design and existence of your controls at a single point in time. A type II report additionally assesses whether they operated effectively over a period, in practice at least six months. That second part is what clients want and it requires a very different kind of record-keeping.
For a type I, a description and a sample on the day itself will suffice. For a type II, you must be able to show for each control that it was performed every time, with evidence from that period. An access review you carry out every quarter must be demonstrably done four times, and a quarter in which it was forgotten cannot be fixed with an extra round just before the audit.
In a type II examination, the auditor picks a random day from the period. That evidence must have been created at the time of the activity, often in a server room or an archive. How to record that on the spot is covered in the app for signing off controls.
How we build this
The control, together with its frequency, is the unit here. If the evidence arises naturally at the moment the control is performed, the audit becomes a selection rather than a search.
What you do, how often, who owns it and what the evidence is. Those four questions per control form the entire foundation; everything after follows from them.
We draw it from the systems where the work takes place rather than making it a separate activity. Evidence that requires manual effort goes missing in the busy months.
A control that was not performed once is a finding, not a disaster, provided you spot it yourself and act on it. Hiding it does not work; the auditor will find the gap.
What you assume of your client should be stated explicitly in the report. We build that as a dedicated list rather than a paragraph nobody reads.
What the software actually does
The register of controls, with their evidence, carries everything. Which components you need depends on whether you issue the report or receive one.
Controls with frequency and owner
For each control: what has to happen, how often, by whom, and what evidence that produces. Without those four, a type II audit is a reconstruction after the fact.
Evidence from the systems themselves
Access reviews, backup checks, change approvals and log files come in through integrations rather than a round of emails. What arrives automatically doesn't go missing in a busy month.
Performance monitored per period
The system shows, per control, which periods are covered and which are not, during the period rather than afterwards. A gap can then still be remedied.
Exceptions with follow-up
A control that was not performed, or a check that failed. Each becomes a finding with an owner and a deadline, because a gap you have seen and followed up carries different weight from one the auditor discovers.
CUECs as an explicit list
The controls you assume of your clients, with per client whether they have confirmed them. This is the appendix everyone skips, and it is the one on which your own control objectives rest.
Audit file per period
All evidence for the reporting period gathered together, with the version of the control that applied at the time. At audit, that is the difference between supplying evidence and collecting it.
Who we build for
Whether you issue the report or receive one changes the system entirely. Four situations.
Service organisations that report
You issue the report to your clients and carry the full burden of evidence. Your greatest risk is the month in which a control was skipped and nobody noticed. If you also fall under the Cybersecurity Act, part of your control set overlaps.
Outsourcing parties
You receive reports from your suppliers and must assess them. What you really need to read is the CUEC appendix, because it states what you should have set up for their conclusion to hold.
Organisations with many suppliers
Dozens of reports a year, each with its own periods, its own exceptions and its own CUECs. Without a register it becomes a filing cabinet nobody consults until the accountant asks for it. Suppliers submit their reports via a supplier portal.
Chains where both roles meet
You issue a report and also rely on reports from your subcontractors. It must then be visible which part of your own assurance comes from their report. If a standard also applies, this aligns with your quality management system.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
The standards are revised periodically, and your own control set changes with your services. Everything related to this should be configurable and retained per version.
Why Appfront
A type II audit measures the period, not the day
We show coverage per period while it is running. A gap you see in month three can be remedied; the same gap in month nine cannot.
Evidence that gathers itself
What people have to supply manually goes missing precisely in the months when things were busy. We retrieve it from the systems where the work takes place.
The CUEC is not an appendix but an agreement
Your objectives will only be achieved if your client has set up their part. We draw up a list of these with confirmation per client.
A gap you find yourself weighs differently
We make exceptions visible with follow-up, because concealing them doesn't work, and an auditor also assesses how you handle deviations.
Security and privacy
An audit file contains the complete picture of how your organisation is secured, including the places where something once went wrong. To an attacker, that is more valuable than the systems themselves. We therefore keep access tightly controlled by role, separate the submission of evidence from its assessment, and record every inspection.
Sharing with third parties brings something special. Your auditor needs access, your clients want the report and sometimes the underlying documents, and your suppliers provide their own evidence. These are three different circles that should not see each other's material. We therefore build separate access paths rather than one shared folder, and limit what an external party sees to the period and controls for which they have been invited. On the evidence side, an item of evidence must be immutable and time-stamped: evidence that can be updated after the fact is not evidence in a type II audit. For how we handle security ourselves, see our information security policy; reports from outside come through our vulnerability disclosure policy.
Frequently asked questions about ISAE 3402 and SOC
A type I report assesses the design and existence of your controls at a single point in time. A type II additionally assesses whether they operated effectively over a period, in practice at least six months. Clients almost always ask for type II, which requires evidence from every month rather than a snapshot.
ISAE 3402 focuses on controls that affect your clients' financial reporting; SOC 2 focuses on information security and related system controls. Which one your clients ask for depends on what they engage you for; some service organisations provide both. Your accountant determines the scope, not your software supplier.
These are the controls the service organisation assumes the client has set up themselves, for example managing their own user accounts or checking output reports. The objectives in the report are only achieved if that assumption holds, and the report states this explicitly. It is the appendix most often overlooked.
Read them, especially the exceptions and the CUEC list. The exceptions tell you what went wrong at your supplier; the CUECs tell you what you should have set up for their conclusion to apply to you. Filing a report away without assessing those two gives false comfort.
Then it is an exception and it belongs in the report. That is unpleasant but not fatal; what weighs more is whether you had seen it yourself and what you did about it. A gap the auditor finds while you were unaware says something about your control environment, not just about that one month.
Sometimes for a type I; never for a type II. The question is whether the control was performed at the time, and a reconstruction after the fact does not answer that. That is why we collect evidence from the systems where the work takes place, rather than making it a separate activity.
No. A certification states that you meet a standard; an assurance report describes your specific controls and an accountant's opinion on their design, existence and operating effectiveness. Your clients can get something from it that a certificate does not offer: they can read exactly what you do.
That depends on the number of controls, how much evidence can be collected automatically, and whether the CUEC side needs to be included. The register with period coverage is usually quick to make useful and immediately shows where the gaps are; the integrations cost more. We give a reasoned estimate after the discovery phase.
Collecting evidence throughout the period?
Take one control that you perform every quarter and try to trace the evidence for all four quarters. Wherever that trail stops, you have your type II risk. We build this as a standalone application and as part of a broader custom software project.